[EMAIL PROTECTED] 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:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to