avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: [GUMP] Build Failure - excalibur-xmlutil
Date Fri, 28 Feb 2003 11:58:48 GMT
(GUMP awareness tutorial part 1 :D)

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">



(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/"/>
       Upload files from Java Servlets
     <home nested="lib/optional"/>
     <jar name="maybeupload_1-0-5pre3.jar"/>

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,


- 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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message