On 2014-09-12, Kristian Rosenvold wrote: > 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).
At least it looks as if you were leaking the stream classes and in some cases the *Entry classes in your protected API. Not sure how much of this is used by clients of plexus-archiver at all and whether you consider this a part of your public API. > but if anyone wants to try porting "more" archivers I suggest you just > fork my repo and we can work further on it. Hmm, bzip2 is already based on Commons Compress so this leaves gzip and tar as the only formats unless I'm overlooking something. tar has undergone quite a few revisions but at least until recently (1.8) gzip in CC has only been using java.util.zip under the covers as well. By now it uses an implementation of its own since we want to deal with concatenated streams and provide access to the gzip meta data - not sure this is of value for plexus-archiver as these features would need to be exposed via the plexus API to be useful as well. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
