Great stuff; I had to dig around quite a lot to determine slight changes in parameter names, now we ask you if we're in doubt:)
I ditched my first two attempts at converting to commons-compress,the patch you're looking at now is take 3. I think that the way to go with this stuff is to convert *all* the implementations to use commons-compress (in the same style) and actually *remove* the implementations from plexus-archiver. The archivers in use are actually not visible to the clients of plexus-archiver, and I was intending to find out to which extent the abstractions in plexus-archiver leak and hence expose the innards into client code (ugly casts and similar come to mind). We should be able to get a high-level verification that this works by running all the IT's for the maven plugins with an updated version. I was a bit scared by the testing aspect, but if anyone wants to try porting "more" archivers I suggest you just fork my repo and we can work further on it. I really think we should port all of them, and I'll see if I can get some work done on it this weekend. plexus-archiver definitely contains a higher-level API. Once we finish the porting I think it would be interesting to see what remains and if it would have any applicability outside maven. Kristian 2014-09-12 9:30 GMT+02:00 Stefan Bodewig <[email protected]>: > On 2014-09-12, Kristian Rosenvold wrote: > >> The thing with the patch was that it took me some time to figure out >> "at what level" plexus-archiver and commons compress were >> "compatible"; we are after all talking about code >> with the same ancient origins. > > I'm really just a lurker on this list but the subject tickled my fancy. > Let's say I'm both deeply familiar with the "ancient origins" and the > current Commons Compress code base while I don't know much about Plexus. > If you need some details about how CC evolved, want to discuss some > things or just need help with anything, feel free to reach out to me. > > Basing Plexus Archiver on top of CC sounds like a good idea to me. I > may add that CC has some open tickets about a higher level API than we > currently provide - something Plexus might be providing. > > Looking at your patch, it seems straight forward. The biggest change in > the zip code that is visible from the outside is Zip64 support - > i.e. dealing with really big entries/archives - something you need to be > explicit about[1] when creating an archive since not all unarchivers > support Zip64 and you may want to avoid the overhead unless it is > necessary. It might be a good idea to make this choice explicit for the > *Archiver classes as well. > > Stefan > > [1] http://commons.apache.org/proper/commons-compress/zip.html#zip64 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
