Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 3379 invoked from network); 25 May 2006 14:52:50 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 25 May 2006 14:52:50 -0000 Received: (qmail 27829 invoked by uid 500); 25 May 2006 14:52:46 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 27598 invoked by uid 500); 25 May 2006 14:52:45 -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 27581 invoked by uid 99); 25 May 2006 14:52:45 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 May 2006 07:52:45 -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: 64.74.244.71 is neither permitted nor denied by domain of geir@pobox.com) Received: from [64.74.244.71] (HELO chi.mobile-health-diary.com) (64.74.244.71) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 25 May 2006 07:52:44 -0700 Received: (qmail 16470 invoked from network); 25 May 2006 14:52:21 -0000 Received: from unknown (HELO ?10.251.41.21?) (geir@192.55.60.41) by b014.internal.mobile-health-diary.com with SMTP; 25 May 2006 14:52:21 -0000 Message-ID: <4475C3CE.3010805@pobox.com> Date: Thu, 25 May 2006 07:48:46 -0700 From: Geir Magnusson Jr Reply-To: geir@pobox.com User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: harmony-dev@incubator.apache.org Subject: Re: Supporting working on a single module? References: <200605091407.k49E749L028574@d06av02.portsmouth.uk.ibm.com> <4471C66F.5040507@googlemail.com> <447353B4.9060906@pobox.com> <44757D5F.1050007@googlemail.com> <4475A501.3090304@pobox.com> <4475B638.30800@googlemail.com> In-Reply-To: <4475B638.30800@googlemail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Oliver Deakin wrote: > Geir Magnusson Jr wrote: >> >> >> Oliver Deakin wrote: >>> Geir Magnusson Jr wrote: >>>> On thing to think about (which I didn't realize until now) is that >>>> HDK should sit above /classlib in the tree right? the VMs will need >>>> it as well. I imagine : >>>> >>>> enhanced/ >>>> classlib/ >>>> drlvm/ >>>> jchevm/ >>>> bootvm/ >>>> >>>> So maybe add a >>>> >>>> enhanced/common >>>> >>>> directory in which the HDK sits by default? >>>> >>>> I'd like to avoid the structural balkanization of making classlib an >>>> island. >>> >>> I had imagined that HDKs would be packaged up as zips and made available >>> in a similar way to snapshots, rather than having a tree of binaries >>> checked into >>> SVN. >> >> I think we all did. I don't know what about the above leads you to >> assume I would have wanted this in SVN. > > I think I'm just easily confused ;) > So are you suggesting that the HDK should sit in a concrete location > relative to whichever component (VM/classlib) we are working on, or > that the HDK zips should be stored in SVN? (or something else...?) I think that the HDK should be a zip/tar that you download from our distro locations(s), and dropped into a) a well-known default location b) anywhere you want so you can set a pointer if you have more than one and no, they aren't stored in SVN. > >> >> >>> IMHO keeping it as a zip makes unpacking it where you want very simple, >>> allows you to easily keep a "known good" HDK configuration locally >>> (in the >>> form of the original zip) and makes it very easy to get previous >>> versions of >>> the HDK (just download an earlier zip). >>> I'd be interested to hear what general consensus on this matter is, and >>> how mailing list members would prefer the HDK to be provided. >> >> Keeping zips around and all that is great, but is it that Eclipse >> would break having it up and above the root of the project tree? > > I dont see this as a problem. > If you use the Ant scripts to build (which can be used within Eclipse), > then > an hy.hdk property (described in one of my other mails in this thread) that > can be set to point at an HDK will enable you to use any location. > If you wanted to work on Java code as a Java project under Eclipse, > then you should only have to point Eclipse at the jre under your HDK > and Eclipse will build against it. Cool > > Regards, > Oliver > >> >> geir >> >>> >>> We discussed [1] that having separate HDKs for each VM and for classlib >>> makes sense - as long as we keep them in a uniform shape, then they >>> can easily >>> overlaid onto each other to allow a developer to work on the classlib >>> and the >>> VM of their choice. >>> I don't see this separation of classlib and VMs as a bad thing. I >>> think that >>> having a VMI enabling us to develop the classlib and VMs as distinct >>> units, >>> and developing using potentially disparate methods and build systems >>> that >>> most suit that component, is one of the cool things about Harmony! >> >> >>> >>> Regards, >>> Oliver >>> >>> [1] >>> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/%3c446D8460.9050105@googlemail.com%3e >>> >>> >>>> >>>> geir >>>> >>>> Oliver Deakin wrote: >>>>> Hi all, >>>>> >>>>> I have opened HARMONY-485, which proposes an additional doc for the >>>>> website describing the HDK and its contents. >>>>> The layout of the HDK described in the doc matches that produced by >>>>> the build script alterations raised in >>>>> HARMONY-469. >>>>> >>>>> I hope that eventually (once the natives are modularised >>>>> and build scripts are altered to understand/use the HDK) the doc >>>>> will expand into a more full description of how developers can use >>>>> the HDK to rebuild Java/native code. >>>>> >>>>> Regards, >>>>> Oliver >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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 >>>> >>>> >>> >> >> --------------------------------------------------------------------- >> 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 >> >> > --------------------------------------------------------------------- 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