All, Does anyone have real objections to this Alex's proposal? If no I can take care of it.
Thanks, 2006/12/14, Alex Blewitt <[EMAIL PROTECTED]>:
> Agreed, in general we cannot serialize on waiting for patches to be > committed before moving on, and keeping track of your development can be > a problem in the face of multiple patches and commits etc. Actually, in this case, there is no patch. This is the discussion about moving the pack200 code to a separate module [1], like I've been suggesting from the beginning [2], so that it can be built with a lower Java version (both via the build.xml, the associated Eclipse metadata and the compliance settings for the bundle itself) than the remainder of the archive module. It will also mean that we don't end up with messages being mixed together, which will be more of a problem when it comes to distributing the decoding as a separate bundle externally to Harmony, which was one of my original motiviations in doing this [2] In any case, it doesn't make sense to me to be in-flight doing work whilst the code is in the wrong place (from my point of view, at least). Generating SVN patches after doing a lot of (renaming) refactoring seems to break things, and the only way that the most recent set of code was integrated was by me providing the entire contents of the project that I was working on. If there's directory moves (and/or package names, if it moves to a different module) then it's going to make that process a lot more painful than it already is. I'm sure there's reasons why the general feeling is that it shouldn't be moved out into its own module, but I've not seen a suggestion yet which addresses the issues I've outlined above; though please let me know if I've misunderstood something and it is in fact possible. Unfortunately, I get the feeling we're at an impasse on this, and that in order to achieve my original goal of having an implementation that could be used by other OSGi systems, it would be better to develop this as an entirely standalone OSGi bundle which Harmony could then chose to use if it wanted. This isn't my preferred option, since after all Harmony needs this code, and it's likely to be a better up-stream source for changes in the future, but rather than me trying to repeatedly initiate conversations about why I think it would be better to move it to a separate module, it will likely be easier for me to develop code against a repository which I have write access and an structure it appropriately. Since it too will be licensed under AL, Harmony can then chose to take advantage of it or someone else can continue working on the codebase so far. Alex. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200610.mbox/[EMAIL PROTECTED] [2] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/[EMAIL PROTECTED]
-- Alexei Zakharov, Intel ESSD
