Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: 64.74.244.71 is neither permitted nor
 denied by domain of geir@pobox.com)
Message-ID: <4461D7D1.8000808@pobox.com>
Date: Wed, 10 May 2006 08:08:49 -0400
From: Geir Magnusson Jr <geir@pobox.com>
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: <000f01c673e2$92e74130$0e01a8c0@LITTLEGUY>
In-Reply-To: <000f01c673e2$92e74130$0e01a8c0@LITTLEGUY>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Nathan Beyer wrote:
> Perhaps this is a bit of an aside, but one of the biggest difficulties I
> have when trying to develop against a single module is the availability of
> the test support classes. Currently, I run the ant build and run the
> 'compile-support' to build the test support classes. Then in Eclipse, I
> create a linked folder to the 'build/tests' in the module I'm working on and
> then add that folder to the classpath of the project.
> 
> As such, I would like to propose adding a packaging of the support classes
> to a JAR in the build scripts and include this as part of the discussed
> snapshots.

There was a related dropped thread.

Why not setup a second jar and manifest per module so that the manifests 
are clean and our test jars and separate from code jars?

geir

> 
> -Nathan
> 
>> -----Original Message-----
>> From: Mark Hindess [mailto:mark.hindess@googlemail.com]
>> Sent: Tuesday, May 09, 2006 9:07 AM
>> To: Apache Harmony Dev List
>> Subject: Supporting working on a single module?
>>
>>
>> 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.  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.
>>
>> Oliver is currently looking at restructuring the native source to the
>> appropriate modules/*/src/main/native directory.  One question that
>> comes out of this investigation is: where should the include files
>> "live"?  I think they belong with the module that provides the
>> implementation defined by the declarations in the header.  That is,
>> zipsup.h is "owned" by archive, hythread.h is "owned" by thread
>> (luni), etc.
>>
>> However, if the build was to refer to the header files within the
>> modules then this breaks the modularity.  So, for example, someone
>> working on a single module would have to checkout all the dependent
>> modules rather than just the one they wish to work on.
>>
>> So, perhaps, at build time we should copy the header files out of the
>> owning module into a common include directory.  All modules would then
>> refer to the header file in the common include directory.  This means
>> we can then create a snapshot tar/zip of the common include directory
>> which someone wishing to work on a single module could download to
>> build against.  This is not dissimilar to the current way in which
>> you could build the java sources against a deploy/jre snapshot.
>>
>> For windows, the snapshot would also include the .lib files that are
>> required to build for the run-time .dll files.
>>
>> What is this new snapshot?  Well, Tim suggested that it was a little
>> like the jdk but for Harmony development.  So perhaps it should be
>> called an hdk, Harmony Development Kit?
>>
>> Logically, in the same way that a jdk contains a jre, the hdk should
>> contain the jdk (which will contain the jre).  Thus, we'd have a
>> hierarchy like:
>>
>>   deploy/hdk
>>   deploy/hdk/jdk
>>   deploy/hdk/jdk/jre
>>
>> When we come to create snapshots/releases, it's easy to see how we'd
>> create archives for the hdk, jdk, and jre.
>>
>> Unfortunately, though I think this solution is quite elegant, there
>> are quite a few references to the "deploy/jre" path that would need to
>> be fixed.  However, I think this is something we should discuss and, if
>> we decide it is the right thing to do, then we should take the hit and
>> move things around now.
>>
>> What do you think?
>>
>> 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
> 
> 
> ---------------------------------------------------------------------
> 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