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/12/27 19:59:32 UTC
[Jelly] Release Issue 1 - dependencies
Hey all,
So far only Bob has voiced a concern with preparing to
release a Jelly beta, and I believe his only concern
is whether or not to release it under the Commons
umbrella. So I'm going to start raising some release
issues, and I'll steer clear of anything relating to
packaging for now, just in case someone wants to
propose moving Jelly soon. (Personally, I'm +0 on the
idea; sounds like potentially good exposure for Jelly,
but it doesn't scratch any itches for me. I still
volunteer as release manager, regardless of Jelly's
location in Jakarta.)
So here's my first issue:
http://jakarta.apache.org/commons/sandbox/jelly/dependencies.html
Holy cow. It's not the number of dependencies that
concerns me, it's the number of dependencies based on
snapshots and alphas.
I know we're already considering breaking up Jelly
into multiple jars. Thoughts on how to do that best?
One possibility is two jars: one for Jelly and the
core taglib, and another for all remaining tags.
Another possibility is three jars: one for Jelly and
the core taglib, one for "released" tags (i.e. tags
with stable dependencies), and one for "beta" tags
(i.e. tags based on unreleased dependencies). Or
maybe both or neither or something else entirely.
We might also want to consider employing separate CVS
trees for each taglib, in the style of Jakarta
Taglibs. That would make things like
identifying/tracking individual taglib dependencies
much simpler, although we'd have more maintenance
overhead and we'd have to find a way to make Maven
happy with the structure.
Regardless of how we structure the JARs and the CVS
repository, I think we should focus on identifying
dependencies specific to Jelly and the core tag
library, and once we have a solid list we should try
to obtain as many released versions as we can manage.
I'm uncomfortable releasing Jelly based on beta
dependencies, and I think including snapshots is
completely unworkable.
- 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!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jelly] Release Issue 1 - dependencies
Posted by di...@multitask.com.au.
news <ne...@main.gmane.org> wrote on 01/01/2003 04:49:41 PM:
> dion@multitask.com.au wrote:
> I differ on the cause of the first error. Let me provide as evidence
> for my opinion the following:
>
> http://cvs.apache.org/viewcvs.cgi/jakarta-
> commons/cli/src/java/org/apache/commons/cli/Attic/
>
> In particular, note the column marked "Age".
Cool. My bad. I'm upgrading Maven CVS to use the release version of CLI.
That one should be fixed in the next run.
> Now, lets take a look at the gump descriptor for maven:
>
> http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-
> gump/project/jakarta-turbine-maven.xml?rev=1.9&content-type=text/plain
Ah, I was looking at the descriptor in Maven's CVS. Which was up to date.
> Oh, and by the way, the jakarta-gump repository should now be open to
> all committers.
I've made some changes now I'm aware of it. Thanks.
> In
> http://cvs.apache.org/viewcvs.cgi/jakarta-gump/project/jakarta-
> turbine-maven.xml,
> I nine commits, two by rubys, one by donaldp, and five by bodewig. From
> my perspective, a number of us *ARE* trying, but I haven't seen much
> cooperation from *any* maven committer.
Well given I wasn't a committer on Gump, it would be hard to see commits
from me.
> But lets not focus on the past.... where should we go from here?
> > From what I can see the constructive steps from here are:
> > 1) Work out why grant, cli and werkz are not being picked up and
included
> > in the compile
> > 2) Get Graph2 gumpified
> > 3) Move the JellyJeezTagLibrary into Maven
> > 4) Split Jelly's taglibs up so that the core build process has fewer
> > dependencies.
>
> I think I've provided you enough info so that you can complete task 1?
I think that issue should now be fixed.
> I'll take task 2.
I can help. I'll generate a gump description if you like in CVS.
> Volunteers for tasks 3 and 4?
>
> And can #4 be done incrementally, with the httpclient taglib done first?
We need to rearrange the source tree to get this happening. I can take a
stab at it if James S. isn't about.
This is progress.
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jelly] Release Issue 1 - dependencies
Posted by Sam Ruby <ru...@apache.org>.
dion@multitask.com.au wrote:
>
> Ok, rather than doing something useful like fixing the gump descriptor,
> I'll respond to your email.
This actually is actually productive.
> 1) There may not be just one taglib, but splitting them out is relatively
> easy. There are no great cross dependencies in the code.
> 2) Usually very simple. The tags are small and self contained already.
> 3) Easy, but a lot of people would complain about missing functionality if
> it was a well used one.
OK, pick one. I'll gladly fix the gump descriptor once this is done and
explain what I did. Or talk you or any interested party through this.
> As for Maven and your link, read this:
> http://marc.theaimsgroup.com/?l=turbine-maven-dev&m=104057092409589&w=2
>
> You'll note:
> 1) None of the maven plugins are being compiled by this code. So the
> separation has already made this process easier. Imagine what the errors
> would look like if we added all the plugin dependencies in.
*very* scary.
> 2) The first error, along with others are because of dependencies that are
> listed by maven but Gump seems to be ignoring, e.g. cli, grant and werkz.
I differ on the cause of the first error. Let me provide as evidence
for my opinion the following:
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/cli/src/java/org/apache/commons/cli/Attic/
In particular, note the column marked "Age".
Now, lets take a look at the gump descriptor for maven:
http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-gump/project/jakarta-turbine-maven.xml?rev=1.9&content-type=text/plain
If you look closely, you will see commons-cli, and werkz *are* included.
commons-grant is not. Adding the dependency is as simple as adding:
<depend project="commons-grant"/>
Documentation for this element can be found at:
http://jakarta.apache.org/gump/project.html#depend
Oh, and by the way, the jakarta-gump repository should now be open to
all committers.
> 3) Some errors are caused by a missing dependency (commons-graph2).
> 3) Some of the code should be in Maven (JellyJeezTagLibrary) and has
> recently agreed to be moved out
> 4) Some of the code should be in Werkz (JellyBuildListener) and has
> recently been moved out
> 3) Of all the Jelly classes referenced (JellyException, JellyContext,
> XMLOutput, TagLibrary, Expression, AntTagLibrary, TagSupport,
> CoreTagLibrary, Script etc) all are in the Jelly 'core'.
>
> So the real reason for
> http://marc.theaimsgroup.com/?l=turbine-maven-dev&m=104057092409589&w=2 is
> that there hasn't been enough effort put into the Gump descriptor for
> Maven. Maven is already broken up and has very few non-core dependencies.
If you can describe in words what needs to be done, I can either talk
you through it, or will be willing to do it myself.
> So far, I've been the only Maven committer willing to put time into the
> Gump descriptor, and you seem to be more willing to post links to me than
> to work together to fix issues.
In
http://cvs.apache.org/viewcvs.cgi/jakarta-gump/project/jakarta-turbine-maven.xml,
I nine commits, two by rubys, one by donaldp, and five by bodewig. From
my perspective, a number of us *ARE* trying, but I haven't seen much
cooperation from *any* maven committer.
But lets not focus on the past.... where should we go from here?
> While we're in the link posting mode, maybe you can explain some things
> for me:
>
> 1)
> http://cvs.apache.org/viewcvs/jakarta-alexandria/proposal/gump/editor/lib/kunststoff.jar
> 2)
> http://cvs.apache.org/viewcvs/jakarta-alexandria/proposal/gump/editor/lib/LICENSE.kunstoff
>
> Q:
> 1) Why are jars stored in Gump's CVS?
> 2) I've been told by various people that GPL and LGPL jars are not to be
> stored in CVS. What is the official Apache position on that?
EEK! Removed.
I don't believe in jars in cvs, and gump itself does not depend on any
such. Apparently, Nicola Ken feels otherwise, and in support for an
editor which is intended to produce gump descriptors, he checked in some
jars. While this is against my personal preferences, I will not stand
in his way... except in issues like the kunstoff jar mentioned above, in
which case I intend to take quick and decisive action.
> If you seriously want to get Jelly and Maven building with Gump on a
> regular basis, work with me.
> I don't have a lot of knowledge about Gump. I can see its value, though.
>
> Posting links to failed builds doesn't help me - I read every one of them
> anyway. Awareness is not the issue.
>
> From what I can see the constructive steps from here are:
> 1) Work out why grant, cli and werkz are not being picked up and included
> in the compile
> 2) Get Graph2 gumpified
> 3) Move the JellyJeezTagLibrary into Maven
> 4) Split Jelly's taglibs up so that the core build process has fewer
> dependencies.
I think I've provided you enough info so that you can complete task 1?
I'll take task 2.
Volunteers for tasks 3 and 4?
And can #4 be done incrementally, with the httpclient taglib done first?
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jelly] Release Issue 1 - dependencies
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Sam Ruby" <ru...@apache.org>
> dion@multitask.com.au wrote:
> > The main issue at the moment is that Jelly needs to be split into core
and
> > various taglibs.
> >
> > I think jelly core has very few dependencies.
> >
> > Once it has separate sub-projects, it will make dependency tracking a
hell
> > of a lot easier.
>
> Questions:
>
> 1) How hard would it be to split out the *one* problematic taglib?
> 2) How hard would it be to fix the *one* problematic taglib?
> 3) How hard would it be to delete the *one* problematic taglib?
FWIW its not been the same one taglib thats been breaking the gump build.
Whilst the gump build has been failing, there have been various problems
along the way that have been fixed which were caused by lots of different
things and different taglibs. One of the most common problems has been the
out of date auto-generated Ant build file that doesn't always behave as the
Maven build does. e.g. the current failure GUMP is that there is a missing
dependency on a new, optional, taglib.
Though one thing that will definitely help is if we seperate out the 'core'
libraries, that rarely fail from the more problematic ones, it'll help
solidify the core Jelly GUMP build.
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: [Jelly] Release Issue 1 - dependencies
Posted by di...@multitask.com.au.
news <ne...@main.gmane.org> wrote on 31/12/2002 11:13:12 PM:
> dion@multitask.com.au wrote:
> > The main issue at the moment is that Jelly needs to be split into core
and
> > various taglibs.
> >
> > I think jelly core has very few dependencies.
> >
> > Once it has separate sub-projects, it will make dependency tracking a
hell
> > of a lot easier.
>
> Questions:
>
> 1) How hard would it be to split out the *one* problematic taglib?
> 2) How hard would it be to fix the *one* problematic taglib?
> 3) How hard would it be to delete the *one* problematic taglib?
>
> Now repeat the same questions for Maven.
>
> http://marc.theaimsgroup.com/?l=turbine-maven-dev&m=104063882211026&w=2
Ok, rather than doing something useful like fixing the gump descriptor,
I'll respond to your email.
1) There may not be just one taglib, but splitting them out is relatively
easy. There are no great cross dependencies in the code.
2) Usually very simple. The tags are small and self contained already.
3) Easy, but a lot of people would complain about missing functionality if
it was a well used one.
As for Maven and your link, read this:
http://marc.theaimsgroup.com/?l=turbine-maven-dev&m=104057092409589&w=2
You'll note:
1) None of the maven plugins are being compiled by this code. So the
separation has already made this process easier. Imagine what the errors
would look like if we added all the plugin dependencies in.
2) The first error, along with others are because of dependencies that are
listed by maven but Gump seems to be ignoring, e.g. cli, grant and werkz.
3) Some errors are caused by a missing dependency (commons-graph2).
3) Some of the code should be in Maven (JellyJeezTagLibrary) and has
recently agreed to be moved out
4) Some of the code should be in Werkz (JellyBuildListener) and has
recently been moved out
3) Of all the Jelly classes referenced (JellyException, JellyContext,
XMLOutput, TagLibrary, Expression, AntTagLibrary, TagSupport,
CoreTagLibrary, Script etc) all are in the Jelly 'core'.
So the real reason for
http://marc.theaimsgroup.com/?l=turbine-maven-dev&m=104057092409589&w=2 is
that there hasn't been enough effort put into the Gump descriptor for
Maven. Maven is already broken up and has very few non-core dependencies.
So far, I've been the only Maven committer willing to put time into the
Gump descriptor, and you seem to be more willing to post links to me than
to work together to fix issues.
While we're in the link posting mode, maybe you can explain some things
for me:
1)
http://cvs.apache.org/viewcvs/jakarta-alexandria/proposal/gump/editor/lib/kunststoff.jar
2)
http://cvs.apache.org/viewcvs/jakarta-alexandria/proposal/gump/editor/lib/LICENSE.kunstoff
Q:
1) Why are jars stored in Gump's CVS?
2) I've been told by various people that GPL and LGPL jars are not to be
stored in CVS. What is the official Apache position on that?
If you seriously want to get Jelly and Maven building with Gump on a
regular basis, work with me.
I don't have a lot of knowledge about Gump. I can see its value, though.
Posting links to failed builds doesn't help me - I read every one of them
anyway. Awareness is not the issue.
>From what I can see the constructive steps from here are:
1) Work out why grant, cli and werkz are not being picked up and included
in the compile
2) Get Graph2 gumpified
3) Move the JellyJeezTagLibrary into Maven
4) Split Jelly's taglibs up so that the core build process has fewer
dependencies.
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jelly] Release Issue 1 - dependencies
Posted by Sam Ruby <ru...@apache.org>.
dion@multitask.com.au wrote:
> The main issue at the moment is that Jelly needs to be split into core and
> various taglibs.
>
> I think jelly core has very few dependencies.
>
> Once it has separate sub-projects, it will make dependency tracking a hell
> of a lot easier.
Questions:
1) How hard would it be to split out the *one* problematic taglib?
2) How hard would it be to fix the *one* problematic taglib?
3) How hard would it be to delete the *one* problematic taglib?
Now repeat the same questions for Maven.
http://marc.theaimsgroup.com/?l=turbine-maven-dev&m=104063882211026&w=2
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jelly] Release Issue 1 - dependencies
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 2 Jan 2003, Rodney Waldhoff wrote:
> Date: Thu, 2 Jan 2003 10:18:55 -0800 (PST)
> From: Rodney Waldhoff <rw...@apache.org>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: [Jelly] Release Issue 1 - dependencies
>
> On Thu, 2 Jan 2003, Craig R. McClanahan wrote:
>
> >
> > This whole issue is why I have some misgivings about Jelly as a commons
> > component -- the functionality is great, but the dependency matrix for the
> > libraries is enormous.
> >
> > How about moving Jelly core *only* to commons proper, and starting a new
> > "jakarta-jelly-taglibs" (with independent but coordinated builds like
> > jakarta-taglibs) for all the tag libraries?
> >
>
> I'm also happy to see a core/taglib split, with independent but
> coordinated builds, and perhaps in some (many?) cases eventually moving
> the taglib more directly under the management of the project upon which it
> depends (e.g., jelly:quartz as an add-on to quartz, jelly:werkz as an
> add-on to werkz, etc.), but why not house this under the same module in
> CVS?
This certainly makes sense to *me*, but isn't it really up to the quartz
and werkz developers to decide if maintaining a library of Jelly tags is
worthwhile to them?
I think we can certainly make that easier on them if commons-jelly
contained only the core classes with stable APIs and minimal external
dependencies.
>
> I.e., for now:
>
> jakarta-commons/jelly/jelly-core
> jakarta-commons/jelly/jelly-taglibs/*
>
> and later:
>
> jakarta-jelly/jelly-core
> jakarta-jelly/jelly-taglibs/*
>
> producing (and releasing) several jars.
The latter would be OK with me, as long as a JAR file with just the core
was released separately. What I don't see is the value of doing this in
two steps instead of one, if this is the ultimate destination.
>
> I don't see the advantage of not having a common root cvs module, or more
> to the point I think I see some slight advantage to having one.
> (Although if you apply Craig's statement to "releases" instead of
> directories--why not move first toward a *release* of jelly-core only, I
> fully agree.)
Migrating to a top-level Jakarta subproject implies a package name change
(org.apache.commons.jelly -> org.apache.jelly) for everything that is
included. If we go with:
jakarta-commons/jelly (core APIs only)
jakarta-jelly-taglibs/* (all the libraries that are not
part of the project whose functionality
is being abstracted)
then we only break the "import" declarations on the existing tag library
implementations that are included with Jelly -- we don't break everyone's
private Jelly tags that depend on org.apache.commons.jelly today.
If we ultimately want a combined repository, that's fine; but doing it
earlier is much better than doing it later, IMHO. (But remember, I'm just
a non-committing Jelly user muttering to myself in the corner :-).
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jelly] Release Issue 1 - dependencies
Posted by Rodney Waldhoff <rw...@apache.org>.
On Thu, 2 Jan 2003, Morgan Delagrange wrote:
> 2. Jelly core stays in Commons, while tags become a
> Jakarta subproject (+1)
This is the one that seems odd to me (and I guess was the
implication of Craig's note that seemed odd to me as well), though I'm not
entirely sure why. I think maybe that splits a community across mailing
lists and karma-rights in a weird way, but one that is probably managable.
Another option might be to keep the org.apache.commons.jelly packaging,
even if jelly moves to a top level project. Perhaps permanently, perhaps
only until the next major release, or perhaps via deprecation of
o.a.c.jelly and delegation to o.a.jelly (using inclusive "or").
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jelly] Release Issue 1 - dependencies
Posted by Morgan Delagrange <md...@yahoo.com>.
--- Rodney Waldhoff <rw...@apache.org> wrote:
> On Thu, 2 Jan 2003, Craig R. McClanahan wrote:
>
> >
> > This whole issue is why I have some misgivings
> about Jelly as a commons
> > component -- the functionality is great, but the
> dependency matrix for the
> > libraries is enormous.
> >
> > How about moving Jelly core *only* to commons
> proper, and starting a new
> > "jakarta-jelly-taglibs" (with independent but
> coordinated builds like
> > jakarta-taglibs) for all the tag libraries?
> >
>
> I'm also happy to see a core/taglib split, with
> independent but
> coordinated builds, and perhaps in some (many?)
> cases eventually moving
> the taglib more directly under the management of the
> project upon which it
> depends (e.g., jelly:quartz as an add-on to quartz,
> jelly:werkz as an
> add-on to werkz, etc.), but why not house this under
> the same module in
> CVS?
>
> I.e., for now:
>
> jakarta-commons/jelly/jelly-core
> jakarta-commons/jelly/jelly-taglibs/*
>
> and later:
>
> jakarta-jelly/jelly-core
> jakarta-jelly/jelly-taglibs/*
>
> producing (and releasing) several jars.
>
> I don't see the advantage of not having a common
> root cvs module, or more
> to the point I think I see some slight advantage to
> having one.
I think the only reason to leave Jelly in Commons is
to avoid repackaging Jelly and its dependant Apache
applications (two inside Jakarta that I know of). I'm
amenable to:
1. Jelly core and tags stay in Commons (+1)
2. Jelly core stays in Commons, while tags become a
Jakarta subproject (+1)
3. Jelly core and tags become a Jakarta
subproject (+0)
Someone person or people would have to volunteer for
the third option however, since that involves some
extra work.
> (Although if you apply Craig's statement to
> "releases" instead of
> directories--why not move first toward a *release*
> of jelly-core only, I
> fully agree.)
Me too. I will probably volunteer to release some
subset of the non-core tags, but only after Jelly 1.0
is out there. Each tag should have independent
releases, version numbers, etc. A combo jar would be
a definite plus, so we should look at that too, but
IMO only after the individual releases are complete.
- Morgan
> >
> > Craig
> >
>
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jelly] Release Issue 1 - dependencies
Posted by Rodney Waldhoff <rw...@apache.org>.
On Thu, 2 Jan 2003, Craig R. McClanahan wrote:
>
> This whole issue is why I have some misgivings about Jelly as a commons
> component -- the functionality is great, but the dependency matrix for the
> libraries is enormous.
>
> How about moving Jelly core *only* to commons proper, and starting a new
> "jakarta-jelly-taglibs" (with independent but coordinated builds like
> jakarta-taglibs) for all the tag libraries?
>
I'm also happy to see a core/taglib split, with independent but
coordinated builds, and perhaps in some (many?) cases eventually moving
the taglib more directly under the management of the project upon which it
depends (e.g., jelly:quartz as an add-on to quartz, jelly:werkz as an
add-on to werkz, etc.), but why not house this under the same module in
CVS?
I.e., for now:
jakarta-commons/jelly/jelly-core
jakarta-commons/jelly/jelly-taglibs/*
and later:
jakarta-jelly/jelly-core
jakarta-jelly/jelly-taglibs/*
producing (and releasing) several jars.
I don't see the advantage of not having a common root cvs module, or more
to the point I think I see some slight advantage to having one.
(Although if you apply Craig's statement to "releases" instead of
directories--why not move first toward a *release* of jelly-core only, I
fully agree.)
>
> Craig
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jelly] Release Issue 1 - dependencies
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 2 Jan 2003, James Strachan wrote:
> Date: Thu, 2 Jan 2003 17:56:13 -0000
> From: James Strachan <ja...@yahoo.co.uk>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>,
> morgand@apache.org
> Subject: Re: [Jelly] Release Issue 1 - dependencies
>
> From: "Morgan Delagrange" <md...@yahoo.com>
> > I'm going to try to move at least one taglib (probably
> > http) to a separate build today. It won't be pretty,
> > but it should be servicable. For starters, I'm just
> > shooting for something that will compile againt
> > Jelly-core. Eventually, we'll want to hook up each
> > individual taglib to GUMP with Jelly-core as a
> > dependency and an appropriate sender name for the
> > shame mail, plus documentation, website, etc.
>
> Cool. I'll have some time next week to dive in and help.
>
> We should ultimately be able to share details for each taglib in a similar
> way as to how each maven-built commons project can share project
> information, to avoid cut-n-paste of things across each individual taglib.
>
This whole issue is why I have some misgivings about Jelly as a commons
component -- the functionality is great, but the dependency matrix for the
libraries is enormous.
How about moving Jelly core *only* to commons proper, and starting a new
"jakarta-jelly-taglibs" (with independent but coordinated builds like
jakarta-taglibs) for all the tag libraries?
> James
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jelly] Release Issue 1 - dependencies
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Morgan Delagrange" <md...@yahoo.com>
> I'm going to try to move at least one taglib (probably
> http) to a separate build today. It won't be pretty,
> but it should be servicable. For starters, I'm just
> shooting for something that will compile againt
> Jelly-core. Eventually, we'll want to hook up each
> individual taglib to GUMP with Jelly-core as a
> dependency and an appropriate sender name for the
> shame mail, plus documentation, website, etc.
Cool. I'll have some time next week to dive in and help.
We should ultimately be able to share details for each taglib in a similar
way as to how each maven-built commons project can share project
information, to avoid cut-n-paste of things across each individual taglib.
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: [Jelly] Release Issue 1 - dependencies
Posted by Morgan Delagrange <md...@yahoo.com>.
--- James Strachan <ja...@yahoo.co.uk> wrote:
<snip/>
>
> I'll try get some time this week though it might
> have to wait until next
> wednesday when I've some spare cycles - but I'll try
> create an experimental
> build of some seperate libraries in the sandbox
> (say, JellySWT for
> starters). Then once thats working and the website &
> documentation is
> working, I'll mail the list and we can start moving
> Jelly over to commons
> proper with a small core with a few solid
> dependencies and then lots of
> optional libraries.
>
I'm going to try to move at least one taglib (probably
http) to a separate build today. It won't be pretty,
but it should be servicable. For starters, I'm just
shooting for something that will compile againt
Jelly-core. Eventually, we'll want to hook up each
individual taglib to GUMP with Jelly-core as a
dependency and an appropriate sender name for the
shame mail, plus documentation, website, etc.
- 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!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jelly] Release Issue 1 - dependencies
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Morgan Delagrange" <md...@yahoo.com>
> --- Sam Ruby <ru...@apache.org> wrote:
> > Morgan Delagrange wrote:
> > >
> > > Yes, it's definitely a full-fledged application,
> > like
> > > Latka and Catcus. Ripe for promotion, should
> > someone
> > > volunteer to make it happen, call the vote, help
> > with
> > > the repackaging, rippling GUMP failures, etc.
> >
> > Rippling GUMP failures? It is not like anything
> > which has a dependency
> > on Jelly has seen any any gump builds for months or
> > anything.
>
> Absolutely. That's part of what I'm trying to address
> by breaking up the Jelly build into 1) the "core"
> library and tags and 2) separate builds for each
> additional tag. That way, when HttpClient snapshot
> 20021214 has a different interface than 20021208, the
> entire GUMP world doesn't suffer.
Agreed.
I'll try get some time this week though it might have to wait until next
wednesday when I've some spare cycles - but I'll try create an experimental
build of some seperate libraries in the sandbox (say, JellySWT for
starters). Then once thats working and the website & documentation is
working, I'll mail the list and we can start moving Jelly over to commons
proper with a small core with a few solid dependencies and then lots of
optional libraries.
Then folks that depend on Jelly should have a small, stable core on which to
depend and the GUMP builds should just work (I hope).
> And that's why I'm only mildly interested in moving
> out of commons.
Me too.
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: [Jelly] Release Issue 1 - dependencies
Posted by Morgan Delagrange <md...@yahoo.com>.
--- Sam Ruby <ru...@apache.org> wrote:
> Morgan Delagrange wrote:
> >
> > Yes, it's definitely a full-fledged application,
> like
> > Latka and Catcus. Ripe for promotion, should
> someone
> > volunteer to make it happen, call the vote, help
> with
> > the repackaging, rippling GUMP failures, etc.
>
> Rippling GUMP failures? It is not like anything
> which has a dependency
> on Jelly has seen any any gump builds for months or
> anything.
Absolutely. That's part of what I'm trying to address
by breaking up the Jelly build into 1) the "core"
library and tags and 2) separate builds for each
additional tag. That way, when HttpClient snapshot
20021214 has a different interface than 20021208, the
entire GUMP world doesn't suffer.
And that's why I'm only mildly interested in moving
out of commons. It's a nice-to-have, but we've got
enough problems making Jelly stable in its current
incarnation before we think about repackaging every
single class (a very GUMP-unfriendly act). I just
want to make it clear that, while I'm willing to
organize a 1.0 release, and while I'm willing to
reorganize Jelly into a more stable series of builds,
I'm not interested in doing the brunt of the
repackaging work if Jelly gets promoted. In other
words, +0. :)
> I certainly will help in any way I can, but fter
> that point I really
> would like to see Jelly manage its dependencies by
> actually taking
> integration errors seriously and reacting in a
> timely fashion, instead
> of merely reacting to changes when the possibility
> of a release.
>
> A chain of dependencies are only as strong as its
> weakest link.
I agree. I think reorganizing the build will do just
that. We'll have a core library with a more stable
build. Whenever that build goes to hell, I believe
the response will be more timely. At present, you
have the core libraries bundled in with all the tags,
and it doesn't work well. The core Jelly build should
not fail if any single tag can't build (IIRC the
current build failure is some problem with HttpClient,
which is not a core Jelly dependency). It's better
for the developers and it's definitely better for the
wide web of GUMP.
> Address that and I would be +1 to a jakarta-jelly.
And I'll be +0. ;)
> - Sam Ruby
>
>
>
>
> --
> 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!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jelly] Release Issue 1 - dependencies
Posted by di...@multitask.com.au.
The main issue at the moment is that Jelly needs to be split into core and
various taglibs.
I think jelly core has very few dependencies.
Once it has separate sub-projects, it will make dependency tracking a hell
of a lot easier.
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
news <ne...@main.gmane.org> wrote on 31/12/2002 10:41:22 AM:
> Morgan Delagrange wrote:
> >
> > Yes, it's definitely a full-fledged application, like
> > Latka and Catcus. Ripe for promotion, should someone
> > volunteer to make it happen, call the vote, help with
> > the repackaging, rippling GUMP failures, etc.
>
> Rippling GUMP failures? It is not like anything which has a dependency
> on Jelly has seen any any gump builds for months or anything.
>
> I certainly will help in any way I can, but fter that point I really
> would like to see Jelly manage its dependencies by actually taking
> integration errors seriously and reacting in a timely fashion, instead
> of merely reacting to changes when the possibility of a release.
>
> A chain of dependencies are only as strong as its weakest link.
>
> Address that and I would be +1 to a jakarta-jelly.
>
> - Sam Ruby
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
> ForwardSourceID:NT0009CC6A
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jelly] Release Issue 1 - dependencies
Posted by Sam Ruby <ru...@apache.org>.
Morgan Delagrange wrote:
>
> Yes, it's definitely a full-fledged application, like
> Latka and Catcus. Ripe for promotion, should someone
> volunteer to make it happen, call the vote, help with
> the repackaging, rippling GUMP failures, etc.
Rippling GUMP failures? It is not like anything which has a dependency
on Jelly has seen any any gump builds for months or anything.
I certainly will help in any way I can, but fter that point I really
would like to see Jelly manage its dependencies by actually taking
integration errors seriously and reacting in a timely fashion, instead
of merely reacting to changes when the possibility of a release.
A chain of dependencies are only as strong as its weakest link.
Address that and I would be +1 to a jakarta-jelly.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jelly] Release Issue 1 - dependencies
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Morgan Delagrange" <md...@yahoo.com>
> --- Stephen Colebourne <sc...@btopenworld.com>
> wrote:
> > From: "Morgan Delagrange" <md...@yahoo.com>
> > > So far only Bob has voiced a concern with
> > preparing to
> > > release a Jelly beta, and I believe his only
> > concern
> > > is whether or not to release it under the Commons
> > > umbrella. So I'm going to start raising some
> > release
> > > issues, and I'll steer clear of anything relating
> > to
> > > packaging for now, just in case someone wants to
> > > propose moving Jelly soon. (Personally, I'm +0 on
> > the
> > > idea; sounds like potentially good exposure for
> > Jelly,
> > > but it doesn't scratch any itches for me. I still
> > > volunteer as release manager, regardless of
> > Jelly's
> > > location in Jakarta.)
> >
> > Although I'm not a Jellier, I think that the length
> > of the dependency list
> > gives a clue that Jelly is not really a commons
> > component, but an
> > integration one like Ant. (Of course Ant isn't in
> > Jakarta anymore....)
The Jelly core is a useful commons component. Its the add-on libraries
(sub-components) that cause the large dependency list. The core of Jelly has
pretty minimal dependencies on mostly other commons components.
> Probably. I hope that tags will be hosted by their
> parent library whenever possible. E.g. it makes
> sense for Latka and Maven to host their own Jelly
> tags, since Jelly is now integral to both
> applications. Tags that introduce alternate XML
> syntax to libraries that are not XML-driven (like
> logging, HTTP requests, etc.) should probably live
> with Jelly.
>
> When a new user comes to the current Jelly website, he
> finds 45 dependencies. It's unrealistic that a user
> will obtain and maintain all those dependencies in
> support of the Jelly subset he's actually interested
> in. Part of this could be rectified by documenting
> the dependencies of the Jelly engine and the
> dependencies of each tag (I'll bet that no single
> Jelly knows them all at present).
Agreed.
> However I'm starting to think that splitting up the
> tags into separate builds and releases (a la Jakarta
> Taglibs and, for that matter, Jakarta Commons) might
> be more effective than the current build. This might
> alleviate the problem of alpha and snapshot
> dependencies; if a tag's dependencies are unreleased,
> we simply stick to beta releases. It also pushes some
> of dependency tracking onto the build scripts, which I
> think is good.
Agreed.
Following the approach of the Maven project, where each plugin has its own
build & dependencies, means that each library can have its own area of the
website & dependency list etc. Then folks know what jars they need based on
the libraries they used.
What would totally rock is if we could also reuse the dependency &
downloading features in Maven so that as Jelly libraries are used, the jars
required for them can be downloaded too to the same repository (in a
Maven/JJAR kinda way).
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: [Jelly] Release Issue 1 - dependencies
Posted by Morgan Delagrange <md...@yahoo.com>.
--- Stephen Colebourne <sc...@btopenworld.com>
wrote:
> From: "Morgan Delagrange" <md...@yahoo.com>
> > So far only Bob has voiced a concern with
> preparing to
> > release a Jelly beta, and I believe his only
> concern
> > is whether or not to release it under the Commons
> > umbrella. So I'm going to start raising some
> release
> > issues, and I'll steer clear of anything relating
> to
> > packaging for now, just in case someone wants to
> > propose moving Jelly soon. (Personally, I'm +0 on
> the
> > idea; sounds like potentially good exposure for
> Jelly,
> > but it doesn't scratch any itches for me. I still
> > volunteer as release manager, regardless of
> Jelly's
> > location in Jakarta.)
>
> Although I'm not a Jellier, I think that the length
> of the dependency list
> gives a clue that Jelly is not really a commons
> component, but an
> integration one like Ant. (Of course Ant isn't in
> Jakarta anymore....)
Yes, it's definitely a full-fledged application, like
Latka and Catcus. Ripe for promotion, should someone
volunteer to make it happen, call the vote, help with
the repackaging, rippling GUMP failures, etc.
> >
>
http://jakarta.apache.org/commons/sandbox/jelly/dependencies.html
> >
> > Holy cow. It's not the number of dependencies
> that
> > concerns me, it's the number of dependencies based
> on
> > snapshots and alphas.
>
> My first reaction is that Jelly will probably always
> be at the forefront of
> technologies, so this isn't a problem that will just
> go away.
Probably. I hope that tags will be hosted by their
parent library whenever possible. E.g. it makes
sense for Latka and Maven to host their own Jelly
tags, since Jelly is now integral to both
applications. Tags that introduce alternate XML
syntax to libraries that are not XML-driven (like
logging, HTTP requests, etc.) should probably live
with Jelly.
When a new user comes to the current Jelly website, he
finds 45 dependencies. It's unrealistic that a user
will obtain and maintain all those dependencies in
support of the Jelly subset he's actually interested
in. Part of this could be rectified by documenting
the dependencies of the Jelly engine and the
dependencies of each tag (I'll bet that no single
Jelly knows them all at present).
However I'm starting to think that splitting up the
tags into separate builds and releases (a la Jakarta
Taglibs and, for that matter, Jakarta Commons) might
be more effective than the current build. This might
alleviate the problem of alpha and snapshot
dependencies; if a tag's dependencies are unreleased,
we simply stick to beta releases. It also pushes some
of dependency tracking onto the build scripts, which I
think is good.
> > Regardless of how we structure the JARs and the
> CVS
> > repository, I think we should focus on identifying
> > dependencies specific to Jelly and the core tag
> > library, and once we have a solid list we should
> try
> > to obtain as many released versions as we can
> manage.
> > I'm uncomfortable releasing Jelly based on beta
> > dependencies, and I think including snapshots is
> > completely unworkable.
>
> I'm hopeful that we can get a new [lang] release out
> fairly soon. That
> should remove one from your list.
Good to hear.
> Stephen
>
>
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jelly] Release Issue 1 - dependencies
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Morgan Delagrange" <md...@yahoo.com>
> So far only Bob has voiced a concern with preparing to
> release a Jelly beta, and I believe his only concern
> is whether or not to release it under the Commons
> umbrella. So I'm going to start raising some release
> issues, and I'll steer clear of anything relating to
> packaging for now, just in case someone wants to
> propose moving Jelly soon. (Personally, I'm +0 on the
> idea; sounds like potentially good exposure for Jelly,
> but it doesn't scratch any itches for me. I still
> volunteer as release manager, regardless of Jelly's
> location in Jakarta.)
Although I'm not a Jellier, I think that the length of the dependency list
gives a clue that Jelly is not really a commons component, but an
integration one like Ant. (Of course Ant isn't in Jakarta anymore....)
> http://jakarta.apache.org/commons/sandbox/jelly/dependencies.html
>
> Holy cow. It's not the number of dependencies that
> concerns me, it's the number of dependencies based on
> snapshots and alphas.
My first reaction is that Jelly will probably always be at the forefront of
technologies, so this isn't a problem that will just go away.
> Regardless of how we structure the JARs and the CVS
> repository, I think we should focus on identifying
> dependencies specific to Jelly and the core tag
> library, and once we have a solid list we should try
> to obtain as many released versions as we can manage.
> I'm uncomfortable releasing Jelly based on beta
> dependencies, and I think including snapshots is
> completely unworkable.
I'm hopeful that we can get a new [lang] release out fairly soon. That
should remove one from your list.
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jelly] Release Issue 1 - dependencies
Posted by bob mcwhirter <bo...@werken.com>.
> So far only Bob has voiced a concern with preparing to
> release a Jelly beta, and I believe his only concern
> is whether or not to release it under the Commons
> umbrella.
Yah, I withdraw this concern, and +1 towards release as
suggested under jakarta-commons proper.
-bob
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>