You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Morgan Delagrange <md...@yahoo.com> on 2002/10/11 19:09:16 UTC
[Latka][Proposal] Make Jelly a required dependency?
Hey all,
I finished a rough cut conversion of the Latka tags
and validators to Jelly. The Jelly tags have syntax
identical to the previous Latka tags. I think it will
be pretty easy to emulate Latka variables inside the
Jelly expression language (JEXL). With a patch I made
to Jelly this week, I think even the lack of a
namespace declaration in existing scripts will not be
a problem.
I believe that the functionality of the Jelly tags is
actually a complete superset of the previous
implementation. The command line interface should be
able to function unchanged if converted to a Jelly
backend, but the new tags will make it much easier to
run Latka inside applications like Ant and JUnit. I
propose that we make Jelly one of Latka's
dependencies, so that we can remove the XML handlers
and processors that support the previous tags. In my
view, the Jelly implementation is much cleaner and
will render the old tags unnecessary.
- Morgan
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Latka][Proposal] Make Jelly a required dependency?
Posted by Morgan Delagrange <md...@yahoo.com>.
It sounds like moving Jelly to either Commons Proper
or to a top-level subproject is nearly a fait
accompli, so I'm going to start making some commits
that remove the legacy XML processing.
Even though Latka's been around longer than Jelly,
Latka is still in beta, so I'm not too worried about
having Jelly as a dependency. In fact, I thinking
converting to Jelly might actually hasten our progress
to a release candidate.
- Morgan
--- Steve Downey <st...@netfolio.com> wrote:
> Well, commons-sandbox is supposed to be a
> whiteboard/scratchpad area. It's
> also functioning as an incubator. I don't think the
> intent is for something
> to live there forever. Having a dependency on a
> sandbox project is having a
> dependency on something that has no plans of
> releasing.
>
> The first step out of sandbox isn't a release. It's
> becoming an official
> project.
>
> For Jelly, given all the activity and commitment,
> being accepted as a project
> ought to be a layup.
>
>
> On Monday 14 October 2002 04:17 am,
> dion@multitask.com.au wrote:
> > Is there a rule somewhere about not having sandbox
> components as a
> > dependency? Or is this a general call to move
> Jelly to commons?
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Latka][Proposal] Make Jelly a required dependency?
Posted by Steve Downey <st...@netfolio.com>.
Well, commons-sandbox is supposed to be a whiteboard/scratchpad area. It's
also functioning as an incubator. I don't think the intent is for something
to live there forever. Having a dependency on a sandbox project is having a
dependency on something that has no plans of releasing.
The first step out of sandbox isn't a release. It's becoming an official
project.
For Jelly, given all the activity and commitment, being accepted as a project
ought to be a layup.
On Monday 14 October 2002 04:17 am, dion@multitask.com.au wrote:
> Is there a rule somewhere about not having sandbox components as a
> dependency? Or is this a general call to move Jelly to commons?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Latka][Proposal] Make Jelly a required dependency?
Posted by Steve Downey <st...@netfolio.com>.
On Monday 14 October 2002 05:11 pm, Costin Manolache wrote:
> James Strachan wrote:
> > I'd really like a stable release of Jelly out ASAP so migrating it to the
> > commons proper sounds like a great idea.
>
> There is no need for a stable release.
>
> All you need ( IMO ) is a community and a plan to eventually get
> a release.
In fact, I think it's a really bad idea to move from sandbox to a stable
release. Although jelly seems to have good visibility, I know I don't, as a
rule, look very carefully at sandbox projects. I've assumed that once they
get past the proof of concept stage, they'll be proposed as a commons
project. I suspect I'm not the only one. And that means that a sandbox
project gets limited review.
Jelly seems to be exceptional, in that there's a lot of interest and use, but
I'd hate to see a precedent that a sandbox project can go to immediate
release.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
sandbox milestones (was Re: [Latka][Proposal] Make Jelly a required dependency?)
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Costin Manolache" <cm...@yahoo.com>
> Ceki Gülcü wrote:
> > My suggestion would be to be patient and let Jelly mature a little
> > more, especially with regards to documentation. When you feel that you
> > are ready, then you can choose to go with commons or directly
> > jakarta. Being in a sandbox has advantages because your project can
> > grow slowly without user pressure. It's kind of like adolescence, when
you
> > are in it you can't wait to get out, but once out you cannot go back.
>
> Being is sandbox has the disadvantage that you can't have releases
> ( acording to the current rules for commons ). I think it would be usefull
> to have milestones and betas, so more people can use the code.
Agreed.
Right now quite a few projects depend on stuff thats in the sandbox or in
CVS but thats not been released yet. So for some time various sandbox
projects have had 'milestones' of some form. e.g.
http://www.ibiblio.org/maven/commons-jelly/jars/
So I guess we have a kinda-release-but-not-really-a-release mechanism for
sandbox components. It certainly allows folks to depend on a certain
snapshot of the code without requiring a full, 1.x, backwards compatible,
supported release.
> Moving to commons would also open the door to more commiters to get
> involved and eventually use it in other projects. Of course, that's
> something you may want or not - it'll start raising questions about
> backward compatibility and stability, and you may loose some control.
Its definitely something I want.
> Getting out of sandbox is usually a signal that things are getting serious
> :-).
Agreed. I'm all for getting serious :-).
James
-------
http://radio.weblogs.com/0112098/
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Latka][Proposal] Make Jelly a required dependency?
Posted by Costin Manolache <cm...@yahoo.com>.
Ceki Gülcü wrote:
> My suggestion would be to be patient and let Jelly mature a little
> more, especially with regards to documentation. When you feel that you
> are ready, then you can choose to go with commons or directly
> jakarta. Being in a sandbox has advantages because your project can
> grow slowly without user pressure. It's kind of like adolescence, when you
> are in it you can't wait to get out, but once out you cannot go back.
Being is sandbox has the disadvantage that you can't have releases
( acording to the current rules for commons ). I think it would be usefull
to have milestones and betas, so more people can use the code.
Moving to commons would also open the door to more commiters to get
involved and eventually use it in other projects. Of course, that's
something you may want or not - it'll start raising questions about
backward compatibility and stability, and you may loose some control.
Getting out of sandbox is usually a signal that things are getting serious
:-).
Costin
>
> At 11:38 15.10.2002 +0100, James Strachan wrote:
>>I agree with both your and Craig's opinions on the matter. I'm finding it
>>hard to decide either way. I think on balance I'd kinda rather keep around
>>the Commons too I think; though I was a bit unsure if Jelly was becoming a
>>bit too 'framework'-ish for commons. The core of Jelly should be small and
>>embeddable and so fits the idea of a commons component. Though it was the
>>various plugin libraries which are kinda like sub-projects that made me
>>think Jelly maybe should maybe be a top level project with a common-core
>>and many independent sub-projects. Hopefully the Jelly build process will
>>get sorted out soon so that it will become much more modular so its easier
>>for folks to just embed what they need.
>>
>>So should Jelly stay in commons or be a top level project? I don't really
>>feel strong enough either way really, so I'm tempted to err on the side of
>>caution and recommend it stays in commons but maybe, like httpclient, have
>>a seperate mail lists to avoid folks not interested in Jelly getting
>>bombarded with mail.
>>
>>I'll call a vote to promote Jelly to commons proper shortly. If we decide
>>later on that Jelly should move out of commons to a top level project we
>>can cross that bridge when we come to it. How's that sound?
>>
>>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
--
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Latka][Proposal] Make Jelly a required dependency?
Posted by Morgan Delagrange <md...@yahoo.com>.
Also wrt. moving to a top level project, there are the
pragmatic concerns of repackaging the code, especially
who knows how many Jelly tag implementations external
to the component. Jelly may be a victim of its own
success. ;)
--- Ceki G�lc� <ce...@qos.ch> wrote:
>
> James,
>
> My suggestion would be to be patient and let Jelly
> mature a little
> more, especially with regards to documentation. When
> you feel that you
> are ready, then you can choose to go with commons or
> directly
> jakarta. Being in a sandbox has advantages because
> your project can
> grow slowly without user pressure. It's kind of like
> adolescence, when you
> are in it you can't wait to get out, but once out
> you cannot go back.
>
> At 11:38 15.10.2002 +0100, James Strachan wrote:
> >I agree with both your and Craig's opinions on the
> matter. I'm finding it
> >hard to decide either way. I think on balance I'd
> kinda rather keep around
> >the Commons too I think; though I was a bit unsure
> if Jelly was becoming a
> >bit too 'framework'-ish for commons. The core of
> Jelly should be small and
> >embeddable and so fits the idea of a commons
> component. Though it was the
> >various plugin libraries which are kinda like
> sub-projects that made me
> >think Jelly maybe should maybe be a top level
> project with a common-core and
> >many independent sub-projects. Hopefully the Jelly
> build process will get
> >sorted out soon so that it will become much more
> modular so its easier for
> >folks to just embed what they need.
> >
> >So should Jelly stay in commons or be a top level
> project? I don't really
> >feel strong enough either way really, so I'm
> tempted to err on the side of
> >caution and recommend it stays in commons but
> maybe, like httpclient, have a
> >seperate mail lists to avoid folks not interested
> in Jelly getting bombarded
> >with mail.
> >
> >I'll call a vote to promote Jelly to commons proper
> shortly. If we decide
> >later on that Jelly should move out of commons to a
> top level project we can
> >cross that bridge when we come to it. How's that
> sound?
> >
> >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:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Latka][Proposal] Make Jelly a required dependency?
Posted by Ceki Gülcü <ce...@qos.ch>.
James,
My suggestion would be to be patient and let Jelly mature a little
more, especially with regards to documentation. When you feel that you
are ready, then you can choose to go with commons or directly
jakarta. Being in a sandbox has advantages because your project can
grow slowly without user pressure. It's kind of like adolescence, when you
are in it you can't wait to get out, but once out you cannot go back.
At 11:38 15.10.2002 +0100, James Strachan wrote:
>I agree with both your and Craig's opinions on the matter. I'm finding it
>hard to decide either way. I think on balance I'd kinda rather keep around
>the Commons too I think; though I was a bit unsure if Jelly was becoming a
>bit too 'framework'-ish for commons. The core of Jelly should be small and
>embeddable and so fits the idea of a commons component. Though it was the
>various plugin libraries which are kinda like sub-projects that made me
>think Jelly maybe should maybe be a top level project with a common-core and
>many independent sub-projects. Hopefully the Jelly build process will get
>sorted out soon so that it will become much more modular so its easier for
>folks to just embed what they need.
>
>So should Jelly stay in commons or be a top level project? I don't really
>feel strong enough either way really, so I'm tempted to err on the side of
>caution and recommend it stays in commons but maybe, like httpclient, have a
>seperate mail lists to avoid folks not interested in Jelly getting bombarded
>with mail.
>
>I'll call a vote to promote Jelly to commons proper shortly. If we decide
>later on that Jelly should move out of commons to a top level project we can
>cross that bridge when we come to it. How's that sound?
>
>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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Latka][Proposal] Make Jelly a required dependency?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 15 Oct 2002, James Strachan wrote:
>
> I'll call a vote to promote Jelly to commons proper shortly. If we decide
> later on that Jelly should move out of commons to a top level project we can
> cross that bridge when we come to it. How's that sound?
>
Sounds sensible.
> James
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Latka][Proposal] Make Jelly a required dependency?
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Costin Manolache" <cm...@yahoo.com>
> James Strachan wrote:
> > Though I am having second thoughts on whether Commons is the right place
> > for Jelly; maybe it should be a top level Jakarta project? Jelly started
> > out as a little reusable XML scripting engine that could be embedded
> > anywhere and is increasingly growing in scope to have all kinds of
add-on
> > libraries like JellyUnit, JellySwing and to do things like SOAP
scripting
> > (via Apache Axis).
>
> If jelly commiters want it to be a top level jakarta project, I'm
> sure it can happen.
>
> I would presonally prefer to see it as a commons project. It can have
> its own list ( like httpclient ), but I think it would benefit from
> the low-entry barier, and given the ammount of plugins it has
> it would be much easier for people to contribute to it.
>
> It would also be much easier for other project to rely on jelly.
>
> That doesn't mean I'm against it as top-level, just that I think it
> would be _much_ better for jelly to be a common component.
I agree with both your and Craig's opinions on the matter. I'm finding it
hard to decide either way. I think on balance I'd kinda rather keep around
the Commons too I think; though I was a bit unsure if Jelly was becoming a
bit too 'framework'-ish for commons. The core of Jelly should be small and
embeddable and so fits the idea of a commons component. Though it was the
various plugin libraries which are kinda like sub-projects that made me
think Jelly maybe should maybe be a top level project with a common-core and
many independent sub-projects. Hopefully the Jelly build process will get
sorted out soon so that it will become much more modular so its easier for
folks to just embed what they need.
So should Jelly stay in commons or be a top level project? I don't really
feel strong enough either way really, so I'm tempted to err on the side of
caution and recommend it stays in commons but maybe, like httpclient, have a
seperate mail lists to avoid folks not interested in Jelly getting bombarded
with mail.
I'll call a vote to promote Jelly to commons proper shortly. If we decide
later on that Jelly should move out of commons to a top level project we can
cross that bridge when we come to it. How's that sound?
James
-------
http://radio.weblogs.com/0112098/
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Latka][Proposal] Make Jelly a required dependency?
Posted by Costin Manolache <cm...@yahoo.com>.
James Strachan wrote:
> I'd really like a stable release of Jelly out ASAP so migrating it to the
> commons proper sounds like a great idea.
There is no need for a stable release.
All you need ( IMO ) is a community and a plan to eventually get
a release.
> Though I am having second thoughts on whether Commons is the right place
> for Jelly; maybe it should be a top level Jakarta project? Jelly started
> out as a little reusable XML scripting engine that could be embedded
> anywhere and is increasingly growing in scope to have all kinds of add-on
> libraries like JellyUnit, JellySwing and to do things like SOAP scripting
> (via Apache Axis).
If jelly commiters want it to be a top level jakarta project, I'm
sure it can happen.
I would presonally prefer to see it as a commons project. It can have
its own list ( like httpclient ), but I think it would benefit from
the low-entry barier, and given the ammount of plugins it has
it would be much easier for people to contribute to it.
It would also be much easier for other project to rely on jelly.
That doesn't mean I'm against it as top-level, just that I think it
would be _much_ better for jelly to be a common component.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Latka][Proposal] Make Jelly a required dependency?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
bob mcwhirter wrote:
>>Though I am having second thoughts on whether Commons is the right place for
>>Jelly; maybe it should be a top level Jakarta project?
+1
> Been waiting for this. I'm going to assume it's a vote...
>
> +1
Make him do a proposal and submit it to Jakarta General.
>>So I'm starting to think it needs to be a top level project with its own
>>sub-projects. Do others think this is a good idea? Either way I'd like to
>>see Jelly promoted very soon.
>
>
> +1
>
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Latka][Proposal] Make Jelly a required dependency?
Posted by bob mcwhirter <bo...@werken.com>.
> Though I am having second thoughts on whether Commons is the right place for
> Jelly; maybe it should be a top level Jakarta project?
Been waiting for this. I'm going to assume it's a vote...
+1
> So I'm starting to think it needs to be a top level project with its own
> sub-projects. Do others think this is a good idea? Either way I'd like to
> see Jelly promoted very soon.
+1
-bob
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [joran] example (was Re: [Latka][Proposal] Make Jelly a
required dependency?)
Posted by Ceki Gülcü <ce...@qos.ch>.
Here is a sample log4j config file in XML:
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<log4j:configuration debug="true"
xmlns:log4j='http://jakarta.apache.org/log4j/'>
<appender name="CON" class="org.apache.log4j.ConsoleAppender">
<param name="Threshold" value="INFO"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%5p [%t] %c - %m%n"/>
</layout>
</appender>
<appender name="FOO" class="org.apache.log4j.FileAppender">
<param name="File" value="foo.log"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%r %p %t %c - %m%n"/>
</layout>
</appender>
<appender name="UNUSED" class="org.apache.log4j.net.SMTPAppender">
<param name="To" value="ceki@apache.org"/>
<param name="Host" value="xyz.com"/>
<layout class="org.apache.log4j.HTMLLayout"/>
</appender>
<logger name="com.foo">
<level value ="info" />
<appender-ref ref="FOO" />
</logger>
<root>
<level value ="debug" />
<appender-ref ref="CON" />
</root>
</log4j:configuration>
The noteworthy point is that the appender element is used only if root
or a logger element references it. For example, the UNUSED appender,
which is not referenced by any root or logger element, will not be
created nor configured. I call this the 0th Property.
Property 0: It's the root or loggers elements which "drive"
the appender elements.
Another interesting point is that different appender elements may have
different nested elements which must be evaluated differently. For
example,
<appender name="EMAIL" class="org.apache.log4j.net.SMTPAppender">
<param name="To" value="ceki@apache.org"/>
<param name="Host" value="xyz.com"/>
<layout class="org.apache.log4j.HTMLLayout"/>
<trigger class="org.apache.log4j.someClass"> <--- trigger is a
special tag
<param name="maxCount" value="1000"/>
</trigger>
</appender>
<trigger> is an SMTPAppender specific tag.
Another example,
<appender name="ROLLING" class="org.apache.log4j.RollingAppender">
<param name="File" value="comfoo.log"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%r %p %t %c - %m%n"/>
</layout>
<rolloverStrategy class="org.apache.log4j.SizeStrategy"> <-- special tag
<param name="maxSize" value="100KB"/>
</rolloverStrategy>
<namingStrategy class="org.apache.log4j.SuffixStrategy"> <-- special tag
<param name="type" value="numerical"/>
<param max="max" value="-1"/>
</rolloverStrategy>
</appender>
in the above example <rolloverStrategy> and <namingStrategy> are
RollingAppender specific tags.
Log4j could support such tags using the addXXX paradigm that Ant uses
for its tasks.
The remaining desired properties are
1) low redundancy in the processing code
2) ability to parse totally unknown tags that are *not*
nested within primary level tasks, e.g. <root>, <logger>, <appender>
tags.
I think that a rule based system such as Digester can take care of
properties 1 and 2 but not property 0 defined above. Can jelly?
BTW, am I making any sense?
At 17:00 14.10.2002 +0100, James Strachan wrote:
>From: "Ceki Gülcü" <ce...@qos.ch>
> >> Have you any examples of what joran
> >>might look like yet?
> >
> > No, I do not have examples, except in my head.
>
>Any chance you could type a snippet of an example thats in your head down in
>an email; I'm interested to hear what you were thinking of.
>
> > Moreover, one wonders at the
> > sanity of the Joran enterprise when a library like Jelly is already
> > available.
>
>Jelly can be molded into many shapes via libraries so maybe Jelly could
>implement Joran; however thats purely an implementation detail. Lets ponder
>a little on what Joran could look like to an end user first before worrying
>about such details.
>
>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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[joran] example (was Re: [Latka][Proposal] Make Jelly a required dependency?)
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Ceki Gülcü" <ce...@qos.ch>
>> Have you any examples of what joran
>>might look like yet?
>
> No, I do not have examples, except in my head.
Any chance you could type a snippet of an example thats in your head down in
an email; I'm interested to hear what you were thinking of.
> Moreover, one wonders at the
> sanity of the Joran enterprise when a library like Jelly is already
> available.
Jelly can be molded into many shapes via libraries so maybe Jelly could
implement Joran; however thats purely an implementation detail. Lets ponder
a little on what Joran could look like to an end user first before worrying
about such details.
James
-------
http://radio.weblogs.com/0112098
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Latka][Proposal] Make Jelly a required dependency?
Posted by Ceki Gülcü <ce...@qos.ch>.
At 15:53 14.10.2002 +0100, James Strachan wrote:
>From: "Ceki Gülcü" <ce...@qos.ch>
> > 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
sanity of the Joran enterprise when a library like Jelly is already
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Latka][Proposal] Make Jelly a required dependency?
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Ceki Gülcü" <ce...@qos.ch>
> 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.
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?
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?
James
-------
http://radio.weblogs.com/0112098/
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Latka][Proposal] Make Jelly a required dependency?
Posted by Ceki Gülcü <ce...@qos.ch>.
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.
At 14:33 14.10.2002 +0100, James Strachan wrote:
>From: "Nicola Ken Barozzi" <ni...@apache.org>
> > dion@multitask.com.au wrote:
> > > Is there a rule somewhere about not having sandbox components as a
> > > dependency? Or is this a general call to move Jelly to commons?
> >
> > It's really time Jelly goes to Commons proper, don't you think?
> > It's more active than Latka itself ATM, and used by more and more
> > Jakarta projects.
> >
> > +1
> >
> > Let's see the plan :-)
>
>:-)
>
>I'd really like a stable release of Jelly out ASAP so migrating it to the
>commons proper sounds like a great idea.
>
>Though I am having second thoughts on whether Commons is the right place for
>Jelly; maybe it should be a top level Jakarta project? Jelly started out as
>a little reusable XML scripting engine that could be embedded anywhere and
>is increasingly growing in scope to have all kinds of add-on libraries like
>JellyUnit, JellySwing and to do things like SOAP scripting (via Apache
>Axis).
>
>So I'm starting to think it needs to be a top level project with its own
>sub-projects. Do others think this is a good idea? Either way I'd like to
>see Jelly promoted very soon.
>
>Incidentally Jelly also has dependencies on Jexl which would need to be
>promoted to the commons proper too before a release could be made.
>
>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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Latka][Proposal] Make Jelly a required dependency?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 14 Oct 2002, James Strachan wrote:
>
> So I'm starting to think it needs to be a top level project with its own
> sub-projects. Do others think this is a good idea? Either way I'd like to
> see Jelly promoted very soon.
>
If the plan is to have Jelly be a "framework" of its own accord, top-level
is definitely the way to go. Given the amount of interest in it, that
makes a lot of sense to me.
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Latka][Proposal] Make Jelly a required dependency?
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Nicola Ken Barozzi" <ni...@apache.org>
> dion@multitask.com.au wrote:
> > Is there a rule somewhere about not having sandbox components as a
> > dependency? Or is this a general call to move Jelly to commons?
>
> It's really time Jelly goes to Commons proper, don't you think?
> It's more active than Latka itself ATM, and used by more and more
> Jakarta projects.
>
> +1
>
> Let's see the plan :-)
:-)
I'd really like a stable release of Jelly out ASAP so migrating it to the
commons proper sounds like a great idea.
Though I am having second thoughts on whether Commons is the right place for
Jelly; maybe it should be a top level Jakarta project? Jelly started out as
a little reusable XML scripting engine that could be embedded anywhere and
is increasingly growing in scope to have all kinds of add-on libraries like
JellyUnit, JellySwing and to do things like SOAP scripting (via Apache
Axis).
So I'm starting to think it needs to be a top level project with its own
sub-projects. Do others think this is a good idea? Either way I'd like to
see Jelly promoted very soon.
Incidentally Jelly also has dependencies on Jexl which would need to be
promoted to the commons proper too before a release could be made.
James
-------
http://radio.weblogs.com/0112098/
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Latka][Proposal] Make Jelly a required dependency?
Posted by Steve Downey <st...@netfolio.com>.
On Monday 14 October 2002 04:49 am, dion@multitask.com.au wrote:
> Nicola Ken Barozzi <ni...@apache.org> wrote on 14/10/2002 06:09:54 PM:
> > dion@multitask.com.au wrote:
> > > Is there a rule somewhere about not having sandbox components as a
> > > dependency? Or is this a general call to move Jelly to commons?
> >
> > It's really time Jelly goes to Commons proper, don't you think?
>
> Yes, I do. But I'm more interested in whether there is a rule somewhere
> about sandbox components as dependencies, since that sparked Costin's
> comments.
I don't think it's a 'rule'. Just common sense. Commons-sandbox code is
unofficial, and could easily be abandoned, or repudiated, or the API changed
wildly. Since arguing that a particular project wouldn't be is pretty much
the same as saying it should be accepted into commons (or some other project,
or a top level project, ...), I think Costin is saying that step ought to be
done first. It shows there really is the level of support there for other
projects to depend on it.
It's about risk management.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Latka][Proposal] Make Jelly a required dependency?
Posted by di...@multitask.com.au.
Nicola Ken Barozzi <ni...@apache.org> wrote on 14/10/2002 06:09:54 PM:
>
> dion@multitask.com.au wrote:
> > Is there a rule somewhere about not having sandbox components as a
> > dependency? Or is this a general call to move Jelly to commons?
>
> It's really time Jelly goes to Commons proper, don't you think?
Yes, I do. But I'm more interested in whether there is a rule somewhere
about sandbox components as dependencies, since that sparked Costin's
comments.
> It's more active than Latka itself ATM, and used by more and more
> Jakarta projects.
It's more active than most of commons.......
> +1
>
> Let's see the plan :-)
Go for it :)
--
dIon Gillard, Multitask Consulting
Work: http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers
Re: [Latka][Proposal] Make Jelly a required dependency?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
dion@multitask.com.au wrote:
> Is there a rule somewhere about not having sandbox components as a
> dependency? Or is this a general call to move Jelly to commons?
It's really time Jelly goes to Commons proper, don't you think?
It's more active than Latka itself ATM, and used by more and more
Jakarta projects.
+1
Let's see the plan :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Latka][Proposal] Make Jelly a required dependency?
Posted by Costin Manolache <cm...@yahoo.com>.
dion@multitask.com.au wrote:
> "Craig R. McClanahan" <cr...@apache.org> wrote on 15/10/2002 02:20:01
> AM:
>
>>
>>
>> On Mon, 14 Oct 2002 dion@multitask.com.au wrote:
>>
>> >
>> > Is there a rule somewhere about not having sandbox components as a
>> > dependency?
>>
>> At a minimum, I think you can infer an indirect rule from the following
>> conventions:
>>
>> * You can't release a Sandbox component at all -- it's just
>> a wad-o-code.
>>
>> * You can't release a Commons component that depends on
>> non-released other code.
>>
>> Struts has some interim dependencies on a sandbox component or two, but
>> that will need to be resolved before a final Struts 1.1 release.
>
> Craig,
>
> out of curiosity, do you know where these conventions are laid out?
The first part was made very clear when the commons was created -
I don't know where it is actually written, but I fought a lot
against it and I remember quite well losing the vote. ( and
IMO the majority was right :-)
The second is pretty obvious since otherwise the component
won't work well with a missing dependency.
> Did I notice struts having 1.1 beta release(s) with sandbox dependencies?
Struts is a standalone project that makes its own decisions. If no struts
commiter voted against the release, then there's nothing we can do,
they don't have to follow jakarta-commons rules.
As a matter of fact, tomcat has major releases with sandbox dependencies.
IMO a majority of commiters can release whatever it wants. If struts
or tomcat or another project wants to release a sandbox component - they
can do that, there's no rule against this. The rules applies only on
releasing sandbox components without a vote ( out of jakarta-commons )
--
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Latka][Proposal] Make Jelly a required dependency?
Posted by di...@multitask.com.au.
"Craig R. McClanahan" <cr...@apache.org> wrote on 15/10/2002 02:20:01
AM:
>
>
> On Mon, 14 Oct 2002 dion@multitask.com.au wrote:
>
> >
> > Is there a rule somewhere about not having sandbox components as a
> > dependency?
>
> At a minimum, I think you can infer an indirect rule from the following
> conventions:
>
> * You can't release a Sandbox component at all -- it's just
> a wad-o-code.
>
> * You can't release a Commons component that depends on
> non-released other code.
>
> Struts has some interim dependencies on a sandbox component or two, but
> that will need to be resolved before a final Struts 1.1 release.
Craig,
out of curiosity, do you know where these conventions are laid out?
Did I notice struts having 1.1 beta release(s) with sandbox dependencies?
> Craig
Don't get me wrong, I'm all for this as a 'rule', as it forces stuff out
of the sandbox, but I like things to be documented so the next person
knows too.
--
dIon Gillard, Multitask Consulting
Work: http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers
Re: [Latka][Proposal] Make Jelly a required dependency?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 14 Oct 2002 dion@multitask.com.au wrote:
>
> Is there a rule somewhere about not having sandbox components as a
> dependency?
At a minimum, I think you can infer an indirect rule from the following
conventions:
* You can't release a Sandbox component at all -- it's just
a wad-o-code.
* You can't release a Commons component that depends on
non-released other code.
Struts has some interim dependencies on a sandbox component or two, but
that will need to be resolved before a final Struts 1.1 release.
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Latka][Proposal] Make Jelly a required dependency?
Posted by di...@multitask.com.au.
Is there a rule somewhere about not having sandbox components as a
dependency? Or is this a general call to move Jelly to commons?
--
dIon Gillard, Multitask Consulting
Work: http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers
news <ne...@main.gmane.org> wrote on 14/10/2002 04:07:16 PM:
> The only problem is that jelly is still in sandbox.
>
> be in a suficiently stable state ( if other components
> start to have deps ). So it may be the time for someone
> to make the proposal for commons.
>
> Costin
>
>
> Morgan Delagrange wrote:
>
> > Hey all,
> >
> > I finished a rough cut conversion of the Latka tags
> > and validators to Jelly. The Jelly tags have syntax
> > identical to the previous Latka tags. I think it will
> > be pretty easy to emulate Latka variables inside the
> > Jelly expression language (JEXL). With a patch I made
> > to Jelly this week, I think even the lack of a
> > namespace declaration in existing scripts will not be
> > a problem.
> >
> > I believe that the functionality of the Jelly tags is
> > actually a complete superset of the previous
> > implementation. The command line interface should be
> > able to function unchanged if converted to a Jelly
> > backend, but the new tags will make it much easier to
> > run Latka inside applications like Ant and JUnit. I
> > propose that we make Jelly one of Latka's
> > dependencies, so that we can remove the XML handlers
> > and processors that support the previous tags. In my
> > view, the Jelly implementation is much cleaner and
> > will render the old tags unnecessary.
> >
> > - Morgan
> >
> > =====
> > Morgan Delagrange
> > http://jakarta.apache.org/taglibs
> > http://jakarta.apache.org/commons
> > http://axion.tigris.org
> > http://jakarta.apache.org/watchdog
> >
> > __________________________________________________
> > Do you Yahoo!?
> > Faith Hill - Exclusive Performances, Videos & More
> > http://faith.yahoo.com
>
> --
> Costin
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
Re: [Latka][Proposal] Make Jelly a required dependency?
Posted by Costin Manolache <cm...@yahoo.com>.
The only problem is that jelly is still in sandbox.
be in a suficiently stable state ( if other components
start to have deps ). So it may be the time for someone
to make the proposal for commons.
Costin
Morgan Delagrange wrote:
> Hey all,
>
> I finished a rough cut conversion of the Latka tags
> and validators to Jelly. The Jelly tags have syntax
> identical to the previous Latka tags. I think it will
> be pretty easy to emulate Latka variables inside the
> Jelly expression language (JEXL). With a patch I made
> to Jelly this week, I think even the lack of a
> namespace declaration in existing scripts will not be
> a problem.
>
> I believe that the functionality of the Jelly tags is
> actually a complete superset of the previous
> implementation. The command line interface should be
> able to function unchanged if converted to a Jelly
> backend, but the new tags will make it much easier to
> run Latka inside applications like Ant and JUnit. I
> propose that we make Jelly one of Latka's
> dependencies, so that we can remove the XML handlers
> and processors that support the previous tags. In my
> view, the Jelly implementation is much cleaner and
> will render the old tags unnecessary.
>
> - Morgan
>
> =====
> Morgan Delagrange
> http://jakarta.apache.org/taglibs
> http://jakarta.apache.org/commons
> http://axion.tigris.org
> http://jakarta.apache.org/watchdog
>
> __________________________________________________
> Do you Yahoo!?
> Faith Hill - Exclusive Performances, Videos & More
> http://faith.yahoo.com
--
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jelly]BreakTag
Posted by James Strachan <ja...@yahoo.co.uk>.
Hi Vinay
I've finally gotten around to adding a BreakTag. The original patch modified
the Script objects, which are the static parsed image of a script and can be
cached and reused across threads. I changed the implementation to use
exception throwing to break out of loops. So to terminate from a <forEach>
or <while> loop, something just needs to throw a BreakException.
Thanks for the patch Vinay, its all applied to CVS HEAD now.
James
-------
http://radio.weblogs.com/0112098/
----- Original Message -----
From: "Vinay Chandran" <sa...@yahoo.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Sunday, October 13, 2002 4:53 AM
Subject: [Jelly]BreakTag
> Hi,
>
> [Attached BreakTag.java]
>
> BreakTag [ <break if="condition"/> ] tag allows one to
> conditionally
> break out of a script block without executing any
> subsequent scripts within its parent .
> The natural use is to break out of a <foreach/> ,
> <while/> loop .
> Break works in the context of any parent tag and thus
> one can use
> to conditionaly break out of the entire script itself.
> [ testBreak.jelly attached ]
>
> Regards,
> Vinay.
>
> Patch to CoreTagLibrary
> ------------------------
> 97a98
> > registerTag("break",BreakTag.class);
>
>
>
> __________________________________________________
> Do you Yahoo!?
> Faith Hill - Exclusive Performances, Videos & More
> http://faith.yahoo.com
----------------------------------------------------------------------------
----
> <?xml version="1.0"?>
>
> <!-- displays the current command line arguments -->
>
>
> <j:jelly xmlns:j="jelly:core">
>
> <!-- Setting a boolean var to true -->
> <j:set var="exitCompletely" value="true"/>
>
> <arguments>
> <j:forEach var="arg" items="${args}" begin="1">
> <!-- Break cond for the foreach loop -->
> <j:break if='${arg=="three"}'/>
> <argument>${arg}</argument>
> </j:forEach>
> </arguments>
>
> <j:break if='${exitCompletely}'/>
> **************************
> These Should NOT appear
> **************************
> </j:jelly>
>
----------------------------------------------------------------------------
----
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[Jelly]BreakTag
Posted by Vinay Chandran <sa...@yahoo.com>.
Hi,
[Attached BreakTag.java]
BreakTag [ <break if="condition"/> ] tag allows one to
conditionally
break out of a script block without executing any
subsequent scripts within its parent .
The natural use is to break out of a <foreach/> ,
<while/> loop .
Break works in the context of any parent tag and thus
one can use
to conditionaly break out of the entire script itself.
[ testBreak.jelly attached ]
Regards,
Vinay.
Patch to CoreTagLibrary
------------------------
97a98
> registerTag("break",BreakTag.class);
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
Re: [Latka][Proposal] Make Jelly a required dependency?
Posted by di...@multitask.com.au.
I'm a big +1 on this. Using Jelly as the underlying mechanism takes a lot
of the complexity out of Latka.
--
dIon Gillard, Multitask Consulting
Work: http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers
Morgan Delagrange <md...@yahoo.com> wrote on 12/10/2002 03:12:12 AM:
> Ah I should note this. The only incompatibility I see
> with the new Jelly tags is wrt. existing custom
> validators. Any XML handlers written for the old tags
> would have to be reimplemented as Jelly tags. It's
> not a difficult task (it takes less than a few minutes
> in most cases), but it does break compatibility.
> Existing Validator classes should work unchanged.
>
> --- Morgan Delagrange <md...@yahoo.com> wrote:
> > Hey all,
> >
> > I finished a rough cut conversion of the Latka tags
> > and validators to Jelly. The Jelly tags have syntax
> > identical to the previous Latka tags. I think it
> > will
> > be pretty easy to emulate Latka variables inside the
> > Jelly expression language (JEXL). With a patch I
> > made
> > to Jelly this week, I think even the lack of a
> > namespace declaration in existing scripts will not
> > be
> > a problem.
> >
> > I believe that the functionality of the Jelly tags
> > is
> > actually a complete superset of the previous
> > implementation. The command line interface should
> > be
> > able to function unchanged if converted to a Jelly
> > backend, but the new tags will make it much easier
> > to
> > run Latka inside applications like Ant and JUnit. I
> > propose that we make Jelly one of Latka's
> > dependencies, so that we can remove the XML handlers
> > and processors that support the previous tags. In
> > my
> > view, the Jelly implementation is much cleaner and
> > will render the old tags unnecessary.
> >
> > - Morgan
> >
> > =====
> > Morgan Delagrange
> > http://jakarta.apache.org/taglibs
> > http://jakarta.apache.org/commons
> > http://axion.tigris.org
> > http://jakarta.apache.org/watchdog
> >
> > __________________________________________________
> > Do you Yahoo!?
> > Faith Hill - Exclusive Performances, Videos & More
> > http://faith.yahoo.com
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
>
> =====
> Morgan Delagrange
> http://jakarta.apache.org/taglibs
> http://jakarta.apache.org/commons
> http://axion.tigris.org
> http://jakarta.apache.org/watchdog
>
> __________________________________________________
> Do you Yahoo!?
> Faith Hill - Exclusive Performances, Videos & More
> http://faith.yahoo.com
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
Re: [Latka][Proposal] Make Jelly a required dependency?
Posted by Morgan Delagrange <md...@yahoo.com>.
Ah I should note this. The only incompatibility I see
with the new Jelly tags is wrt. existing custom
validators. Any XML handlers written for the old tags
would have to be reimplemented as Jelly tags. It's
not a difficult task (it takes less than a few minutes
in most cases), but it does break compatibility.
Existing Validator classes should work unchanged.
--- Morgan Delagrange <md...@yahoo.com> wrote:
> Hey all,
>
> I finished a rough cut conversion of the Latka tags
> and validators to Jelly. The Jelly tags have syntax
> identical to the previous Latka tags. I think it
> will
> be pretty easy to emulate Latka variables inside the
> Jelly expression language (JEXL). With a patch I
> made
> to Jelly this week, I think even the lack of a
> namespace declaration in existing scripts will not
> be
> a problem.
>
> I believe that the functionality of the Jelly tags
> is
> actually a complete superset of the previous
> implementation. The command line interface should
> be
> able to function unchanged if converted to a Jelly
> backend, but the new tags will make it much easier
> to
> run Latka inside applications like Ant and JUnit. I
> propose that we make Jelly one of Latka's
> dependencies, so that we can remove the XML handlers
> and processors that support the previous tags. In
> my
> view, the Jelly implementation is much cleaner and
> will render the old tags unnecessary.
>
> - Morgan
>
> =====
> Morgan Delagrange
> http://jakarta.apache.org/taglibs
> http://jakarta.apache.org/commons
> http://axion.tigris.org
> http://jakarta.apache.org/watchdog
>
> __________________________________________________
> Do you Yahoo!?
> Faith Hill - Exclusive Performances, Videos & More
> http://faith.yahoo.com
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>