gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: [GUMP@lsd]: avalon/avalon failed
Date Mon, 01 Mar 2004 08:50:04 GMT
On Fri, 27 Feb 2004, Antoine Lévy-Lambert <>

> I had to hack my way also to figure out where is the gump descriptor
> for avalon.  (used find . -name "*.xml" | xargs grep avalon)

Looking into Gump's profile may have been easier:

  <module href="*checkout*/avalon/buildsystem/gump-integration/project/avalon.xml"/>


> Niclas Hedhman wrote:

>>Applied (not that I know why this is needed...)
> Stefan Bodewig figured out that we needed this mkdir [1] [2], he
> thinks that a path containing some classes is not incorporated into
> the build classpath, because at the beginning of the build the
> directory does not exist.

Let me expand this a little.

Some JVMs drop things from the CLASSPATH that don't exist at startup
time - I think all Sun VMs after 1.3 do.  They will not be included in
java.class.path and the application has no control over it.

If the build process creates a directory and compiles classes into
this directory that are later needed in the same build, we need to
ensure that the directory exists prior to starting the JVM to prevent

This doesn't seem to be necessary for all situations, for example:

* forked <junit> and <java> tasks  don't need a <mkdir> upfront since
  they'll see the CLASSPATH environment variable.

* <javac> tasks that include the sources of the compiled classes in
  the sourcepath don't need it since javac will use the sources instead.

* <javac> tasks that compile to the <work> directory won't need it
  since Ant adds the target directory to the classpath.

But in general each <work> element inside a Gump descriptor will need
a corresponding <mkdir>.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message