> So we could do 1.21 as is followed by 1.22 with pack200 support.
>
+1
Lee
On 11, 1, 2020, at 11:59, Gary Gregory wrote:
> It's been quite a while since this thread started so I will review my
> branch today but might wait for 1.22.
>
> While we indicated that we would address building and
It's been quite a while since this thread started so I will review my
branch today but might wait for 1.22.
While we indicated that we would address building and running pack200 in
some way on Java 14+ for 1.21, an option is to release 1.21 as is since
there are quite a few changes there already
Hi All,
As the next step in the pack200 branch, I've renamed the package
org.apache.harmony to org.apache.commons.compress.harmony to more easily
track potential future changes. If this looks acceptable, it can be merged
and documented.
The builds are green here
Thanks Peter, I updated the branch and the build passes for me locally, the
CI is building now here
https://github.com/apache/commons-compress/actions/runs/19115
Gary
On Sun, Aug 23, 2020 at 11:40 PM Peter Lee wrote:
> After some debugging I found this at
>
After some debugging I found this at org.apache.harmony.pack200.Archive#171 :
if (classes.size() > 0 && files.size() > 0) {
segmentUnitList.add(new SegmentUnit(classes, files));
}
Seems the Pack200 implementation in harmony requires existing of both classes
AND files at the same time. The tests
Hi All,
I created a branch called *pack200* which contains the Apache Harmony
Pack200 code.
If there are 2 failing unit test ATM if anyone wants to help out.
Gary
On 2011-09-14, Emmanuel Bourg wrote:
Le 14/09/2011 17:16, Stefan Bodewig a écrit :
Emmanuel, is the Pack200Utils.normalize method I've just committed what
you've been looking for?
Yes that's what I had in mind, thank you.
You might also want to support repacking a file to itself, that's a
On 2011-09-15, Emmanuel Bourg wrote:
Le 15/09/2011 11:46, Stefan Bodewig a écrit :
BTW, I've added pack200 support to the Compress Antlib (tasks and a
pack200resource) and will push for a release once CC 1.3 is out.
Pack200 tasks available out of the box with Ant would be really nice,
The
On 2011-09-05, Stefan Bodewig wrote:
On 2011-09-05, Emmanuel Bourg wrote:
That looks interesting. Does it provide a repack mode suitable for
signing compressed jars?
I assume you mean
,
| Note that packing and unpacking a JAR will in general alter the bytewise
| contents of
On 2011-09-05, Stefan Bodewig wrote:
On 2011-09-05, Emmanuel Bourg wrote:
That looks interesting. Does it provide a repack mode suitable for
signing compressed jars?
I assume you mean
,
| Note that packing and unpacking a JAR will in general alter the bytewise
| contents of
That looks interesting. Does it provide a repack mode suitable for
signing compressed jars?
Emmanuel Bourg
Le 04/09/2011 08:04, Stefan Bodewig a écrit :
Hi,
I've just committed Converter*Stream implementations for Pack200[1]
which is a bit unusual in several ways.
First of all it will (by
On 2011-09-04, sebb wrote:
You must have put a lot of thought into this
Well, I was without network access for almost two weeks 8-)
it would be useful to record these design decisions and investigations
in the code somewhere. e.g. as package Javadoc.
The current package.html already
On 2011-09-05, Emmanuel Bourg wrote:
That looks interesting. Does it provide a repack mode suitable for
signing compressed jars?
I assume you mean
,
| Note that packing and unpacking a JAR will in general alter the bytewise
| contents of classfiles in the JAR. This means that packing and
Hi,
I've just committed Converter*Stream implementations for Pack200[1]
which is a bit unusual in several ways.
First of all it will (by design of the format) only work on compressing
valid jar files. Actually the result isn't likely to be compressed (in
the sense of smaller than the original)
On 4 September 2011 07:04, Stefan Bodewig bode...@apache.org wrote:
Hi,
I've just committed Converter*Stream implementations for Pack200[1]
which is a bit unusual in several ways.
First of all it will (by design of the format) only work on compressing
valid jar files. Actually the result
15 matches
Mail list logo
