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 -- Karl Pauls [email protected]
