Niclas Hedhman wrote:
On Monday 21 June 2004 19:01, Nicola Ken Barozzi wrote:...
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.
Gump metadata != Gump being setup.
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.
Keep in mind that you are talking to three developers that have worked on Centipede even before Maven had the concept of plugins :-)
We did our "magic" way before, and Depot is in fact a spinoff.
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.
Gump is not written in Java anymore, so you're out of luck on this one. ;-)
Over at Krysalis we had started Viprom, that was an abstraction over the object model. Dunno what o do now though.
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.
Meta information, that's the point. Mvan has his own object model, Gump has a merge.xml DOM that we can use as an object model... what should we use?
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.
From our POV it's just simpler as this:
* Repository is moved under Depot with package names changed. (It's parallelly kept in Avalon for as much as Avalon wants, it's not a Depot concern) * Merge of the codebases
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.
'k
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
