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. -Nathan > -----Original Message----- > From: Mark Hindess [mailto:[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
