On Fri, 09 Jul 2004, Stephen McConnell <[EMAIL PROTECTED]> wrote: > Ant provides support for a system property "build.sysclasspath" > which if set to "none"
nitpick, "only" - not "none". > ensures that the bootstrap classpath is used throughout the > execution of an ant session. > Clearly - the assumptions behind the "project == classpath" notion > become an issue when dealing with a build system which provides > artifact resolution. In this scenario the build system needs > information about artifact locations. In effect it's my opinion > that gump should be delegating the responsibility to the builder for > classpath and classloader management. I'm not sure I follow you here. We'd also want to use the very latest of every plugin, so Gumo needs to build the plugins as well and as a consequence will know its location. Placing them all on a single classloader may not be nice, but will ensure the plugins can deal with the same set of libraries. > b) add a MagicBuilder which disables "build.sysclasspath" I prefer that. In the Maven context, build.sysclasspath is ignored as well and we rely on jar overrides to work. The biggest problems I see: * how to deal with plugins properly. Can I trust the plugins will do what I want? With custom tasks in Ant and the build sysclasspath setting I can ensure that no plugin ever gets a chance to use classes from any source that Gump doesn't control. * how do you deal with Magic build files that use snippets of "plain Ant"? > Outside of the these two I have the feeling I'm getting into > workarounds (things like overloading the property is not nice - and > forking another java process seems like cludge). If you overload the property, you should use one of the supported values. "last" or even "none" seems to be what you want for Magic. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
