Interesting to see what happens here as a case study. Carsten updates the xmlutil stuff based on developments in cocoon. He adds a cvs snapshot jar to CVS, probably runs a few ant tests to ensure things work, then commits. Regardless of the fact that it is not a good idea to have jars in CVS (fix in development :D), and that Carsten doesn't know that the excalibur build system expect you to modify ${subproject}/default.properties when you add a new dependency, gump is not told about the change, so it complains and xmlutil fails to build.
This is a prereq failure for xml-cocoon2 (not the only one at this point, but it could've been), resulting in cocoon not building, and blocks depending on cocoon core also failing, and stuff like forrest also failing.
I think it's important that all committers working on a project realize when they need to update the gump descriptors. In this case, the fix is to add
<depend project="xml-commons-resolver"/>
to the project
<project name="excalibur-xmlutil">
in
jakarta-gump/project/avalon-excalibur.xml
(which I've just done, and which is something people like Sam silently do for lots of projects whose committers don't maintain the gump descriptors very well). This is a common, simple rule: whenever you import a dependency into a project in one way or another, you need to also add this dependency information to the gump descriptor (and then always run 'ant gen' in the jakarta-gump base directory, and commit the change if there's no errors in the output).
Another common reason why you need to update the gump descriptor is when source trees or build trees are moved around or reformatted, or even entire projects. For example, the excalibur-meta project was moved to avalon-sandbox some time ago, but no-one (should've been me as I moved it) updated the avalon-excalibur buildfile to know about this, so this resulted in errors still popping up 2 months after the cvs restructuring! Another example is when a project not built by gump is defined by referencing a jarfile, and the name of the jarfile changes.
For example, jakarta-gump/project/xml-cocoon2.xml defines
<project name="maybeupload">
<url href="http://www.weft.co.uk/library/maybeupload/"/>
<package>uk.co.weft.maybeupload</package>
<description>
Upload files from Java Servlets
</description>
<home nested="lib/optional"/>
<jar name="maybeupload_1-0-5pre3.jar"/>
</project>but the referenced jar xml-cocoon2/lib/optional/maybeupload_1-0-5pre3.jar no longer exists (Stefano removed it two days ago). GUMP reports this is a "prereq failure" for cocoon (so the limited <nag/> tags defined in xml-cocoon2.xml don't result in a complaint message to the cocoon mailing list), when in fact the project definition for maybeupload is now wrong.
gotta go now,
cheers,
- Leo
Gump Integration Build wrote:
compile:
[mkdir] Created dir: /home/rubys/jakarta/avalon-excalibur/xmlutil/build/classes
[javac] Compiling 34 source files to
/home/rubys/jakarta/avalon-excalibur/xmlutil/build/classes
[javac]
/home/rubys/jakarta/avalon-excalibur/xmlutil/src/java/org/apache/excalibur/xml/DefaultEntityResolver.java:70:
package org.apache.xml.resolver does not exist
[javac] import org.apache.xml.resolver.CatalogManager;
[javac] ^
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
