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: [classlib][pack200] new module (was: [classlib][pack200] Development has stalled :-( )
Date Sun, 07 Jan 2007 09:24:44 GMT
Great, thanks for that. I'll investigate the Segment test ... it's
probably because it was looking a resource up by name and if the
resources/ have moved into the harmony/pack200 folder it can't find
them. Shouldn't be too tricky to fix.

I'll also update the Manifest and/or other files that fixing and
submit a patch shortly.

Thanks again!

Alex.

On 06/01/07, Alexei Zakharov <alexei.zakharov@gmail.com> wrote:
> 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