sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: [Feature Model] Feature Archive?
Date Wed, 19 Feb 2020 10:11:57 GMT
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.



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
> <> wrote:
>> Hi,
>> On Wed, Feb 19, 2020 at 7:12 AM Carsten Ziegeler <> 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

View raw message