On 9 May 2006 at 22:33, "Nathan Beyer" <[EMAIL PROTECTED]> 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.
Nathan, I agree. This is precisely the kind of thing that the 'hdk' snapshot would need to contain to fully support modular development. -Mark. > > -----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]
