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 2015/01/26 07:05:08 UTC
[VOTE] Release Compress 1.10 Based on RC1
As inidcated last week, here is the first RC for Compress 1.10.
Compress 1.10 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/compress/
(svn revision 7828)
Maven artifacts are here:
https://repository.apache.org/content/repositories/orgapachecommons-1080/org/apache/commons/commons-compress/1.10/
Details of changes since 1.9 are in the release notes:
https://dist.apache.org/repos/dist/dev/commons/compress/RELEASE-NOTES.txt
http://people.apache.org/~bodewig/compress-1.10-RC1/changes-report.html
The tag is here:
http://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.10-RC1
(svn revision 1654723)
Site:
http://people.apache.org/~bodewig/compress-1.10-RC1/
Clirr Report (compared to 1.9):
http://people.apache.org/~bodewig/compress-1.10-RC1/clirr-report.html
RAT Report:
http://people.apache.org/~bodewig/compress-1.10-RC1/rat-report.html
KEYS:
https://www.apache.org/dist/commons/KEYS
Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now, i.e. after
0600 GMT 29-January 2015
[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...
Thanks!
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[CANCEL][VOTE] Release Compress 1.10 Based on RC1
Posted by Stefan Bodewig <bo...@apache.org>.
On 2015-01-27, Gary Gregory wrote:
> On Tue, Jan 27, 2015 at 4:54 AM, Kristian Rosenvold <
> kristian.rosenvold@gmail.com> wrote:
>> I've run through all of our tests and the release looks good.
>> The testcase should fail 1 in 1000 times as is and has been fixed.
>> I'm +1 on the release as such (but we'd normally recut or leave this
>> decision to the RM....).
> I'd prefer a clean RC to give a positive vote. So I'll abstain for now.
I'll roll another RC on Friday (I'm travelling and haven't got access to
my GPG keyring right now). I'll also address the website issue Gary
mentioned (except for the changes report, my process is different, I
re-create the site once the release is through ;-).
IIRC the "unused private method" warnings are all false positives we've
been seeing since the plugin got upgraded.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Compress 1.10 Based on RC1
Posted by Kristian Rosenvold <kr...@apache.org>.
2015-01-27 15:24 GMT+01:00 Gary Gregory <ga...@gmail.com>:
> I'd prefer a clean RC to give a positive vote. So I'll abstain for now.
That seems to be the norm :)
K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Compress 1.10 Based on RC1
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Jan 27, 2015 at 4:54 AM, Kristian Rosenvold <
kristian.rosenvold@gmail.com> wrote:
> I've run through all of our tests and the release looks good.
>
> The testcase should fail 1 in 1000 times as is and has been fixed.
>
> I'm +1 on the release as such (but we'd normally recut or leave this
> decision to the RM....).
>
>
I'd prefer a clean RC to give a positive vote. So I'll abstain for now.
Gary
> Krisian
>
> 2015-01-27 7:35 GMT+01:00 Kristian Rosenvold <kristian.rosenvold@gmail.com
> >:
> > Done in r1654980.
> >
> > This whole incident is a confirmation of murphys law; I must've run
> > that test 500 times on my machine without failure =:)
> >
> > K
> >
> >
> > 2015-01-27 0:10 GMT+01:00 Gary Gregory <ga...@gmail.com>:
> >> I see you changed the test but the code could benefit from a comment to
> >> avoid a future regression back to this problem.
> >>
> >> Gary
> >>
> >> On Mon, Jan 26, 2015 at 4:52 PM, Kristian Rosenvold <
> krosenvold@apache.org>
> >> wrote:
> >>
> >>> Testcase fixed in r1654901
> >>>
> >>> Kristian
> >>>
> >>>
> >>> 2015-01-26 22:37 GMT+01:00 Kristian Rosenvold <
> >>> kristian.rosenvold@gmail.com>:
> >>> > 2015-01-26 22:27 GMT+01:00 Gary Gregory <ga...@gmail.com>:
> >>> >> Tests:
> >>> >>
> >>> >> Running: 'mvn clean site' gave me
> >>> >>
> >>> >> Failed tests:
> >>> >>
> >>>
> ZipTestCase.testCopyRawZip64EntryFromFile:361->assertSameFileContents:414
> >>> >> arrays first differed at element [10]; expected:<-16> but was:<-15>
> >>> >
> >>> > The problem appears to be that time does not stand still, and every
> >>> > now and then you can make "expected" and "actual" get different time
> >>> > stamps (with the 2 second granularity of zip it takes a bit of "luck"
> >>> > to hit the problem)
> >>> >
> >>> > The problem is within the testcase itself, and I'll fix this on
> trunk.
> >>> >
> >>> > Kristian
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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
>
> ---------------------------------------------------------------------
> 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: [VOTE] Release Compress 1.10 Based on RC1
Posted by Kristian Rosenvold <kr...@gmail.com>.
I've run through all of our tests and the release looks good.
The testcase should fail 1 in 1000 times as is and has been fixed.
I'm +1 on the release as such (but we'd normally recut or leave this
decision to the RM....).
Krisian
2015-01-27 7:35 GMT+01:00 Kristian Rosenvold <kr...@gmail.com>:
> Done in r1654980.
>
> This whole incident is a confirmation of murphys law; I must've run
> that test 500 times on my machine without failure =:)
>
> K
>
>
> 2015-01-27 0:10 GMT+01:00 Gary Gregory <ga...@gmail.com>:
>> I see you changed the test but the code could benefit from a comment to
>> avoid a future regression back to this problem.
>>
>> Gary
>>
>> On Mon, Jan 26, 2015 at 4:52 PM, Kristian Rosenvold <kr...@apache.org>
>> wrote:
>>
>>> Testcase fixed in r1654901
>>>
>>> Kristian
>>>
>>>
>>> 2015-01-26 22:37 GMT+01:00 Kristian Rosenvold <
>>> kristian.rosenvold@gmail.com>:
>>> > 2015-01-26 22:27 GMT+01:00 Gary Gregory <ga...@gmail.com>:
>>> >> Tests:
>>> >>
>>> >> Running: 'mvn clean site' gave me
>>> >>
>>> >> Failed tests:
>>> >>
>>> ZipTestCase.testCopyRawZip64EntryFromFile:361->assertSameFileContents:414
>>> >> arrays first differed at element [10]; expected:<-16> but was:<-15>
>>> >
>>> > The problem appears to be that time does not stand still, and every
>>> > now and then you can make "expected" and "actual" get different time
>>> > stamps (with the 2 second granularity of zip it takes a bit of "luck"
>>> > to hit the problem)
>>> >
>>> > The problem is within the testcase itself, and I'll fix this on trunk.
>>> >
>>> > Kristian
>>>
>>> ---------------------------------------------------------------------
>>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Compress 1.10 Based on RC1
Posted by Kristian Rosenvold <kr...@gmail.com>.
Done in r1654980.
This whole incident is a confirmation of murphys law; I must've run
that test 500 times on my machine without failure =:)
K
2015-01-27 0:10 GMT+01:00 Gary Gregory <ga...@gmail.com>:
> I see you changed the test but the code could benefit from a comment to
> avoid a future regression back to this problem.
>
> Gary
>
> On Mon, Jan 26, 2015 at 4:52 PM, Kristian Rosenvold <kr...@apache.org>
> wrote:
>
>> Testcase fixed in r1654901
>>
>> Kristian
>>
>>
>> 2015-01-26 22:37 GMT+01:00 Kristian Rosenvold <
>> kristian.rosenvold@gmail.com>:
>> > 2015-01-26 22:27 GMT+01:00 Gary Gregory <ga...@gmail.com>:
>> >> Tests:
>> >>
>> >> Running: 'mvn clean site' gave me
>> >>
>> >> Failed tests:
>> >>
>> ZipTestCase.testCopyRawZip64EntryFromFile:361->assertSameFileContents:414
>> >> arrays first differed at element [10]; expected:<-16> but was:<-15>
>> >
>> > The problem appears to be that time does not stand still, and every
>> > now and then you can make "expected" and "actual" get different time
>> > stamps (with the 2 second granularity of zip it takes a bit of "luck"
>> > to hit the problem)
>> >
>> > The problem is within the testcase itself, and I'll fix this on trunk.
>> >
>> > Kristian
>>
>> ---------------------------------------------------------------------
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Compress 1.10 Based on RC1
Posted by Gary Gregory <ga...@gmail.com>.
I see you changed the test but the code could benefit from a comment to
avoid a future regression back to this problem.
Gary
On Mon, Jan 26, 2015 at 4:52 PM, Kristian Rosenvold <kr...@apache.org>
wrote:
> Testcase fixed in r1654901
>
> Kristian
>
>
> 2015-01-26 22:37 GMT+01:00 Kristian Rosenvold <
> kristian.rosenvold@gmail.com>:
> > 2015-01-26 22:27 GMT+01:00 Gary Gregory <ga...@gmail.com>:
> >> Tests:
> >>
> >> Running: 'mvn clean site' gave me
> >>
> >> Failed tests:
> >>
> ZipTestCase.testCopyRawZip64EntryFromFile:361->assertSameFileContents:414
> >> arrays first differed at element [10]; expected:<-16> but was:<-15>
> >
> > The problem appears to be that time does not stand still, and every
> > now and then you can make "expected" and "actual" get different time
> > stamps (with the 2 second granularity of zip it takes a bit of "luck"
> > to hit the problem)
> >
> > The problem is within the testcase itself, and I'll fix this on trunk.
> >
> > Kristian
>
> ---------------------------------------------------------------------
> 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: [VOTE] Release Compress 1.10 Based on RC1
Posted by Kristian Rosenvold <kr...@apache.org>.
Testcase fixed in r1654901
Kristian
2015-01-26 22:37 GMT+01:00 Kristian Rosenvold <kr...@gmail.com>:
> 2015-01-26 22:27 GMT+01:00 Gary Gregory <ga...@gmail.com>:
>> Tests:
>>
>> Running: 'mvn clean site' gave me
>>
>> Failed tests:
>> ZipTestCase.testCopyRawZip64EntryFromFile:361->assertSameFileContents:414
>> arrays first differed at element [10]; expected:<-16> but was:<-15>
>
> The problem appears to be that time does not stand still, and every
> now and then you can make "expected" and "actual" get different time
> stamps (with the 2 second granularity of zip it takes a bit of "luck"
> to hit the problem)
>
> The problem is within the testcase itself, and I'll fix this on trunk.
>
> Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Compress 1.10 Based on RC1
Posted by Kristian Rosenvold <kr...@gmail.com>.
2015-01-26 22:27 GMT+01:00 Gary Gregory <ga...@gmail.com>:
> Tests:
>
> Running: 'mvn clean site' gave me
>
> Failed tests:
> ZipTestCase.testCopyRawZip64EntryFromFile:361->assertSameFileContents:414
> arrays first differed at element [10]; expected:<-16> but was:<-15>
The problem appears to be that time does not stand still, and every
now and then you can make "expected" and "actual" get different time
stamps (with the 2 second granularity of zip it takes a bit of "luck"
to hit the problem)
The problem is within the testcase itself, and I'll fix this on trunk.
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Compress 1.10 Based on RC1
Posted by Gary Gregory <ga...@gmail.com>.
Thank you for preparing this RC Stefan.
Using with src zip from binary dist folder:
MD5 OK.
ASC OK.
Tests:
Running: 'mvn clean site' gave me
Failed tests:
ZipTestCase.testCopyRawZip64EntryFromFile:361->assertSameFileContents:414
arrays first differed at element [10]; expected:<-16> but was:<-15>
The HEAD of trunk passes this test in Eclipse (Java 7).
Running 'mvn test' solo was OK.
Running 'mvn clean test' again was OK.
Running 'mvn clean site' again was OK.
Can anyone shed some light on this 'random' error? My PC might have been
super busy at the time.
I am on:
Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1;
2014-12-14T12:29:23-05:00)
Maven home: C:\Java\apache-maven-3.2.5
Java version: 1.7.0_75, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_75\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
Site:
Typo: What's new in 1.10? "the old" -> "The old".
Changes report says "Release 1.10 – not released, yet". I like to use the
RC date here so you do not have to change the site post vote. But that's
just my process...
Other reports look good. Clirr shows expected errors due to internal
package name change.
Should be fixed, not a blocker: PMDs for "Avoid unused private methods".
Abstaining for now until RM addresses 'random' test failure.
Gary
On Mon, Jan 26, 2015 at 1:05 AM, Stefan Bodewig <bo...@apache.org> wrote:
> As inidcated last week, here is the first RC for Compress 1.10.
>
> Compress 1.10 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/compress/
> (svn revision 7828)
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1080/org/apache/commons/commons-compress/1.10/
>
> Details of changes since 1.9 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/compress/RELEASE-NOTES.txt
>
> http://people.apache.org/~bodewig/compress-1.10-RC1/changes-report.html
>
> The tag is here:
>
> http://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.10-RC1
> (svn revision 1654723)
>
> Site:
> http://people.apache.org/~bodewig/compress-1.10-RC1/
>
> Clirr Report (compared to 1.9):
> http://people.apache.org/~bodewig/compress-1.10-RC1/clirr-report.html
>
> RAT Report:
> http://people.apache.org/~bodewig/compress-1.10-RC1/rat-report.html
>
> KEYS:
> https://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now, i.e. after
> 0600 GMT 29-January 2015
>
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
>
> Thanks!
>
> 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: [VOTE] Release Compress 1.10 Based on RC1
Posted by sebb <se...@gmail.com>.
On 30 January 2015 at 17:34, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 30/01/2015 17:48, Gary Gregory a écrit :
>
>> Well, we cannot break BC in a minor release for a public class. Are we
>> sure BC breaks?
>>
>> If we want to make this internal package public, it needs to be copied to
>> the new location, not moved. Then ZCompressorInputStream would still extend
>> the internal package.
>
> I thought there was a consensus to allow breaking public classes clearly
> identified as internal such as this one. The Javadoc clearly state:
>
> "This class is only public for technical reasons and is not part of
> Commons Compress' published API - it may change or disappear without
> warning."
>
> And now we can't change it? Sorry but if someone used it this isn't our
> problem, he has been warned and will have to fix his code.
That is not the issue; the issue is that the internal class was part
of the hierarchy of a public class.
See elsethread.
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Compress 1.10 Based on RC1
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 30/01/2015 17:48, Gary Gregory a écrit :
> Well, we cannot break BC in a minor release for a public class. Are we
> sure BC breaks?
>
> If we want to make this internal package public, it needs to be copied to
> the new location, not moved. Then ZCompressorInputStream would still extend
> the internal package.
I thought there was a consensus to allow breaking public classes clearly
identified as internal such as this one. The Javadoc clearly state:
"This class is only public for technical reasons and is not part of
Commons Compress' published API - it may change or disappear without
warning."
And now we can't change it? Sorry but if someone used it this isn't our
problem, he has been warned and will have to fix his code.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Compress 1.10 Based on RC1
Posted by sebb <se...@gmail.com>.
On 30 January 2015 at 16:48, Gary Gregory <ga...@gmail.com> wrote:
> On Fri, Jan 30, 2015 at 6:06 AM, Stefan Bodewig <bo...@apache.org> wrote:
>
>> On 2015-01-30, sebb wrote:
>>
>> > On 30 January 2015 at 08:20, Stefan Bodewig <bo...@apache.org> wrote:
>> >> On 2015-01-28, Benedikt Ritter wrote:
>>
>> >>> - PROPOSAL.txt is not in the src archives. Should it be?
>>
>> >> This is only there for historical reasons, I don't even think the other
>> >> components still have a file like this. I've removed it completely.
>>
>> >>> - there is a typo in the release notes. The first line says "Apache
>> >>> Apache Commons Compress"
>>
>> >> fixed, thanks.
>>
>> >>> - will clients who extended ZCompressorInputStream be affected by the
>> >>> change in it's superclass hierarchy? In other words, is the change to
>> >>> ZCompressorInputStream reported by clirr binary compatible with 1.9?
>>
>> >>> The last one would be a blocker for me. It could be resolved by
>> restoring
>> >>> the _internal_ package and deprecate it right away.
>>
>> >> It is reported as not compatible, so yes, we are breaking backwards
>> >> compatibility.
>>
>> > Note that Clirr does not distinguish binary and source compatibility.
>> > Breaking binary compatibility is almost never a good idea.
>> > However source compatibility may be less important in some cases.
>>
>> > Which incompatibility is it?
>>
>> The superclass of ZCompressorInputStream has changed from one we've
>> removed with the old __internal__ package to a new one in the now
>> supported lzw package.
>>
>
> Well, we cannot break BC in a minor release for a public class. Are we
> sure BC breaks?
>
> If we want to make this internal package public, it needs to be copied to
> the new location, not moved. Then ZCompressorInputStream would still extend
> the internal package.
Not necessarily - that needs to be checked.
Clearly if an accessible method or field has been dropped, or changed,
then it won't be BC.
But if the class or its superclasses still provides the original
protected and public methods and members, it may still be BC.
The JLS [1] has this to say:
"Changing the direct superclass or the set of direct superinterfaces
of a class type will not break compatibility with pre-existing
binaries, provided that the total set of superclasses or
superinterfaces, respectively, of the class type loses no members. "
Given that the original super-class was internal, there is no need to
allow for any direct references to it, e.g. in "instanceof" (which I
imagine would fail BC).
[1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.4.4
> Gary
>
>
>>
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Compress 1.10 Based on RC1
Posted by Stefan Bodewig <bo...@apache.org>.
On 2015-02-27, Gary Gregory wrote:
> What is the conclusion of this vote thread? Did I miss a CANCEL or RESULT
> email while I was gone?
http://mail-archives.apache.org/mod_mbox/commons-dev/201502.mbox/%3C87oapdqxa0.fsf%40v35516.1blu.de%3E
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Compress 1.10 Based on RC1
Posted by Gary Gregory <ga...@gmail.com>.
What is the conclusion of this vote thread? Did I miss a CANCEL or RESULT
email while I was gone?
Gary
On Sat, Jan 31, 2015 at 1:07 AM, Stefan Bodewig <bo...@apache.org> wrote:
> On 2015-01-30, Benedikt Ritter wrote:
>
> > What will happen if a client has overwritten a method from
> > InternalLZWInputStream?
>
> My example already did, close is implemented in InternalLZWInputStream.
>
> I just extended the example to also override setClearCode and it still
> works.
>
> 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: [VOTE] Release Compress 1.10 Based on RC1
Posted by Stefan Bodewig <bo...@apache.org>.
On 2015-01-30, Benedikt Ritter wrote:
> What will happen if a client has overwritten a method from
> InternalLZWInputStream?
My example already did, close is implemented in InternalLZWInputStream.
I just extended the example to also override setClearCode and it still
works.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Compress 1.10 Based on RC1
Posted by Benedikt Ritter <br...@apache.org>.
Hello Stefan,
2015-01-30 20:41 GMT+01:00 Stefan Bodewig <bo...@apache.org>:
> On 2015-01-30, Gary Gregory wrote:
>
> > On Fri, Jan 30, 2015 at 6:06 AM, Stefan Bodewig <bo...@apache.org>
> wrote:
>
> >> The superclass of ZCompressorInputStream has changed from one we've
> >> removed with the old __internal__ package to a new one in the now
> >> supported lzw package.
>
> > Well, we cannot break BC in a minor release for a public class. Are
> > we sure BC breaks?
>
> Well, not as much as my intuition had told me:
>
> public static void main(String[] args) throws Exception {
> try (InputStream in = new FileInputStream(args[0]);
> OutputStream out = new FileOutputStream(args[1]);
> ZCompressorInputStream zin = new ZCompressorInputStream(in) {
> @Override
> public void close() throws IOException {
> System.err.println("closing with code size " +
> codeSize);
> setClearCode(12);
> super.close();
> }
> }) {
> IOUtils.copy(zin, out);
> }
> }
>
> accesses a protected field and a protected method of
> InternalLZWInputStream when compiled against 1.9, a class that is no
> longer there in 1.10. When run against trunk (without recompiling) it
> still works. This is in line with something I once read up in the JLS
> (oh my, nine years ago, time flies)[1]. The compiler says "call the
> protected setClearCode method taking an int arg" and at runtime it
> starts searching for that method with the most derived class. So
> changing superclasses doesn't seem to affect things.
>
> Of course we will break someting like
>
> InternalLZWInputStream s = new ZCompressorInputStream(in)
>
> but then again you'd have used a class that we had explicitly marked as
> internal.
>
> Unless anybody comes up with a case where the change in superclass
> causes a problem, I'd say we are fine.
>
thank you for the research!
What will happen if a client has overwritten a method from
InternalLZWInputStream?
public static void main(String[] args) throws Exception {
try (InputStream in = new FileInputStream(args[0]);
OutputStream out = new FileOutputStream(args[1]);
ZCompressorInputStream zin = new ZCompressorInputStream(in) {
@Override
public void setClearCode(int code) throws IOException {
// reinvent the wheel here...
}
}) {
IOUtils.copy(zin, out);
}
}
My gut feeling tells me this will work as well, but we better double check
to avoid jar hell :-)
Benedikt
>
> Stefan
>
> [1]
> http://stefan.samaflost.de/blog/en/dotNet/difference_between_java_and_csharp.html
>
>
> ---------------------------------------------------------------------
> 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: [VOTE] Release Compress 1.10 Based on RC1
Posted by Stefan Bodewig <bo...@apache.org>.
On 2015-01-30, Gary Gregory wrote:
> On Fri, Jan 30, 2015 at 6:06 AM, Stefan Bodewig <bo...@apache.org> wrote:
>> The superclass of ZCompressorInputStream has changed from one we've
>> removed with the old __internal__ package to a new one in the now
>> supported lzw package.
> Well, we cannot break BC in a minor release for a public class. Are
> we sure BC breaks?
Well, not as much as my intuition had told me:
public static void main(String[] args) throws Exception {
try (InputStream in = new FileInputStream(args[0]);
OutputStream out = new FileOutputStream(args[1]);
ZCompressorInputStream zin = new ZCompressorInputStream(in) {
@Override
public void close() throws IOException {
System.err.println("closing with code size " + codeSize);
setClearCode(12);
super.close();
}
}) {
IOUtils.copy(zin, out);
}
}
accesses a protected field and a protected method of
InternalLZWInputStream when compiled against 1.9, a class that is no
longer there in 1.10. When run against trunk (without recompiling) it
still works. This is in line with something I once read up in the JLS
(oh my, nine years ago, time flies)[1]. The compiler says "call the
protected setClearCode method taking an int arg" and at runtime it
starts searching for that method with the most derived class. So
changing superclasses doesn't seem to affect things.
Of course we will break someting like
InternalLZWInputStream s = new ZCompressorInputStream(in)
but then again you'd have used a class that we had explicitly marked as
internal.
Unless anybody comes up with a case where the change in superclass
causes a problem, I'd say we are fine.
Stefan
[1] http://stefan.samaflost.de/blog/en/dotNet/difference_between_java_and_csharp.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Compress 1.10 Based on RC1
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Jan 30, 2015 at 6:06 AM, Stefan Bodewig <bo...@apache.org> wrote:
> On 2015-01-30, sebb wrote:
>
> > On 30 January 2015 at 08:20, Stefan Bodewig <bo...@apache.org> wrote:
> >> On 2015-01-28, Benedikt Ritter wrote:
>
> >>> - PROPOSAL.txt is not in the src archives. Should it be?
>
> >> This is only there for historical reasons, I don't even think the other
> >> components still have a file like this. I've removed it completely.
>
> >>> - there is a typo in the release notes. The first line says "Apache
> >>> Apache Commons Compress"
>
> >> fixed, thanks.
>
> >>> - will clients who extended ZCompressorInputStream be affected by the
> >>> change in it's superclass hierarchy? In other words, is the change to
> >>> ZCompressorInputStream reported by clirr binary compatible with 1.9?
>
> >>> The last one would be a blocker for me. It could be resolved by
> restoring
> >>> the _internal_ package and deprecate it right away.
>
> >> It is reported as not compatible, so yes, we are breaking backwards
> >> compatibility.
>
> > Note that Clirr does not distinguish binary and source compatibility.
> > Breaking binary compatibility is almost never a good idea.
> > However source compatibility may be less important in some cases.
>
> > Which incompatibility is it?
>
> The superclass of ZCompressorInputStream has changed from one we've
> removed with the old __internal__ package to a new one in the now
> supported lzw package.
>
Well, we cannot break BC in a minor release for a public class. Are we
sure BC breaks?
If we want to make this internal package public, it needs to be copied to
the new location, not moved. Then ZCompressorInputStream would still extend
the internal package.
Gary
>
> 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: [VOTE] Release Compress 1.10 Based on RC1
Posted by Stefan Bodewig <bo...@apache.org>.
On 2015-01-30, sebb wrote:
> On 30 January 2015 at 08:20, Stefan Bodewig <bo...@apache.org> wrote:
>> On 2015-01-28, Benedikt Ritter wrote:
>>> - PROPOSAL.txt is not in the src archives. Should it be?
>> This is only there for historical reasons, I don't even think the other
>> components still have a file like this. I've removed it completely.
>>> - there is a typo in the release notes. The first line says "Apache
>>> Apache Commons Compress"
>> fixed, thanks.
>>> - will clients who extended ZCompressorInputStream be affected by the
>>> change in it's superclass hierarchy? In other words, is the change to
>>> ZCompressorInputStream reported by clirr binary compatible with 1.9?
>>> The last one would be a blocker for me. It could be resolved by restoring
>>> the _internal_ package and deprecate it right away.
>> It is reported as not compatible, so yes, we are breaking backwards
>> compatibility.
> Note that Clirr does not distinguish binary and source compatibility.
> Breaking binary compatibility is almost never a good idea.
> However source compatibility may be less important in some cases.
> Which incompatibility is it?
The superclass of ZCompressorInputStream has changed from one we've
removed with the old __internal__ package to a new one in the now
supported lzw package.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Compress 1.10 Based on RC1
Posted by sebb <se...@gmail.com>.
On 30 January 2015 at 08:20, Stefan Bodewig <bo...@apache.org> wrote:
> On 2015-01-28, Benedikt Ritter wrote:
>
>> - PROPOSAL.txt is not in the src archives. Should it be?
>
> This is only there for historical reasons, I don't even think the other
> components still have a file like this. I've removed it completely.
>
>> - there is a typo in the release notes. The first line says "Apache
>> Apache Commons Compress"
>
> fixed, thanks.
>
>> - will clients who extended ZCompressorInputStream be affected by the
>> change in it's superclass hierarchy? In other words, is the change to
>> ZCompressorInputStream reported by clirr binary compatible with 1.9?
>>
>> The last one would be a blocker for me. It could be resolved by restoring
>> the _internal_ package and deprecate it right away.
>
> It is reported as not compatible, so yes, we are breaking backwards
> compatibility.
Note that Clirr does not distinguish binary and source compatibility.
Breaking binary compatibility is almost never a good idea.
However source compatibility may be less important in some cases.
Which incompatibility is it?
> Reinstating the package won't help since then we'd also
> have to make ZCompressorInputStream extend InternalLZWInputStream again,
> which we do not want to do. Even deprecating the package wouldn't help
> as removing the package later would again be a binary breaking change.
>
> I'll use stronger words in the warning about backwards incompatible
> changes.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Compress 1.10 Based on RC1
Posted by Stefan Bodewig <bo...@apache.org>.
On 2015-01-28, Benedikt Ritter wrote:
> - PROPOSAL.txt is not in the src archives. Should it be?
This is only there for historical reasons, I don't even think the other
components still have a file like this. I've removed it completely.
> - there is a typo in the release notes. The first line says "Apache
> Apache Commons Compress"
fixed, thanks.
> - will clients who extended ZCompressorInputStream be affected by the
> change in it's superclass hierarchy? In other words, is the change to
> ZCompressorInputStream reported by clirr binary compatible with 1.9?
>
> The last one would be a blocker for me. It could be resolved by restoring
> the _internal_ package and deprecate it right away.
It is reported as not compatible, so yes, we are breaking backwards
compatibility. Reinstating the package won't help since then we'd also
have to make ZCompressorInputStream extend InternalLZWInputStream again,
which we do not want to do. Even deprecating the package wouldn't help
as removing the package later would again be a binary breaking change.
I'll use stronger words in the warning about backwards incompatible
changes.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Compress 1.10 Based on RC1
Posted by Kristian Rosenvold <kr...@gmail.com>.
2015-01-28 19:30 GMT+01:00 Benedikt Ritter <br...@apache.org>:
> Hello Stefan,
>
> - I've build this RC with Maven 3.2.5 and Java 6, 7, 8 and 9 EA. Java 6, 7
> and 8 work fine (although the site can not be build with Java 8 due to
> doclint). Java 9 fails, because it does not support target option 1.5.
I just fixed the site for jdk8 (again). There'd almost have to be a CI
JDK8 site build if the project is to live with doclint enabled.
Or, of course, just disable the stuff.
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Compress 1.10 Based on RC1
Posted by Benedikt Ritter <br...@apache.org>.
Hello Stefan,
- I've build this RC with Maven 3.2.5 and Java 6, 7, 8 and 9 EA. Java 6, 7
and 8 work fine (although the site can not be build with Java 8 due to
doclint). Java 9 fails, because it does not support target option 1.5.
- Signs and hashes look good.
- Site looks good
Here are a few things I've observed:
- PROPOSAL.txt is not in the src archives. Should it be?
- there is a typo in the release notes. The first line says "Apache Apache
Commons Compress"
- will clients who extended ZCompressorInputStream be affected by the
change in it's superclass hierarchy? In other words, is the change to
ZCompressorInputStream reported by clirr binary compatible with 1.9?
The last one would be a blocker for me. It could be resolved by restoring
the _internal_ package and deprecate it right away.
regards,
Benedikt
2015-01-26 7:05 GMT+01:00 Stefan Bodewig <bo...@apache.org>:
> As inidcated last week, here is the first RC for Compress 1.10.
>
> Compress 1.10 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/compress/
> (svn revision 7828)
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1080/org/apache/commons/commons-compress/1.10/
>
> Details of changes since 1.9 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/compress/RELEASE-NOTES.txt
>
> http://people.apache.org/~bodewig/compress-1.10-RC1/changes-report.html
>
> The tag is here:
>
> http://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.10-RC1
> (svn revision 1654723)
>
> Site:
> http://people.apache.org/~bodewig/compress-1.10-RC1/
>
> Clirr Report (compared to 1.9):
> http://people.apache.org/~bodewig/compress-1.10-RC1/clirr-report.html
>
> RAT Report:
> http://people.apache.org/~bodewig/compress-1.10-RC1/rat-report.html
>
> KEYS:
> https://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now, i.e. after
> 0600 GMT 29-January 2015
>
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
>
> Thanks!
>
> 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