Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 2820 invoked from network); 14 Oct 2002 15:44:40 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 14 Oct 2002 15:44:40 -0000 Received: (qmail 21674 invoked by uid 97); 14 Oct 2002 15:45:26 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 21615 invoked by uid 97); 14 Oct 2002 15:45:24 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 21602 invoked by uid 98); 14 Oct 2002 15:45:24 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-Id: <5.1.0.14.0.20021014173357.025d0538@mail.qos.ch> X-Sender: ceki@mail.qos.ch X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 14 Oct 2002 17:44:32 +0200 To: "Jakarta Commons Developers List" From: Ceki =?iso-8859-1?Q?G=FClc=FC?= Subject: Re: [Latka][Proposal] Make Jelly a required dependency? In-Reply-To: <01f801c27391$7a67f280$3565a8c0@spiritsoft.com> References: <3DAA7BD2.8080409@apache.org> <5.1.0.14.0.20021014154214.027b2d78@mail.qos.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N At 15:53 14.10.2002 +0100, James Strachan wrote: >From: "Ceki G=FClc=FC" > > Being in the process of writing an XML processing library called > > joran, I am thoroughly impressed by Jelly's capabilities. Even if its > > documentation is imho somewhat lacking, Jelly looks like one of the > > most promising projects currently under the Jakarta umbrella. > >Wow, thank you Ceki. I'm literally blushing right now. Although I meant what I said, I am not necessarily a qualified judge. >I'd not spotted joran up to now but have read the specification and will be >tracking it. It sounds interesting. Have you any examples of what joran >might look like yet? No, I do not have examples, except in my head. Moreover, one wonders at the= =20 sanity of the Joran enterprise when a library like Jelly is already=20 available. >I've used digester quite a bit and, though it took a while to get going= I've >found it very useful. One nice thing about using things like Ant and Jelly >is that they are runtime extensible; so its easy to add some custom stuff >into the XML files (Ant build.xml or Jelly scripts) without having to= change >the core. >Recently I've been looking at the digester configuration mechanism in >commons-messenger and am seriously thinking of replacing it with a >Jelly-version as its much easier to extend and to plugin custom tags to do >new stuff. To extend the digester version, a user needs to switch the >Digester implementation class that a component is using; while this is >perfectly possible its a bit easier to do with things like Ant or Jelly >since the extensions can all be inside specific XML documents. > >It might be an interesting experiement to try create an implementation of >Joran as a Jelly library? That is an interesting thought. >James >------- >http://radio.weblogs.com/0112098/ -- Ceki TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others. -- Jon Postel, RFC 793 -- To unsubscribe, e-mail: For additional commands, e-mail: