harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sian January" <sianjanu...@googlemail.com>
Subject Re: [pack200] Merge code back into archive?
Date Mon, 24 Sep 2007 08:25:17 GMT
I don't really have a preference either way on this, but it seems to make
sense to keep it as its own module for now while it's being developed, and
then review the decision at a later date.  I wouldn't want to move it all
into archive, only to discover that we need to move it back again.  I agree
with Pascal that there are other scenarios where people may want to use it
on its own, as well as just the 1.4 VM scenario.



On 23/09/2007, Tim Ellison <t.p.ellison@gmail.com> wrote:
> Alex Blewitt wrote:
> > I sent a while arguing for the pack200 code to be a separate bundle,
> > and therefore set up with its own source trees in the archive module.
> > The plan was that the pack200 bundle could be used in other OSGi
> > engines on its own outside of Harmony.
> >
> > The plan didn't work out quite as expected in that it took longer to
> > get going than planned, and since Java 1.4 is nearing EOL it probably
> > doesn't make sense for the pack200 to be available as an OSGi bundle
> > in its own right. In any case, I ended up letting the implementation
> > slide and now it's been taken over by others.
> >
> > So it might be a good time to consider folding it back into the main
> > archive source folders/locations. Sound like a good idea?
> I will let those who have taken over it's implementation make the
> decision, but (always being one to express an opinion <g>) I see no harm
> in it continuing as a separate module while the functionality is
> completed.  It would be trivial to make it 1.4 compatible, roll it into
> ARCHIVE, or make it a fragment bundle later.
> Regards,
> Tim

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message