I'm learning all sorts of things about how gump works! Please keep in mind that this message is based on a bunch of assumptions and limited experience - but I think I'm correct (so please feel free to correct any mistakes).
If your in a hurry - skip to the end.
Anyway - here goes...
Gump and Ant basically collaborate together though the subversion of classloader creation. First of all - a gump project definition is for all intensive purposes a descriptor enabling the establishment of a single classpath. Ant provides support for a system property "build.sysclasspath" which if set to "none" ensures that the bootstrap classpath is used throughout the execution of an ant session. Gump, using the project definition creates a single project classpath, and using the "build.sysclasspath" property takes effective control over the classloaders created with ant - enabling community wide normalization of classpath constructs.
This approach is quite effective when dealing with simple ant build procedures (compile, test, jar, javadoc, etc.) as it enables the reuse of the classic build definition "build.xml" within a continuous integration context.
In contrast - Magic maintains an index of project definitions. Each definition contains information about compilation, build, test and runtime dependencies. Magic uses this information together with property values supplied by gump to construct appropriate classloaders for the respective build phases. In the case of a build that requires a plugin, Magic creates a classloader for the plugin on the fly. Magic also makes extensive use of meta-information for build and runtime processes (generating and consuming multiple definitions in a single project build).
Currently the Magic based build of Magic is failing due to the gump's subversion of control over classpath management. Specifically - the magic generated classpath for unit testing is being ignored by ant (due to the "build.sysclasspath" property setting) resulting in a inconsistent classpath under the junit task. While this particular problem can be solved with things like gump <work> directives - it does not address the underlying problem of classloader management. In effect the magic build will fail on the first project requesting a plugin.
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.
This leads me to the question of how to properly handle the disabling of the gump declaration of "build.sysclasspath". As things stand this is declared within the gump workspace. It seems to me that modifying this is not a good idea as it would probably break gump on all non-magic builds.
Instead there appears to be a least a couple of options:
a) enable the ability to disable "build.sysclasspath" on the
AntBuilderor
b) add a MagicBuilder which disables "build.sysclasspath"
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).
OK - thoughts?
Cheers, Steve.
--
|---------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
