harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Zakharov" <alexei.zakha...@gmail.com>
Subject [classlib][pack200] new module (was: [classlib][pack200] Development has stalled :-( )
Date Sat, 06 Jan 2007 20:46:33 GMT
Hi all,

I've just finished with moving pack200 code to the new module
(r493560). The name of the new module is "pack200" (no surprises), new
package names start with "org.apache.harmony.pack200". The build can
be customized for using arbitrary build source and build target (Alex
has asked for it). One test is currently failing:
org/apache/harmony/pack200/tests/SegmentTest
so I've put it to the exclude list. I don't know why does it fail,
probably because of the package name change. I suppose Alex can shed
light on it.  There are also files that probably need fixing -
META-INF/MANIFEST.MF for example. So patches are welcome as always.

I've seen build failure alerts after my commits - there were problems
with ant clean. After running ant clean twice all problems disappear
on my machine. So..

Thanks for your attention and Merry Christmas to the Orthodox part of
the community,

2006/12/14, Alexei Zakharov <alexei.zakharov@gmail.com>:
> 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