From harmony-dev-return-8285-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org Tue Jun 06 15:03:48 2006 Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 21085 invoked from network); 6 Jun 2006 15:03:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 6 Jun 2006 15:03:48 -0000 Received: (qmail 99860 invoked by uid 500); 6 Jun 2006 15:03:44 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 99819 invoked by uid 500); 6 Jun 2006 15:03:44 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 99808 invoked by uid 99); 6 Jun 2006 15:03:43 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Jun 2006 08:03:43 -0700 X-ASF-Spam-Status: No, hits=1.4 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: 195.212.29.137 is neither permitted nor denied by domain of mark.hindess@googlemail.com) Received: from [195.212.29.137] (HELO mtagate4.uk.ibm.com) (195.212.29.137) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Jun 2006 08:03:42 -0700 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.13.6/8.13.6) with ESMTP id k56F3K6S159754 for ; Tue, 6 Jun 2006 15:03:20 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k56F4Umn092148 for ; Tue, 6 Jun 2006 16:04:30 +0100 Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k56F3KHo022723 for ; Tue, 6 Jun 2006 16:03:20 +0100 Received: from anaheim.local (anaheim.hursley.ibm.com [9.20.183.13]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k56F3Kod022717; Tue, 6 Jun 2006 16:03:20 +0100 Message-Id: <200606061503.k56F3Kod022717@d06av02.portsmouth.uk.ibm.com> X-Mailer: exmh version 2.7.2 01/07/2005 (debian 1:2.7.2-7) with nmh-1.1 From: Mark Hindess To: harmony-dev@incubator.apache.org, geir@pobox.com Subject: Re: [general] revisiting structure of SVN In-reply-to: Your message of "Mon, 05 Jun 2006 13:00:20 EDT." <44846324.2040908@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Jun 2006 16:03:19 +0100 X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On 5 June 2006 at 13:00, Geir Magnusson Jr wrote: > > I'd like to discuss how we start to bring together the pieces of Harmony > given our goal is Java SE with all the fixin's. > > We now have > > /classlib > /jchevm > /drlvm > > DRLVM and classlib work together (as I think we all like to see jchevm > do too...) > But given that we are a Java SE project (and not a VM project or a > classlibrary project) I think it behooves us to start thinking how to > organize at a higher level. We've been very focused on the classlib > area, but that's only one part. Perhaps we could use svn:externals rather than moving things around? (It would of course be the only way to include SableVM given the current setup.) At least until we have ironed out any potential issues that will undoubtedly arise while drlvm is fixed with respect to classlib trunk, etc. > So, I'd like to propose something like > > 1) a /deploy directory in root, as a peer to /classlib and /drlvm > > /classlib > /deploy > /drlvm Perhaps there should be a depends directory - even if the checked in version might be quite sparse - since some of the classlib/ depends/jars will be common to both ... i.e. at least the eclipse compiler jar. > 2) Maybe move the launcher out from classlib to > > /launcher > > 3) Maybe create > > /tools > > where the tool work can happen? > > 4) Have /drlvm and /classlib build-deploy into /deploy, rather than the > local one > > 3) create a top level script such that > > build drlvm-jdk > or > build jchevm-jdk > > does what you expect, namely build the classlib artifacts and put in > /deploy, build the VM of choice and drop in /deploy, builds the > toolset,etc and go from there. It is not clear from your description how tightly integrated you envision the jvm/classlib build to be? I assume this script will be trivial delegating all of the work to the subtrees? That is doing something equivalent to: #!/bin/sh ( cd classlib; ant -f make/build.xml ) ( cd ${1%-jdk}/build ; sh build.sh ) rather than trying to actually do anything clever? Specifically, it wont do anything that prevents someone from only having to check out classlib or drlvm rather than the whole lot? I think that the drlvm build is always going to be substantially more complicated - due to greater significance of platform/architecture differences - than the classlib build and nothing is really gained by having the same build structure for both. > We can create our HDK snapshots from it, and drop HDKs into it for use : > > /deploy > /hdk/ > /hdk1/ > /hdk2/ > /jdk > /jre > > etc I think the current layout has the jdk as a part of the hdk rather than as a peer - much like the jre is a part of the jdk. Regards, Mark. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org For additional commands, e-mail: harmony-dev-help@incubator.apache.org