harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Liang <richard.lian...@gmail.com>
Subject Re: Supporting working on a single module?
Date Wed, 10 May 2006 05:02:55 GMT
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.
>   
Yes. I have the same problems. But I just try to configure "support" as 
a java 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.
>   
Good idea. As you know, some test data files are accessed through file 
system, so packaging them into a JAR may cause some problems. But we can 
take a try. :-)
> -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
>
>
>   


-- 
Richard Liang
China Software Development Lab, IBM 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message