From depot-dev-return-605-apmail-incubator-depot-dev-archive=incubator.apache.org@incubator.apache.org Mon Jun 21 11:49:38 2004 Return-Path: Delivered-To: apmail-incubator-depot-dev-archive@www.apache.org Received: (qmail 45629 invoked from network); 21 Jun 2004 11:49:38 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 21 Jun 2004 11:49:38 -0000 Received: (qmail 72898 invoked by uid 500); 21 Jun 2004 11:49:29 -0000 Delivered-To: apmail-incubator-depot-dev-archive@incubator.apache.org Received: (qmail 72682 invoked by uid 500); 21 Jun 2004 11:49:28 -0000 Mailing-List: contact depot-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: "Depot Development" List-Id: Depot Development Delivered-To: mailing list depot-dev@incubator.apache.org Received: (qmail 72479 invoked by uid 99); 21 Jun 2004 11:49:26 -0000 Received: from [203.121.47.163] (HELO f2.hedhman.org) (203.121.47.163) by apache.org (qpsmtpd/0.27.1) with ESMTP; Mon, 21 Jun 2004 04:49:26 -0700 Received: from f2.hedhman.org (f2.hedhman.org [127.0.0.1]) by f2.hedhman.org (8.12.8/8.12.8) with ESMTP id i5LBnKRn019318 for ; Mon, 21 Jun 2004 19:49:20 +0800 From: Niclas Hedhman Organization: Private To: "Depot Development" Subject: Re: classloader was: Moving forward or letting go Date: Mon, 21 Jun 2004 19:49:19 +0800 User-Agent: KMail/1.5 References: <40D18CB2.7000907@apache.org> <200406211731.36192.niclas@hedhman.org> <40D6C020.5010605@apache.org> In-Reply-To: <40D6C020.5010605@apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200406211949.19552.niclas@hedhman.org> X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N 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 / +------//-------------------+