On Fri, 27 Feb 2004, Antoine L�vy-Lambert <[EMAIL PROTECTED]> wrote: > 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="http://cvs.apache.org/viewcvs.cgi/*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. 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>. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
