I think it would be helpful to keep the following two issues you have raised quite separate.
1) Additional requirements on the Pack200 code, and 2) The working model for contributing code. Taking them in reverse order, there have been a number of suggestions for working 'disconnected' and contributing patches / new files from your local repository (such as svk and git) that I hope you can figure out a system that works for you. It is a problem that all contributors face, and a great topic for sharing experiences. IMO the additional requirements on the Pack200 code seems to unnecessarily couple implementation with packaging/deployment needs. I don't think making Pack200 a separate bundle will be sufficient to meet all the requirements. Let me try and explain why: - dependency on Java 1.4 syntax and APIs We can easily ensure that the Pack200 code only uses 1.4 syntax by compiling it with the appropriate source flag. However, we cannot ensure it only uses 1.4 APIs since we compile Harmony against itself. The only way to do that is to have a JSE1.4 class library around, which means an additional Harmony dependency. I suggest that we compile the code in a separate source folder as 1.4, but rely upon an out of band build to check that there are no references outside the J2SE-1.4 execution environment. If people commit 5.0 syntax, or code that depends upon 5.0 APIs then it is not your job to fix it -- you should yell on the dev list and have it rolled back. - packaging as a separate bundle In regular OSGi you do not explicitly list java.* packages in the Import-Package statement. They are part of the execution environment hosting the bundle. However, since Harmony is modularizing the class libraries themselves we precisely want to define the scope of the bundle by java.* and their corresponding implementation packages. For the Pack200 code to be a useful bundle in Harmony will require a different Manifest to a bundle that is useful as a regular Eclipse plug-in / Felix bundle / whatever. Harmony's bundles cannot specify a required execution environment. One manifest will not do both jobs. I suggest that there needs to be a separate project description and Manifest for a 'regular' Pack200 bundle outside the modules source tree, that links to the same source folder containing the same implementation code. Then there can be a 'Harmony view' and 'regular bundle view' of the same code. - NLS messages Sure, if the code is going to be separable, then it needs a way to take only it's own messages away. The mechanism for loading messages is lightweight so I suggest there is no need to re-invent that code. So then, does this warrant a new module, and what is a module anyway? Why is 'regex' a module, etc? The original discovery of modules was driven by the observed coupling in the APIs and implementation of the class library code. We split up groups of functionally coherent behaviour, and declared them a module. Later we decided that we would not split along the API's SPI boundaries too, so, for example, the LDAP and DNS providers are in the JNDI module, and the SHA1, PKCS code are in SECURITY module etc. I see the Pack200 being similar. It is a provider to the ARCHIVE module, and by the same reasoning would be part of that module. The additional requirements means that I'd ensure it was in a separate source folder, and a non-Harmony module project made to deliver that code into a regular OSGi bundle for consumption elsewhere. Could we have made a different choice about projects? Sure. We could pick finer-grained bundles and pull out all the reusable pieces and providers into projects/bundles. I can imagine having at least 3x as many modules for Harmony [aside: I've always wanted separate test code projects]. That is how we got to this set of modules and their 'semantic size'. Could we, or should we, have done it differently? Maybe, it has worked well for us so far in terms of resolving multiple contributions, and switching different implementations (was it 3 RMI's at one point?!). But like all parents, you know that if you are asked 'why?' enough times then the answer will eventually be 'because!' <g>. If we want to revisit this decision then fine, but let's do so consistently for the whole project, and not build a patchwork architecture of different local decisions. I've seen good-will on both sides to try and get a workable solution. Let's keep talking until we get a satisfactory resolution. And in the meantime,keep hacking on the code :-) Regards, Tim
