incubator-depot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <>
Subject Re: classloader was: Moving forward or letting go
Date Mon, 21 Jun 2004 11:49:19 GMT
On Monday 21 June 2004 19:01, Nicola Ken Barozzi wrote:

> I don't agree here, Nick, classloading is part of artifact handling,
> albeit in the JVM.
> It can and IMHO should live as a Depot subproject.

Thanks for the thumbs up... I was getting a bit depressed :o)

> > Gump?? Sorry, how on earth did you manage to get a "Continuous
> > Integration System" to be part of a 'Jar Hell' solution?
> The Gump Metadata is a rich source of dependencies. Stephen AFAIK is
> investigating in this too.

How are you going to rely on Gump for 3rd party projects, who have no interest 
in having their own Gump setup, but for sure want to harness the power we are 
all striving for.

ATM, I only know of three build systems (Ant for this discussion is more of a 
build toolkit, than a complete system, so I leave that out), namely Maven, 
Gump and 'our pet' Magic.
All these solves the dependency pattern in their own way. 
Magic solves all _our_ concerns, i.e. chained dependencies, classloader 
establishment and the standard stuff.
Gump solves chained dependencies, but currently doesn't bother about 
classloader concerns.
Maven does neither handle chained dependencies nor classloader concerns.

Stephen is currently trying to work out how to teach Gump the classloader 
tricks, and I haven't followed that very closely.

> > We have chained dependencies in place. It works well, but our down side
> > is that only Avalon tools generate and understand the necessary meta
> > information required to support this feature.
> That's why using Gump metadata would bring projects closer.

Maybe you are looking at this from the wrong end. If Depot could solidly 
define what complex projects (such as Avalon) require, in form of meta 
information, then one should teach Gump to use it.

> The only real issue I see is the catch22 problem you have outlined about
> Avalon using Incubator code and viceversa.
> Let me disagree with it though. It's ok that an Apache project does not
> rely on incubating projects, but if some of the developers are part of
> this incubating project, does it still make sense?

Probably not. I could imagine that there is even a few more phases involved;
 *  Phase I: Avalon Repository is copied across, but Avalon maintain a 
parallel codebase, and changes are merged from one to the other.
 *  Phase II: Avalon Repository is removed from the Avalon codebase.
 *  Phase III: Avalon Repository has its package names and so forth changed to 
suit the Depot project.
 *  Phase IV: Bits and pieces are broken out into other parts of Depot, while 
maintaining enough compatibility with Avalon Merlin.

> Would this ease concerns?

Perhaps. To be totally honest, few people in Avalon care much about what 
Stephen and I decide about the codebase, as long as compatibility remains. 
So, I'll discuss it with Stephen and see how we can tackle this.


  /        /
 / / 

View raw message