> I'd like Gump to control the classpath, and not have forehead > in the way (not just to avoid writing more file, but to > handle all issues). If I avoid forehead, [for the simple > build w/ jar override use case] what will be the downside?
The downside will be that Maven won't work :) There are 3 classloaders in Maven: root (where ant and its friends live), root.maven (everything else in lib), and the project's own own (it's dependencies, all the plugin dependencies). Each project.xml can specify to put certain JARs in root or root.maven if necessary (Eg to make ant taskdefs available). In the future, classworlds will be used, plugins will each have their own classloader and the root/root.maven idea will disappear. This is all post-1.0, so for now, you'll need to keep forehead. > I get confused between 'endorsed' jars and bootclasspath. I > know Gump manages the system classpath (for runtime for > builders, like ant/maven & for dependent jars) and > bootclasspath (for things like XML libraries). Right now Gump > would set the CLASSPATH environment variable, call the JVM w/ > JVM arguments (including -Xbootclasspath if needed), and then > Maven's CLI class w/ arguments. Endorsed JARs are used to perform "endorsed standards overrides" - providing a different implementation for something provided with the JDK where it is allowed. I think the only ones included at the moment are JAXP and some corba stuff? So you need to put xerces in an endorsed directory if you want to use it under JDK 1.4 to provide javax.xml.* and org.w3c.* You shouldn't have to set a CLASSPATH at all. I think your use of bootclasspath is just cheating the endorsed mechanism by providing the XML libs before rt.jar is loaded. I didn't think that would have worked, but I guess it does :) I would think gump should be closely simulating a normal build environment, just with updated dependencies, so I would think fudging classpaths and bootclasspaths is probably not the best approach anyway. This is all from my point of view of never having attempted it though, so take this as opinion only :) > I'm going to give this a shot. Let me know if you can see > anything obviously wrong with it. I assume this means you are going to have Maven use the latest JARs to run? I'm afraid you'll have to use forehead to achieve this. IF you are just running a stock install of Maven, none of this is necessary. I can say for a fact Maven won't build with a gumped werkz, so its probably futile to attempt this right now. In the future, as I mentioned about the componentized Maven, Maven will be embeddable into apps, IDEs, etc, which should make this a whole lot easier :) Cheers, Brett
