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 <[EMAIL PROTECTED]>:
> 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
