You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Stephen McConnell <mc...@apache.org> on 2004/07/09 15:44:27 UTC
build.sysclasspath management
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
AntBuilder
or
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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: build.sysclasspath management
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 12 Jul 2004, Stephen McConnell <mc...@apache.org> wrote:
> Stefan Bodewig wrote:
> 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
> descriptors
Your "normal" Magic execution would be (b) while Gump should be (a),
not?
I'm not here to stop you. If you think that a Magic builder should
work around build.sysclasspath handling, then do so. I'm pointing out
problems we might face this way.
> 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.
Repositories and Ant are orthogonal to me, I sure may be wrong, but I
haven't been convinced yet.
> 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.
OK, so Magic is in complete control of them, fine.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: build.sysclasspath management
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 12 Jul 2004, Stephen McConnell <mc...@apache.org> wrote:
>>>> 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.
<http://ant.apache.org/manual/sysclasspath.html> linked from the main
navigation in "Concepts And Types".
> Is this an Ant 1.6.2 thing?
Ant 1.3 IIRC.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: build.sysclasspath management
Posted by Stephen McConnell <mc...@apache.org>.
Stephen McConnell wrote:
> Stephen McConnell wrote:
>
>>>
>>> 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?
>
>
> Don't worry - I've found it.
Actually - no.
The ant docs (1.6.1) say
Property | Values
--------------------|----------------------------
build.sysclasspath | "only", something else
Is this an Ant 1.6.2 thing?
Steve.
--
|---------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org |
|---------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: build.sysclasspath management
Posted by Stephen McConnell <mc...@apache.org>.
Stephen McConnell wrote:
>>
>> 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?
Don't worry - I've found it.
Steve.
--
|---------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org |
|---------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: build.sysclasspath management
Posted by Stephen McConnell <mc...@apache.org>.
Stefan Bodewig wrote:
> On Fri, 09 Jul 2004, Stephen McConnell <mc...@apache.org> 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
descriptors
An 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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: build.sysclasspath management
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 09 Jul 2004, Stephen McConnell <mc...@apache.org> 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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org