You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stefan Bodewig <bo...@apache.org> on 2014/02/27 08:03:36 UTC
[compress] Planning 1.8 Release
Hi all,
this is a heads-up that I intend to cut a RC for Compress 1.8 soon. We
have accumulated a few bugfixes and at least COMPRESS-264 is pretty
serious.
I've already updated the website from trunk (basically to have the new
skin online) so you can already have a look at the reports.
Before I cut the release I intend to spike a solution for COMPRESS-257
which could bring us about six new filters supported as 7z methods
because they are supported by XZ for Java - if this turns out to be more
difficult than it looks right now, I wouldn't delay the release for it.
I don't intend to work on any other issue before the release, so if you
want anything else to go in, please speak up.
Apart from the bugfixing we've added better support for 7z compression
methods - you can now chose a stack of more than one method when writing
(this has always been possible when reading), pass options to the
methods and use different configurations per entry. The core of this
are the new get/setContentMethods methods in SevenZOutpuzFile and
SevenZArchiveEntry along with the new SevenZMethodConfiguration class.
I'm notoriously bad at naming and am not too sure about the API I've
created, so any feedback on either or the minimal documentation I've
added to Javadoc and the examples page is more than welcome.
Cheers
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] Planning 1.8 Release
Posted by Stefan Bodewig <bo...@apache.org>.
On 2014-02-27, Benedikt Ritter wrote:
> the project reports look good to me. Some package have low test coverage
> but I think you've already said that it's pretty hard to write tests for
> this areas of the code. PMD shows four violations. The first three look
> like they can be fixed easily.
Not sure about the "too many static imports" errors, we've always
ignored them. I think the crc field is currently only written as our
zip classes (regrettably) ignore the CRC - so it is nit really unused
but just never read.
As for test coverage, the coverage inside the 7z package has actually
improved over 1.7 and I don't think it has gotten worse in any other
package.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] Planning 1.8 Release
Posted by Benedikt Ritter <br...@apache.org>.
Hello Stefan,
the project reports look good to me. Some package have low test coverage
but I think you've already said that it's pretty hard to write tests for
this areas of the code. PMD shows four violations. The first three look
like they can be fixed easily.
Benedikt
2014-02-27 8:03 GMT+01:00 Stefan Bodewig <bo...@apache.org>:
> Hi all,
>
> this is a heads-up that I intend to cut a RC for Compress 1.8 soon. We
> have accumulated a few bugfixes and at least COMPRESS-264 is pretty
> serious.
>
> I've already updated the website from trunk (basically to have the new
> skin online) so you can already have a look at the reports.
>
> Before I cut the release I intend to spike a solution for COMPRESS-257
> which could bring us about six new filters supported as 7z methods
> because they are supported by XZ for Java - if this turns out to be more
> difficult than it looks right now, I wouldn't delay the release for it.
> I don't intend to work on any other issue before the release, so if you
> want anything else to go in, please speak up.
>
> Apart from the bugfixing we've added better support for 7z compression
> methods - you can now chose a stack of more than one method when writing
> (this has always been possible when reading), pass options to the
> methods and use different configurations per entry. The core of this
> are the new get/setContentMethods methods in SevenZOutpuzFile and
> SevenZArchiveEntry along with the new SevenZMethodConfiguration class.
> I'm notoriously bad at naming and am not too sure about the API I've
> created, so any feedback on either or the minimal documentation I've
> added to Javadoc and the examples page is more than welcome.
>
> Cheers
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [compress] Planning 1.8 Release
Posted by Gary Gregory <ga...@gmail.com>.
It looks like this should be a smooth release :)
Gary
On Thu, Feb 27, 2014 at 2:03 AM, Stefan Bodewig <bo...@apache.org> wrote:
> Hi all,
>
> this is a heads-up that I intend to cut a RC for Compress 1.8 soon. We
> have accumulated a few bugfixes and at least COMPRESS-264 is pretty
> serious.
>
> I've already updated the website from trunk (basically to have the new
> skin online) so you can already have a look at the reports.
>
> Before I cut the release I intend to spike a solution for COMPRESS-257
> which could bring us about six new filters supported as 7z methods
> because they are supported by XZ for Java - if this turns out to be more
> difficult than it looks right now, I wouldn't delay the release for it.
> I don't intend to work on any other issue before the release, so if you
> want anything else to go in, please speak up.
>
> Apart from the bugfixing we've added better support for 7z compression
> methods - you can now chose a stack of more than one method when writing
> (this has always been possible when reading), pass options to the
> methods and use different configurations per entry. The core of this
> are the new get/setContentMethods methods in SevenZOutpuzFile and
> SevenZArchiveEntry along with the new SevenZMethodConfiguration class.
> I'm notoriously bad at naming and am not too sure about the API I've
> created, so any feedback on either or the minimal documentation I've
> added to Javadoc and the examples page is more than welcome.
>
> Cheers
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [compress] Planning 1.8 Release
Posted by Stefan Bodewig <bo...@apache.org>.
> Apart from the bugfixing we've added better support for 7z compression
> methods - you can now chose a stack of more than one method when writing
> (this has always been possible when reading), pass options to the
> methods and use different configurations per entry. The core of this
> are the new get/setContentMethods methods in SevenZOutpuzFile and
> SevenZArchiveEntry along with the new SevenZMethodConfiguration class.
To summarize some discussion from IRC back to the list:
The main change is this one
<http://svn.apache.org/viewvc/commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/sevenz/SevenZArchiveEntry.java?r1=1552756&r2=1571923>
with some later variations. The Iterable as argument to the setter
looks inconvenient and a varargs signature may be more user friendly -
in particular in a use-case where you only want to pass in a single
"method".
Personally I prefer to keep getter and setter symmetric and don't like
the idea of copying things around in order to not expose state if the
API was array based. The inconvenience is just an extra Arrays.asList
for the user.
But I don't have any strong feelings either way.
The API is not going to be used much as most people will read archives
or create archives with just a single method. The major use-case I
envision is copying entries from one archive to another and keeping the
same methods.
Any thoughts?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org