harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Blewitt" <alex.blew...@gmail.com>
Subject Re: Re: [classlib][pack200] Development has stalled :-(
Date Thu, 14 Dec 2006 13:12:15 GMT
> 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.


[1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200610.mbox/%3C636fd28e0610141654rcd650f8x32c7c2b311a5fd65@mail.gmail.com%3E

[2] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/%3c636fd28e0605251346m47a5289ch1e61ce611d0de615@mail.gmail.com%3e

View raw message