From harmony-dev-return-7350-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org Thu May 11 16:44:50 2006
Return-Path:
Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org
Received: (qmail 49236 invoked from network); 11 May 2006 16:25:29 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
by minotaur.apache.org with SMTP; 11 May 2006 16:25:27 -0000
Received: (qmail 83225 invoked by uid 500); 11 May 2006 16:25:14 -0000
Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org
Received: (qmail 83080 invoked by uid 500); 11 May 2006 16:25:14 -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 83069 invoked by uid 99); 11 May 2006 16:25:13 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 May 2006 09:25:13 -0700
X-ASF-Spam-Status: No, hits=1.2 required=10.0
tests=RCVD_IN_SORBS_WEB,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: domain of oliver.deakin@googlemail.com designates 66.249.92.172 as permitted sender)
Received: from [66.249.92.172] (HELO ug-out-1314.google.com) (66.249.92.172)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 May 2006 09:25:12 -0700
Received: by ug-out-1314.google.com with SMTP id u40so169915ugc
for ; Thu, 11 May 2006 09:24:50 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=beta; d=googlemail.com;
h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
b=bjpMYtNFGZWJCyksA1N3VWlhcB9GqIc9ou2avPdxSrQ2OPAZTqb4AqLm5KNzgAOPnuU1txuB2puEHijppEfP+DGvDgXKKAGI9C8EjjZ4LDb74320DT3fT4A81O1CoXvT30YNObyD9ZRnJsOcMc3MIzSO+McC05/5EeZZ0I7ncDE=
Received: by 10.66.166.7 with SMTP id o7mr785009uge;
Thu, 11 May 2006 09:24:50 -0700 (PDT)
Received: from ?9.20.183.162? ( [195.212.29.67])
by mx.gmail.com with ESMTP id o1sm3035742uge.2006.05.11.09.24.49;
Thu, 11 May 2006 09:24:49 -0700 (PDT)
Message-ID: <4463654A.3080105@googlemail.com>
Date: Thu, 11 May 2006 17:24:42 +0100
From: Oliver Deakin
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: <200605091946.k49JkIuD002370@d06av02.portsmouth.uk.ibm.com> <4461D780.2030708@pobox.com>
In-Reply-To: <4461D780.2030708@pobox.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
Geir Magnusson Jr wrote:
> Mark Hindess wrote:
>> On 9 May 2006 at 10:32, Geir Magnusson Jr wrote:
>>> Mark Hindess wrote:
>>>> As the Harmony Classlib grows, I think that being able to work on a
>>>> single module (or some subset of the modules) will become the
>>>> typical way of working for many (perhaps even most) contributors.
>>> Sure, that makes sense.
>>>
>>>> So I think we need a plan to support this. I also think that
>>>> forcing ourselves to support this mode of working sooner rather than
>>>> later will help us keep from accidentally breaking the modularity in
>>>> the current build/development process.
>>> Can you not work on a single module now?
>>
>> Yes. But only by checking out everything.
>
> Wouldn't you do that anyway?
>
> I guess thats the mystery to me. I figured that someone would do the
> full checkout, and go from there.
I think it's good if we can cater not only for those developers who want
to completely checkout classlib trunk, but also for those who want to
work only on a single module. When I say "work on a single module", I
mean only checking that module's directory out of SVN, and not the code
for all the other modules, thereby saving download time and disk space,
not to mention the subsequent reduced build times of only recompiling a
single module.
Currently a developer cannot work on both the native and Java code for a
module without checking out the whole of classlib trunk, because the
native source directories and Ant build script associated with them are
completely separate from the modules. IMHO it would be great if we could
get the build scripts and code repository layout into a state where a
developer can just checkout a module, grab an hdk from some location and
start changing and rebuilding both Java and native code (and also
running tests against the rebuilt libraries).
To do this there are at least three steps needed, as far as I can see:
1) Refactor the native code into the modular structure we currently have
for Java code and tests. This has been spoken about before at [1]. The
native code would be located within each module at modules//src/main/native. As a starting point, can I propose that the
natives be broken down in the following way:
modules/archive/src/main/native/
|-------archive/
|-------zip/
+------zlib/
modules/auth/src/main/native/
+-------auth/
modules/luni/src/main/native/
|--------common/
|--------fdlibm/
|--------launcher/
|--------luni/
|--------pool/
|--------port/
|--------sig/
|--------thread/
|--------vmi/
+-------vmls/
modules/prefs/src/main/native/
+-------prefs/
modules/text/src/main/native/
|-------text/
+------unicode/ (comes from the
icu4c zips stored currently in depends)
Additionally, each module may have an include directory that contains
header files required across its native components. Each native
component would contain subdirectories for its shared and platform
specific code.
2) Alter the global build scripts to start creating an hdk under the
deploy directory, which contains a jdk which contains a jre. As Mark
described before, this hdk would probably look something like:
deploy/hdk/
|--------jdk/
| |-------jre/ (already being created at
the moment as deploy/jre)
| +------include/ (already being created
at the moment as deploy/include)
|--------include/
+-------lib/
The hdk/include directory would be much like the current
native-src//include directories, and would contain a minimal
set of header files that define an interface between native modules. It
would be the responsibility of the individual module to copy its
required headers to this directory as a prerequisite for building.
The hdk/lib directory would exist on Windows platforms, and would
contain .lib files for each native component.
An hdk snapshot would then be a zip of the hdk directory, and should
provide everything necessary for a developer to build both native and
Java code against.
3) Modularise native and Java build scripts so that the individual
module's Ant scripts are capable of building native and Java source
against an hdk, rather than having its code compiled as part of a global
build. The rebuilt libraries would be placed back into the hdk
directory, so that the developers local hdk always contains their latest
built code (much as the current deploy/jre does).
Additionally, I agree with Nathan [2] that allowing a developer working
in a modular way to run the entire test suite against their
work-in-progress code would be a good thing, and this could be done by
bundling tests and their resources in with an hdk.
Regards,
Oliver
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/%3cc3755b3a0602100609x1b79da6q@mail.gmail.com%3e
[2]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/%3c000f01c673e2$92e74130$0e01a8c0@LITTLEGUY%3e
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
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