incubator-depot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: classloader was: Moving forward or letting go
Date Mon, 21 Jun 2004 20:55:08 GMT

Stephen McConnell wrote:
> Going the direction of multiple gump files means invoking a build 
> multiple time.  This is massive inefficiency - do a build to generate 
> the classes directory and a jar file, do another build to run the 
> testcase, 

You call it inefficiency, I call it *safe* separation of builds. I don't 
see the problem here. Note that I'm talking about *Gump*, not about a 
build system, that uses also Gump metadata.

> but then when you need the above information for generation of 
> a build artifact - well - you sunk.  You cannot do it with gump as it is 
> today.

I don't understand this last sentence.

> The solution is to do to gump what Sam did to Ant community  .. he 
> basically said - "hey .. there is an application that knows more about 
> the classpath information than you do" and from that intervention ant 
> added the ability to override the classloader definition that ant uses.
> Apply this same logic to gump - there is a build system that knows more 
> about the class loading requirements than gump does - and gump needs to 
> delegate responsibility to that system - just as ant delegates 
> responsibility to gump.

It doesn't make sense. You mean that one should delegate

  buildsystem -> CI system -> buildsystem


Gump took away the responsibility from the build system, why should he 
give it back?

>>> I.e. gump is very focused on the pure compile scenarios and does not 
>>> deal with the realities of test and runtime environments that load 
>>> plugins dynamically.
>> You cannot create fixed metadata for dynamically loaded plugins 
>> (components), unless you decide to declare them, and the above is 
>> sufficient.
> Consider the problem of generating the meta data for a multi-staged 
> classloader 

What's a 'multi-staged classloader'?

> containing API, SPI and IMPL separation based on one or 
> multiple gump definitions .. 

A classloader containing 'separation'?

> you could write a special task to handle 
> phased buildup of data,

'Phased buildup'?

> and another task to consolidate this and 
> progressively - over three gump build cycles you could produce the 
> meta-data.  Or, you could just say to magic - <artifact/> and if gump is 
> opened up a bit .. the generated artifact will be totally linked in to 
> gump generated resources

'Linked in to gump generated resources'?

> - which means that subsequent builds that are 
> using the plugin are running against the gump content.

You totally lost me here.

> The point is that gump build information is not sufficiently rich when 
> it comes down to really using a repository in a productive manner when 
> dealing with pluggable artifacts (and this covers both build and runtime 
> concerns).  How this this effect Depot? Simply that gump project 
> descriptors should be considered as an application specific descriptor - 
> not a generic solution.

Sorry, I don't understand.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message