From dev-return-37764-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Thu Jul 23 11:08:45 2009 Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 27779 invoked from network); 23 Jul 2009 11:08:45 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 23 Jul 2009 11:08:45 -0000 Received: (qmail 40139 invoked by uid 500); 23 Jul 2009 11:09:49 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 40064 invoked by uid 500); 23 Jul 2009 11:09:49 -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 40053 invoked by uid 99); 23 Jul 2009 11:09:49 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 Jul 2009 11:09:49 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of oliver.deakin@googlemail.com designates 209.85.218.227 as permitted sender) Received: from [209.85.218.227] (HELO mail-bw0-f227.google.com) (209.85.218.227) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 Jul 2009 11:09:37 +0000 Received: by bwz27 with SMTP id 27so703728bwz.36 for ; Thu, 23 Jul 2009 04:09:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=WmT+JnaxV4dnzlUS1JD6UlrksOetsLk3LdD6E3lg8sE=; b=SzyawkFrBzNvjIW9H2faPBemNfdsZqlnGnpFOvdutpw9cC12uniXSRtPlBZNLr1v12 R7nIXxjItRNxpJKJSX0IvEM/2NmEJ2CyAQCuRl725ihzjbU6H2Zjd6YSZUXdkOyBw+L0 graHWKwE34J7wKiyf77nZWPHD5+T1o9ABb5/8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=OrCNU382YUh4ugChmP4QVjLUXsohE84N+QaZqTJ3l9p0Xxq8+7XBmaOgy9JkdtuIMI yOiuTMIQnkqa3iFgb52pPAJaOWiV0TB+u/IfwXuhhFq06UM6bfkOEZBh6O7R0Rq6sXU1 s8jn3zxA1d1vqS/2iZ+hcMsd9CmJLdi6m57+c= Received: by 10.204.65.65 with SMTP id h1mr1987743bki.18.1248347356902; Thu, 23 Jul 2009 04:09:16 -0700 (PDT) Received: from ?9.20.183.162? (blueice4n2.uk.ibm.com [195.212.29.92]) by mx.google.com with ESMTPS id 18sm2516308fkq.29.2009.07.23.04.09.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 23 Jul 2009 04:09:15 -0700 (PDT) Message-ID: <4A6844DA.7040203@googlemail.com> Date: Thu, 23 Jul 2009 12:09:14 +0100 From: Oliver Deakin User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: dev@harmony.apache.org Subject: Re: [general] jdktools and classlib? References: <200907211455.n6LEtQkl023990@d06av02.portsmouth.uk.ibm.com> <4A668437.3030401@gmail.com> <200907220731.n6M7VM4U013734@d12av03.megacenter.de.ibm.com> <4A66C774.2030109@gmail.com> <3b3f27c60907222000y7ed60baaq1d3170931930d65e@mail.gmail.com> <94d710af0907230143j78bfa205k7c7a8b4a4e05c7a3@mail.gmail.com> <4A6824FC.6030704@gmail.com> In-Reply-To: <4A6824FC.6030704@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Tim Ellison wrote: > On 23/Jul/2009 09:43, Sean Qiu wrote: > >> Do we really need this big change? >> >> There are so many "duplicated" xml files whose original goal is to >> achieve modularity. >> So each component can be developed and tested separately. >> I guess that's the reason that we got so many build scripts on each >> modules of classlib. >> (It is another story whether they worked as we expected) >> >> I prefer to keep jdktools and classlib separately, it sounds more natural to me. >> > > My gut feeling is also to keep the class library and jdktools separated, > but I'll admit that it is only a gut feeling and not something I can > defend technically. > > If it really does make life easier for build then it is something I > could learn to live with. I'd like to hear the arguments though. > I agree. It just feels to me like the VM and classlib are obvious "units" and putting the additional jre/jdk tools in with either one of them doesn't sit right. If our goals are to get the jdktools used/looked at more and to unify the build scripts as much as possible, then I would suggest improving the federated build for wider use. At the moment if a contributor wants to just work on classlib, they will probably just check out classlib trunk and build from there copying in whichever VM they wish to use. I think it would be better if we made the federated build the starting point for this kind of development and improved the build targets it provides so it plays nicely when working with individual components. For this to work we would need to allow more control over what source gets checked out/built/tested, so they more closely reflect the targets within the components - here's a few examples of what I was thinking of (names like hy.component are just suggestions, not really important): "ant -Dhy.component=classlib,jdktools populate-src" - just checkout the source for classlib and jdktools "ant -Dhy.component=classlib rebuild-native" - just clean and build the native code for the classlib module, and automatically populate the built binaries under the federated target directory "ant build-java" - build java code across all components. This target could detect which components have been checked out, much as the classlib build works out which modules to build automatically by checking if build targets exists, and only build those so that hy.component does not always need to be specified. The above is just a rough idea of how it could be done, but I can see a few advantages of this approach: 1) The federated build would get used more, giving us a more unified approach to building Harmony while still allowing contributors to work in individual areas with the same ease. This should also help remove some of the build script duplication across components. 2) The java/javaw executables could be moved to jdktools (which makes more sense than classlib to me) meaning that jdktools would get more attention also. 3) The common_resources directory would work for those working on the whole jdk and also for those just working on one or two components, as they would both use the federated build. 4) If we ever wanted to add components (for example, split portlib into it's own component) it would be easier managed. 5) If you started working on drlvm only and also wanted to make some changes to classlib later on, you could just run populate-src specifying the classlib component to check out the additional source and then carry on working. These are just ideas at the moment, but I can see there are benefits to this approach. Any thoughts/comments? Regards, Oliver > Regards, > Tim > > > -- Oliver Deakin Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU