You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Dan Tran <da...@gmail.com> on 2014/09/11 23:19:59 UTC
Replacing plexus-archiver with commons-compress?
>From today's maven hangout discussion
Just want to let you know Kristian Rosenvold
<https://plus.google.com/u/0/112402174582006942652?prsrc=4> mentioned [1]
he did some work on this area
-D
[1]
http://maven.40175.n5.nabble.com/Use-native-tar-to-unpack-good-bad-idea-td5794712.html
Re: Replacing plexus-archiver with commons-compress?
Posted by Kristian Rosenvold <kr...@gmail.com>.
FWIW, I just completed /most/ of the conversion to commons-compress for the rest
of plexus-archiver; just so no-one else starts duplicating my work :)
K
2014-09-12 11:12 GMT+02:00 Stefan Bodewig <bo...@apache.org>:
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Replacing plexus-archiver with commons-compress?
Posted by Stefan Bodewig <bo...@apache.org>.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Replacing plexus-archiver with commons-compress?
Posted by Kristian Rosenvold <kr...@gmail.com>.
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 <bo...@apache.org>:
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Replacing plexus-archiver with commons-compress?
Posted by Stefan Bodewig <bo...@apache.org>.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Replacing plexus-archiver with commons-compress?
Posted by Kristian Rosenvold <kr...@gmail.com>.
I implemented Zip via commons compress, and the patch can be seen here
https://github.com/krosenvold/plexus-archiver/tree/commonsCompressZipOutputStrea
I was planning to push the change, but I was somewhat set back by the
testing need, and I did not want to leave plexus-archiver in a "limbo"
state :) I figure the patch is OK as such.
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 think my patch sets an example that
could be applied to the other archivers to migrate everything to
commons-compress.
I think we need to request a full round of community re-testing before
we release such a thing. But given the general number of bugs that are
present in plexus that should be fixed by migrating, there should be
some community interest...
Kristian
2014-09-11 23:19 GMT+02:00 Dan Tran <da...@gmail.com>:
> From today's maven hangout discussion
>
> Just want to let you know Kristian Rosenvold
> <https://plus.google.com/u/0/112402174582006942652?prsrc=4> mentioned [1]
> he did some work on this area
>
> -D
>
> [1]
> http://maven.40175.n5.nabble.com/Use-native-tar-to-unpack-good-bad-idea-td5794712.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org