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] >
