Stefan Bodewig wrote:
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.
I agree with you objective (and magic is supporting this).
The issue comes down to the conflict of interest between the two following scenarios:
(a) I stack the initial classloader with everything that is
needed (plugins, lib, directories, etc.) in which case
the system should work (b) I simulate the real runtime scenario by building classloader
hierarchies and through integration testing validate not only
the build integrity but also the integrity of runtime
descriptorsAn example of the difference is that in scenario (b) I'm going to discover that a particular class has not been included in a deployment classloader because it was not referenced as a runtime dependency in whatever it is that is describing the deployment solution. But to discover this issue I need to be able to create the classloaders that simulate the deployment scenario.
IMO - the real solution is to enable ant with repository based logic and instead of inhibiting ant classloader logic - focus instead on liberating ant such that classloaders can be created providing the jar references are uris to repository artifacts. Then link the repository handling within ant runtime with gump and your back in control. Add to this an ant -offline switch (backed with updates to ant's get task) and things are looking good.
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.
A simple example was included in my earlier email. Magic makes a distinction between a "plugin" and a something like a ant <taskdef>. A plugin to Magic is a project with build, test and runtime dependencies that exports a definition of itself. The definition includes the declaration of the classloader in terms of artifact uris. A project that uses a plugin simply declares the plugin dependency and magic takes care of the construction of the classloader for the plugin by resolving artifact uris relative to its local repository. Its here that we intercept things and map the artifact to a gump generated jar file.
* how do you deal with Magic build files that use snippets of "plain Ant"?
No special handling. Just as maven users use jelly to supplement a build, magic uses ant. The main Magic benefit is the provision of a centralized version and dependency management framework within which there is more value to play within the rules than outside.
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.
I haven't located docs on this. Is there a url you can point me to?
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]
