harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Zakharov" <alexei.zakha...@gmail.com>
Subject Re: Re: [classlib][pack200] Development has stalled :-(
Date Thu, 14 Dec 2006 16:55:27 GMT
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 <alex.blewitt@gmail.com>:
> > 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/%3C636fd28e0610141654rcd650f8x32c7c2b311a5fd65@mail.gmail.com%3E
>
> [2] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/%3c636fd28e0605251346m47a5289ch1e61ce611d0de615@mail.gmail.com%3e
>


-- 
Alexei Zakharov,
Intel ESSD

Mime
View raw message