Interesting, I came actually to the same conclusion already implemented
it that way 😉
Carsten
On 19.02.2020 17:10, Julian Sedding wrote:
Hi all
The ZIP file format (and the Java API) allows different compression levels
per entry. Couldn’t we just not compress all embedded binary artifacts and
have the best of both worlds? That is, assuming we know which files need to
be uncompressed for the use case Karl mentioned.
Regards
Julian
On Wed, 19 Feb 2020 at 11:11, Carsten Ziegeler <[email protected]> wrote:
We could also simplify and say the archive is never compressed and we
only support that. I don't think that not compressing is a problem for
the binaries we put in there. If you have a huge feature model, then it
might make a difference as David points out. But I would also argue that
in that case you have a lot of artifacts. So again, it would not make
that much of a difference
In addition - and that's probably not clear from my proposal - you can
use any extension with these archives. However, if we think of
supporting them in some tools, for example the OSGi installer, then we
need to detect such archives. Using an extension for that sounds like a
natural fit; however, we could also simply look at the manifest of the
archive. That's for example what we do for content packages which
usually have the general extension zip.
So in other words, we don't need to worry about defining an extension
and just look at the manifest of the provided zip file.
And we could either make compression configurable or not compress at all.
WDYT?
Carsten
On 19.02.2020 11:06, Karl Pauls wrote:
I'm not sure we need to have a second extension. I would assume the
archive can be attached via a classifier anyways - hence, if you want
to provide both, an uncompressed and a compressed version, I guess you
can just encode the difference in the classifier name. Personally, I
would be fine with just making the extension be "zip" to begin with
since it sounds like that is all it is anyways (at least for now) but
I don't really feel strongly about it - if I can use it to create
uncompressed zips with everything in it I'm a happy camper already
:-).
regards,
Karl
On Wed, Feb 19, 2020 at 11:00 AM Bertrand Delacretaz
<[email protected]> wrote:
Hi,
On Wed, Feb 19, 2020 at 7:12 AM Carsten Ziegeler <[email protected]>
wrote:
...Having an option for compressing sounds good to me, but I get a
little
bit worried to support two extensions. It is transparent for the user
of
the archive..
Karl seems to imply that having an uncompressed archive is required
for some use cases so I suppose there's a need for the "consumers" of
those archives to be able to specify that they require the
uncompressed version?
If that's correct, a way of identifying those uncompressed versions is
required, IMHO.
That can be the file extension, or maybe a Maven classifier?
A common pattern used for tar archives is to add a suffix to indicate
compression, such as .tar.gz
-Bertrand
--
--
Carsten Ziegeler
Adobe Research Switzerland
[email protected]
--
--
Carsten Ziegeler
Adobe Research Switzerland
[email protected]
