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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
