From dev-return-31454-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Wed Jan 09 15:41:20 2008 Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 60637 invoked from network); 9 Jan 2008 15:41:20 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 9 Jan 2008 15:41:20 -0000 Received: (qmail 74638 invoked by uid 500); 9 Jan 2008 15:41:07 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 74619 invoked by uid 500); 9 Jan 2008 15:41:07 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 74610 invoked by uid 99); 9 Jan 2008 15:41:07 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 09 Jan 2008 07:41:07 -0800 X-ASF-Spam-Status: No, hits=-2.8 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: 195.212.29.140 is neither permitted nor denied by domain of mark.hindess@googlemail.com) Received: from [195.212.29.140] (HELO mtagate7.uk.ibm.com) (195.212.29.140) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 09 Jan 2008 15:40:53 +0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate7.uk.ibm.com (8.13.8/8.13.8) with ESMTP id m09FeiOr141990 for ; Wed, 9 Jan 2008 15:40:44 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m09FeiJb4866146 for ; Wed, 9 Jan 2008 15:40:44 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m09FeSeD000541 for ; Wed, 9 Jan 2008 15:40:28 GMT Received: from anaheim.local (dhcp-9-20-183-171.hursley.ibm.com [9.20.183.171]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m09FeSUE032259 for ; Wed, 9 Jan 2008 15:40:28 GMT Message-Id: <200801091540.m09FeSUE032259@d06av01.portsmouth.uk.ibm.com> X-Mailer: exmh version 2.7.2 01/07/2005 (debian 1:2.7.2-10) with nmh-1.1 In-reply-to: References: Comments: In-reply-to "Alexey Varlamov" message dated "Wed, 09 Jan 2008 19:07:40 +0600." From: Mark Hindess To: dev@harmony.apache.org Subject: Re: [build] managing external dependencies Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 09 Jan 2008 15:40:11 +0000 X-Virus-Checked: Checked by ClamAV on apache.org On 9 January 2008 at 19:07, "Alexey Varlamov" wrote: > Folks, > > We did a few iterations refactoring the subject - let's have one more access > ;). > Why? There was a desire to have the following: > 1) More fine-grained control over dependencies to empower modularity; > 2) Unified approach and shared scripts across Harmony modules - VMs, > classlib, jdktools; > 3) Reduce duplication of resources (traffic, space, etc) between > modules within the same workspace; > I'd also add 4) If possible, reuse resources in different workspaces. > This would be quite handy for committing purposes and for > multi-platform development. I like all of the above but would add Tim's suggestion from a few weeks back which I think was something like: 5) Move binary dependencies - like all the icu libs - from the enhanced to the standard tree in svn and download them via http as we do other dependencies during the fetch-depends stage. A nice-to-have but not necessarily essential for a first approximation: 6) Ability to re-use system installed versions of dependencies - both at build time and ideally at run time if the dependencies are stable. For instance, my machine already has the 8 megs of dejavu fonts installed (because openoffice uses them). I fool the build in to using them to avoid the download but this should be made easier. At build time they [a subset actually] are copied into the runtime and it might be nice to avoid this if possible - although this part is easier to workaround during debian/rpm packaging. > Geir once introduced "common_resources" module, which IMO was a step > in the right direction, but it was not fully adapted thus not used > properly. Now the new build for DRLVM is a good stimulus and > opportunity to accomplish the task. > > I suggest this time we deprive the classlib of it's state of Harmony > umbilicus and make the "common_resources" a "primordial" module ;) Does this mean the: svn co http://svn.../classlib/trunk classlib cd classlib ant fetch-depends ant use case will cease to work? It would be nice if we didn't have to break this. Perhaps we can have a classlib/trunk/common_resources placeholder and if a h(armon)y.common.resources properties is not defined then svn switch this placeholder to the correct copy (in a similar manner to the way the federation build works). Users will multiple work spaces (or the federation build.xml) could set the hy.common.resources property to a shared copy? > The idea is to move all shared properties, definitions, tasks and > files to the single location. Besides, the same module should be used > as a central repository for downloading and storing external files. > So, each module would "request" needed resources via standard > facilities (ant tasks), automatically reusing duplicates. And the same > "common_resources" instance can be imported to several workspaces and > even shared between developers. > > How? > 1) Roughly, the following files need to be moved from classlib to > common_resources: > make/properties.xml > make/depends.properties # ? move only shared items to > simplify maintenance > depends/** except depends/files/ # ? there are several libs/zips + > make definitions being shared As I mentioned above, I think the platform specific files should be moved to the standard (not enhanced tree) for download with fetch-depends or whatever replaces it. And we should create the bcprov-noidea.jar in the standard tree rather than downloading it from bouncycastle to comply with their request to reduce load on their servers. > Closer comparison of other make/build-*.xml ant scripts in classlib > and jdktools may give more candidates. > 2) Implement tasks or macros for fetching resources, storing them and > providing uniform access: common_resources/download.xml svn.xml etc > 3) Refactor make/depends.xml in respective modules to resolve bullet #1. > > Surely the plan is very sketchy, we need to agree on general direction first. > Waiting for your comments/objections impatiently :) Thanks very much for kicking off this discussion. -Mark.