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. Cheers Niclas -- +------//-------------------+ / http://www.bali.ac / / http://niclas.hedhman.org / +------//-------------------+
