You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by di...@multitask.com.au on 2003/01/01 01:47:14 UTC
Re: [Jelly] Release Issue 1 - dependencies
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 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>