Re: [CANCEL][VOTE] Release Commons Fileupload 1.3.3 based on RC5

[Rob Tompkins]

> On Jun 7, 2017, at 8:31 PM, Gary Gregory  wrote:
> 
>> On Wed, Jun 7, 2017 at 5:30 PM, Gary Gregory  wrote:
>> 
>> 
>> 
>>> On Wed, Jun 7, 2017 at 5:27 PM, Rob Tompkins  wrote:
>>> 
>>> 
>>> 
 On Jun 7, 2017, at 8:20 PM, Gary Gregory 
>>> wrote:
 
 The ASC does not seem to have a public key.:
 
 gpg --verify commons-fileupload-1.3.3-source-release.zip.asc
 gpg: assuming signed data in 'commons-fileupload-1.3.3-sour
>>> ce-release.zip'
 gpg: Signature made 12/04/16 05:15:02 Pacific Standard Time using DSA
>>> key
 ID 7188601C
 *gpg: Can't check signature: No public key*
 
 
>>> 
>>> Curious. I'll re-roll.
>>> 
>> 
> I wonder if this VOTE should be canceled or if properly signing the files
> can be done "in-line" to this VOTE?

Indeed I was wondering if I re-built from the tag if that would warrant an RC6. 

> 
> Gary
> 
> 
>> Just FYI, I re-imported http://www.apache.org/dist/commons/KEYS. Just in
>> case. Didn't help.
>> 
>> Gary
>> 
>> 
>>> 
 Also, the file naming should be consistent,
 https://dist.apache.org/repos/dist/dev/commons/fileupload/source/ has
>>> both
 "source-release" and "src". Not sure how you can end up with the
 differences beyond just the file extension.
 
 Gary
 
 
> On Tue, Jun 6, 2017 at 11:20 AM, Rob Tompkins 
>>> wrote:
> 
> Hello all,
> 
> This is a [VOTE] for releasing Apache Commons Fileupload 1.3.3 (from
>>> RC5).
> 
> Tag name:
>  commons-fileupload-1.3.3-RC5 (signature can be checked from git using
> 'git tag -v')
> 
> Tag URL:
>  https://git-wip-us.apache.org/repos/asf?p=commons-
> fileupload.git;a=commit;h=dd2238b1671644cfead0e87c24a8ac61b4039084
> 
> Commit ID the tag points at:
>  dd2238b1671644cfead0e87c24a8ac61b4039084
> 
> Site:
>  http://home.apache.org/~chtompki/commons-fileupload-1.3.3-RC5
> 
> Distribution files (committed at revision 19901):
>  https://dist.apache.org/repos/dist/dev/commons/fileupload/
> 
> Distribution files hashes (SHA1):
>  commons-fileupload-1.3.3-bin.tar.gz
>  (SHA1: 2f4a9672168641ff726974a3b7cc68b97d1212fa)
>  commons-fileupload-1.3.3-bin.zip
>  (SHA1: b66e2c434ddbda90dfc9e92af4775d9777524bfa)
>  commons-fileupload-1.3.3-src.tar.gz
>  (SHA1: 71294a7d737a8ced04934c222ae6dfb16e4d8d73)
>  commons-fileupload-1.3.3-src.zip
>  (SHA1: 661172a2f62b460c4b754b7a0f04d412afabde52)
> 
> These are the Maven artifacts and their hashes:
>  commons-fileupload-1.3.3-javadoc.jar
>  (SHA1: 92d2fc371379d64a822150ca3882157564dd3f99)
>  commons-fileupload-1.3.3-sources.jar
>  (SHA1: c8c7bcb851fb5af0b19e4ea845cf2fc03de6f673)
>  commons-fileupload-1.3.3-test-sources.jar
>  (SHA1: 5e0d8c621d38694e0f2960ab2899ee1d67f2b708)
>  commons-fileupload-1.3.3-tests.jar
>  (SHA1: 20510147958fc759582e6ede789ccf31d056b232)
>  commons-fileupload-1.3.3.jar
>  (SHA1: fd754c7518772453aea1d5ffc32cb5ce0ebc0e40)
>  commons-fileupload-1.3.3.pom
>  (SHA1: 97d781eafc190f4fee3abf11f9ec8076f5f7b58c)
> 
> KEYS file to check signatures:
>  http://www.apache.org/dist/commons/KEYS
> 
> Maven artifacts:
>  https://repository.apache.org/content/repositories/
> orgapachecommons-1249
> 
> Please select one of the following options[1]:
> [ ] +1 Release it.
> [ ] +0 Go ahead; I don't care.
> [ ] -0 There are a few minor glitches: ...
> [ ] -1 No, do not release it because ...
> 
> This vote will be open at least 72 hours, i.e. until
> 2017-06-09T19:00:00Z
> (this is UTC time).
> 
> 
> Cheers,
> -Rob
> 
> [1] http://apache.org/foundation/voting.html
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>> 
>>> 
>> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [CANCEL][VOTE] Release Commons Fileupload 1.3.3 based on RC5

[Gary Gregory]

On Wed, Jun 7, 2017 at 5:30 PM, Gary Gregory  wrote:

>
>
> On Wed, Jun 7, 2017 at 5:27 PM, Rob Tompkins  wrote:
>
>>
>>
>> > On Jun 7, 2017, at 8:20 PM, Gary Gregory 
>> wrote:
>> >
>> > The ASC does not seem to have a public key.:
>> >
>> > gpg --verify commons-fileupload-1.3.3-source-release.zip.asc
>> > gpg: assuming signed data in 'commons-fileupload-1.3.3-sour
>> ce-release.zip'
>> > gpg: Signature made 12/04/16 05:15:02 Pacific Standard Time using DSA
>> key
>> > ID 7188601C
>> > *gpg: Can't check signature: No public key*
>> >
>> >
>>
>> Curious. I'll re-roll.
>>
>
I wonder if this VOTE should be canceled or if properly signing the files
can be done "in-line" to this VOTE?

Gary


> Just FYI, I re-imported http://www.apache.org/dist/commons/KEYS. Just in
> case. Didn't help.
>
> Gary
>
>
>>
>> > Also, the file naming should be consistent,
>> > https://dist.apache.org/repos/dist/dev/commons/fileupload/source/ has
>> both
>> > "source-release" and "src". Not sure how you can end up with the
>> > differences beyond just the file extension.
>> >
>> > Gary
>> >
>> >
>> >> On Tue, Jun 6, 2017 at 11:20 AM, Rob Tompkins 
>> wrote:
>> >>
>> >> Hello all,
>> >>
>> >> This is a [VOTE] for releasing Apache Commons Fileupload 1.3.3 (from
>> RC5).
>> >>
>> >> Tag name:
>> >>   commons-fileupload-1.3.3-RC5 (signature can be checked from git using
>> >> 'git tag -v')
>> >>
>> >> Tag URL:
>> >>   https://git-wip-us.apache.org/repos/asf?p=commons-
>> >> fileupload.git;a=commit;h=dd2238b1671644cfead0e87c24a8ac61b4039084
>> >>
>> >> Commit ID the tag points at:
>> >>   dd2238b1671644cfead0e87c24a8ac61b4039084
>> >>
>> >> Site:
>> >>   http://home.apache.org/~chtompki/commons-fileupload-1.3.3-RC5
>> >>
>> >> Distribution files (committed at revision 19901):
>> >>   https://dist.apache.org/repos/dist/dev/commons/fileupload/
>> >>
>> >> Distribution files hashes (SHA1):
>> >>   commons-fileupload-1.3.3-bin.tar.gz
>> >>   (SHA1: 2f4a9672168641ff726974a3b7cc68b97d1212fa)
>> >>   commons-fileupload-1.3.3-bin.zip
>> >>   (SHA1: b66e2c434ddbda90dfc9e92af4775d9777524bfa)
>> >>   commons-fileupload-1.3.3-src.tar.gz
>> >>   (SHA1: 71294a7d737a8ced04934c222ae6dfb16e4d8d73)
>> >>   commons-fileupload-1.3.3-src.zip
>> >>   (SHA1: 661172a2f62b460c4b754b7a0f04d412afabde52)
>> >>
>> >> These are the Maven artifacts and their hashes:
>> >>   commons-fileupload-1.3.3-javadoc.jar
>> >>   (SHA1: 92d2fc371379d64a822150ca3882157564dd3f99)
>> >>   commons-fileupload-1.3.3-sources.jar
>> >>   (SHA1: c8c7bcb851fb5af0b19e4ea845cf2fc03de6f673)
>> >>   commons-fileupload-1.3.3-test-sources.jar
>> >>   (SHA1: 5e0d8c621d38694e0f2960ab2899ee1d67f2b708)
>> >>   commons-fileupload-1.3.3-tests.jar
>> >>   (SHA1: 20510147958fc759582e6ede789ccf31d056b232)
>> >>   commons-fileupload-1.3.3.jar
>> >>   (SHA1: fd754c7518772453aea1d5ffc32cb5ce0ebc0e40)
>> >>   commons-fileupload-1.3.3.pom
>> >>   (SHA1: 97d781eafc190f4fee3abf11f9ec8076f5f7b58c)
>> >>
>> >> KEYS file to check signatures:
>> >>   http://www.apache.org/dist/commons/KEYS
>> >>
>> >> Maven artifacts:
>> >>   https://repository.apache.org/content/repositories/
>> >> orgapachecommons-1249
>> >>
>> >> Please select one of the following options[1]:
>> >>  [ ] +1 Release it.
>> >>  [ ] +0 Go ahead; I don't care.
>> >>  [ ] -0 There are a few minor glitches: ...
>> >>  [ ] -1 No, do not release it because ...
>> >>
>> >> This vote will be open at least 72 hours, i.e. until
>> >> 2017-06-09T19:00:00Z
>> >> (this is UTC time).
>> >> 
>> >>
>> >> Cheers,
>> >> -Rob
>> >>
>> >> [1] http://apache.org/foundation/voting.html
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >> For additional commands, e-mail: dev-h...@commons.apache.org
>> >>
>> >>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>

Re: [CANCEL][VOTE] Release Commons Fileupload 1.3.3 based on RC5

[Gary Gregory]

On Wed, Jun 7, 2017 at 5:27 PM, Rob Tompkins  wrote:

>
>
> > On Jun 7, 2017, at 8:20 PM, Gary Gregory  wrote:
> >
> > The ASC does not seem to have a public key.:
> >
> > gpg --verify commons-fileupload-1.3.3-source-release.zip.asc
> > gpg: assuming signed data in 'commons-fileupload-1.3.3-
> source-release.zip'
> > gpg: Signature made 12/04/16 05:15:02 Pacific Standard Time using DSA key
> > ID 7188601C
> > *gpg: Can't check signature: No public key*
> >
> >
>
> Curious. I'll re-roll.
>

Just FYI, I re-imported http://www.apache.org/dist/commons/KEYS. Just in
case. Didn't help.

Gary


>
> > Also, the file naming should be consistent,
> > https://dist.apache.org/repos/dist/dev/commons/fileupload/source/ has
> both
> > "source-release" and "src". Not sure how you can end up with the
> > differences beyond just the file extension.
> >
> > Gary
> >
> >
> >> On Tue, Jun 6, 2017 at 11:20 AM, Rob Tompkins 
> wrote:
> >>
> >> Hello all,
> >>
> >> This is a [VOTE] for releasing Apache Commons Fileupload 1.3.3 (from
> RC5).
> >>
> >> Tag name:
> >>   commons-fileupload-1.3.3-RC5 (signature can be checked from git using
> >> 'git tag -v')
> >>
> >> Tag URL:
> >>   https://git-wip-us.apache.org/repos/asf?p=commons-
> >> fileupload.git;a=commit;h=dd2238b1671644cfead0e87c24a8ac61b4039084
> >>
> >> Commit ID the tag points at:
> >>   dd2238b1671644cfead0e87c24a8ac61b4039084
> >>
> >> Site:
> >>   http://home.apache.org/~chtompki/commons-fileupload-1.3.3-RC5
> >>
> >> Distribution files (committed at revision 19901):
> >>   https://dist.apache.org/repos/dist/dev/commons/fileupload/
> >>
> >> Distribution files hashes (SHA1):
> >>   commons-fileupload-1.3.3-bin.tar.gz
> >>   (SHA1: 2f4a9672168641ff726974a3b7cc68b97d1212fa)
> >>   commons-fileupload-1.3.3-bin.zip
> >>   (SHA1: b66e2c434ddbda90dfc9e92af4775d9777524bfa)
> >>   commons-fileupload-1.3.3-src.tar.gz
> >>   (SHA1: 71294a7d737a8ced04934c222ae6dfb16e4d8d73)
> >>   commons-fileupload-1.3.3-src.zip
> >>   (SHA1: 661172a2f62b460c4b754b7a0f04d412afabde52)
> >>
> >> These are the Maven artifacts and their hashes:
> >>   commons-fileupload-1.3.3-javadoc.jar
> >>   (SHA1: 92d2fc371379d64a822150ca3882157564dd3f99)
> >>   commons-fileupload-1.3.3-sources.jar
> >>   (SHA1: c8c7bcb851fb5af0b19e4ea845cf2fc03de6f673)
> >>   commons-fileupload-1.3.3-test-sources.jar
> >>   (SHA1: 5e0d8c621d38694e0f2960ab2899ee1d67f2b708)
> >>   commons-fileupload-1.3.3-tests.jar
> >>   (SHA1: 20510147958fc759582e6ede789ccf31d056b232)
> >>   commons-fileupload-1.3.3.jar
> >>   (SHA1: fd754c7518772453aea1d5ffc32cb5ce0ebc0e40)
> >>   commons-fileupload-1.3.3.pom
> >>   (SHA1: 97d781eafc190f4fee3abf11f9ec8076f5f7b58c)
> >>
> >> KEYS file to check signatures:
> >>   http://www.apache.org/dist/commons/KEYS
> >>
> >> Maven artifacts:
> >>   https://repository.apache.org/content/repositories/
> >> orgapachecommons-1249
> >>
> >> Please select one of the following options[1]:
> >>  [ ] +1 Release it.
> >>  [ ] +0 Go ahead; I don't care.
> >>  [ ] -0 There are a few minor glitches: ...
> >>  [ ] -1 No, do not release it because ...
> >>
> >> This vote will be open at least 72 hours, i.e. until
> >> 2017-06-09T19:00:00Z
> >> (this is UTC time).
> >> 
> >>
> >> Cheers,
> >> -Rob
> >>
> >> [1] http://apache.org/foundation/voting.html
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[CANCEL][VOTE] Release Commons Fileupload 1.3.3 based on RC5

[Rob Tompkins]

> On Jun 7, 2017, at 8:20 PM, Gary Gregory  wrote:
> 
> The ASC does not seem to have a public key.:
> 
> gpg --verify commons-fileupload-1.3.3-source-release.zip.asc
> gpg: assuming signed data in 'commons-fileupload-1.3.3-source-release.zip'
> gpg: Signature made 12/04/16 05:15:02 Pacific Standard Time using DSA key
> ID 7188601C
> *gpg: Can't check signature: No public key*
> 
> 

Curious. I'll re-roll.


> Also, the file naming should be consistent,
> https://dist.apache.org/repos/dist/dev/commons/fileupload/source/ has both
> "source-release" and "src". Not sure how you can end up with the
> differences beyond just the file extension.
> 
> Gary
> 
> 
>> On Tue, Jun 6, 2017 at 11:20 AM, Rob Tompkins  wrote:
>> 
>> Hello all,
>> 
>> This is a [VOTE] for releasing Apache Commons Fileupload 1.3.3 (from RC5).
>> 
>> Tag name:
>>   commons-fileupload-1.3.3-RC5 (signature can be checked from git using
>> 'git tag -v')
>> 
>> Tag URL:
>>   https://git-wip-us.apache.org/repos/asf?p=commons-
>> fileupload.git;a=commit;h=dd2238b1671644cfead0e87c24a8ac61b4039084
>> 
>> Commit ID the tag points at:
>>   dd2238b1671644cfead0e87c24a8ac61b4039084
>> 
>> Site:
>>   http://home.apache.org/~chtompki/commons-fileupload-1.3.3-RC5
>> 
>> Distribution files (committed at revision 19901):
>>   https://dist.apache.org/repos/dist/dev/commons/fileupload/
>> 
>> Distribution files hashes (SHA1):
>>   commons-fileupload-1.3.3-bin.tar.gz
>>   (SHA1: 2f4a9672168641ff726974a3b7cc68b97d1212fa)
>>   commons-fileupload-1.3.3-bin.zip
>>   (SHA1: b66e2c434ddbda90dfc9e92af4775d9777524bfa)
>>   commons-fileupload-1.3.3-src.tar.gz
>>   (SHA1: 71294a7d737a8ced04934c222ae6dfb16e4d8d73)
>>   commons-fileupload-1.3.3-src.zip
>>   (SHA1: 661172a2f62b460c4b754b7a0f04d412afabde52)
>> 
>> These are the Maven artifacts and their hashes:
>>   commons-fileupload-1.3.3-javadoc.jar
>>   (SHA1: 92d2fc371379d64a822150ca3882157564dd3f99)
>>   commons-fileupload-1.3.3-sources.jar
>>   (SHA1: c8c7bcb851fb5af0b19e4ea845cf2fc03de6f673)
>>   commons-fileupload-1.3.3-test-sources.jar
>>   (SHA1: 5e0d8c621d38694e0f2960ab2899ee1d67f2b708)
>>   commons-fileupload-1.3.3-tests.jar
>>   (SHA1: 20510147958fc759582e6ede789ccf31d056b232)
>>   commons-fileupload-1.3.3.jar
>>   (SHA1: fd754c7518772453aea1d5ffc32cb5ce0ebc0e40)
>>   commons-fileupload-1.3.3.pom
>>   (SHA1: 97d781eafc190f4fee3abf11f9ec8076f5f7b58c)
>> 
>> KEYS file to check signatures:
>>   http://www.apache.org/dist/commons/KEYS
>> 
>> Maven artifacts:
>>   https://repository.apache.org/content/repositories/
>> orgapachecommons-1249
>> 
>> Please select one of the following options[1]:
>>  [ ] +1 Release it.
>>  [ ] +0 Go ahead; I don't care.
>>  [ ] -0 There are a few minor glitches: ...
>>  [ ] -1 No, do not release it because ...
>> 
>> This vote will be open at least 72 hours, i.e. until
>> 2017-06-09T19:00:00Z
>> (this is UTC time).
>> 
>> 
>> Cheers,
>> -Rob
>> 
>> [1] http://apache.org/foundation/voting.html
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Commons Fileupload 1.3.3 based on RC5

[Gary Gregory]

The ASC does not seem to have a public key.:

gpg --verify commons-fileupload-1.3.3-source-release.zip.asc
gpg: assuming signed data in 'commons-fileupload-1.3.3-source-release.zip'
gpg: Signature made 12/04/16 05:15:02 Pacific Standard Time using DSA key
ID 7188601C
*gpg: Can't check signature: No public key*


Also, the file naming should be consistent,
https://dist.apache.org/repos/dist/dev/commons/fileupload/source/ has both
"source-release" and "src". Not sure how you can end up with the
differences beyond just the file extension.

Gary


On Tue, Jun 6, 2017 at 11:20 AM, Rob Tompkins  wrote:

> Hello all,
>
> This is a [VOTE] for releasing Apache Commons Fileupload 1.3.3 (from RC5).
>
> Tag name:
>commons-fileupload-1.3.3-RC5 (signature can be checked from git using
> 'git tag -v')
>
> Tag URL:
>https://git-wip-us.apache.org/repos/asf?p=commons-
> fileupload.git;a=commit;h=dd2238b1671644cfead0e87c24a8ac61b4039084
>
> Commit ID the tag points at:
>dd2238b1671644cfead0e87c24a8ac61b4039084
>
> Site:
>http://home.apache.org/~chtompki/commons-fileupload-1.3.3-RC5
>
> Distribution files (committed at revision 19901):
>https://dist.apache.org/repos/dist/dev/commons/fileupload/
>
> Distribution files hashes (SHA1):
>commons-fileupload-1.3.3-bin.tar.gz
>(SHA1: 2f4a9672168641ff726974a3b7cc68b97d1212fa)
>commons-fileupload-1.3.3-bin.zip
>(SHA1: b66e2c434ddbda90dfc9e92af4775d9777524bfa)
>commons-fileupload-1.3.3-src.tar.gz
>(SHA1: 71294a7d737a8ced04934c222ae6dfb16e4d8d73)
>commons-fileupload-1.3.3-src.zip
>(SHA1: 661172a2f62b460c4b754b7a0f04d412afabde52)
>
> These are the Maven artifacts and their hashes:
>commons-fileupload-1.3.3-javadoc.jar
>(SHA1: 92d2fc371379d64a822150ca3882157564dd3f99)
>commons-fileupload-1.3.3-sources.jar
>(SHA1: c8c7bcb851fb5af0b19e4ea845cf2fc03de6f673)
>commons-fileupload-1.3.3-test-sources.jar
>(SHA1: 5e0d8c621d38694e0f2960ab2899ee1d67f2b708)
>commons-fileupload-1.3.3-tests.jar
>(SHA1: 20510147958fc759582e6ede789ccf31d056b232)
>commons-fileupload-1.3.3.jar
>(SHA1: fd754c7518772453aea1d5ffc32cb5ce0ebc0e40)
>commons-fileupload-1.3.3.pom
>(SHA1: 97d781eafc190f4fee3abf11f9ec8076f5f7b58c)
>
> KEYS file to check signatures:
>http://www.apache.org/dist/commons/KEYS
>
> Maven artifacts:
>https://repository.apache.org/content/repositories/
> orgapachecommons-1249
>
> Please select one of the following options[1]:
>   [ ] +1 Release it.
>   [ ] +0 Go ahead; I don't care.
>   [ ] -0 There are a few minor glitches: ...
>   [ ] -1 No, do not release it because ...
>
> This vote will be open at least 72 hours, i.e. until
> 2017-06-09T19:00:00Z
> (this is UTC time).
> 
>
> Cheers,
> -Rob
>
> [1] http://apache.org/foundation/voting.html
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: OSGI Version at Package Level : some more details about the COMPRESS-399 pull request

[Gary Gregory]

On Wed, Jun 7, 2017 at 10:28 AM, Simon Spero  wrote:

> As Bertrand mentioned earlier, the bundle:baseline goal  is built in to the
> maven-bundle-plugin already in use!
>
> The pull-request adds that goal to the verify phase of the maven build (and
> changes the travis config to run 'mvn verify'  instead of 'mvn test' ). The
> baseline goal is set to fail the build if the versioning contains errors.
>

We should run mvn verify anyway to pick up any other checks like
integration tests.

Gary


>
> It takes very little work to bump the package version numbers when an API
> change is made.  The first time you change a package in a way that requires
> a new version number, the build will simply break in the verify phase, with
> a list of changes, and a suggested new version number.
>
> Any further API changes to the package at the same level or below will pass
> the verify stage without a problem. For example, if you have already bumped
> the package by a minor version, any further minor changes won't require any
> more changes.
>
> However, a subsequent major (breaking) changes will fail when verifying.
> The author of the change can then consider whether the breaking change is
> the best way forward, or whether their goals can be achieved in different
> way.Studies have shown that there is considerable confusion about what is
> and isn't a binary compatible change in java (for example, changing the
> return type of a method from Collection to List is a
> binary-incompatible change (but is source-compatible).  Breaking changes
> need careful consideration.
>
> In principle, the major and minor components of the bundle & artifact
> version should be bumped to match the most significant change in any
> package in the bundle/artifact, so that maven version-range dependencies
> don't break, but that ship has sunk.
>
> Simon
> p.s.
> The reason I'd been making changes to commons-compress was to support
> creating and using random access tar.xz files in order to store release
> series of  bundles from maven-central to investigate this issue (and see
> how many problems can be fixed statically, and how many by dynamic
> rewriting and/or fibbing.
> p.p.s.
> Compressing series of maven artifact is quite interesting ;
>  for example, the ten releases of common-math3 (to 3.6) contain 40.9 MiB
>  of uncompressed contents:
>
> 17.8 MiB as jars.
>   6.4 MiB when the jars are packed in version order in .tar.xz format,
>   4.4 MiB if the jars are run through pack200 and xz'ed individually.
>   1.6 MiB if the compressed entries of the jar files are reflated first.
>   1.5 MiB if run through pack200 then tar.xz
>

[NUMBERS] : findbug failing in commons-number-core

[Amey Jadiye]

Hi,

I was trying to run all checks on commons-number and found findbug is
failing in Precision.java[544] FE_FLOATING_POINT_EQUALITY

{code}
case BigDecimal.ROUND_HALF_EVEN : {
double fraction = unscaled - Math.floor(unscaled);
if (fraction > 0.5) {
unscaled = Math.ceil(unscaled);
} else if (fraction < 0.5) {
unscaled = Math.floor(unscaled);
} else {
// The following equality test is intentional and needed
for rounding purposes
if (Math.floor(unscaled) / 2.0 ==
Math.floor(Math.floor(unscaled) / 2.0)) { // even // failing here.
//
unscaled = Math.floor(unscaled);
} else { // odd
unscaled = Math.ceil(unscaled);
}
}
break;
}
{code}

Error is :
Test for floating point equality in
org.apache.commons.numbers.core.Precision.roundUnscaled(double, double,
int) [Of Concern(15), High confidence]

Fix:
Replace equality check with below:
if (Math.abs((Math.floor(unscaled) / 2.0) -
(Math.floor(Math.floor(unscaled) / 2.0))) < .001)

we have couple of similar issues in code.
Let me know if we have better alternative, else will submit code.

Regards,
Amey

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

OSGI Version at Package Level : some more details about the COMPRESS-399 pull request

[Simon Spero]

As Bertrand mentioned earlier, the bundle:baseline goal  is built in to the
maven-bundle-plugin already in use!

The pull-request adds that goal to the verify phase of the maven build (and
changes the travis config to run 'mvn verify'  instead of 'mvn test' ). The
baseline goal is set to fail the build if the versioning contains errors.

It takes very little work to bump the package version numbers when an API
change is made.  The first time you change a package in a way that requires
a new version number, the build will simply break in the verify phase, with
a list of changes, and a suggested new version number.

Any further API changes to the package at the same level or below will pass
the verify stage without a problem. For example, if you have already bumped
the package by a minor version, any further minor changes won't require any
more changes.

However, a subsequent major (breaking) changes will fail when verifying.
The author of the change can then consider whether the breaking change is
the best way forward, or whether their goals can be achieved in different
way.Studies have shown that there is considerable confusion about what is
and isn't a binary compatible change in java (for example, changing the
return type of a method from Collection to List is a
binary-incompatible change (but is source-compatible).  Breaking changes
need careful consideration.

In principle, the major and minor components of the bundle & artifact
version should be bumped to match the most significant change in any
package in the bundle/artifact, so that maven version-range dependencies
don't break, but that ship has sunk.

Simon
p.s.
The reason I'd been making changes to commons-compress was to support
creating and using random access tar.xz files in order to store release
series of  bundles from maven-central to investigate this issue (and see
how many problems can be fixed statically, and how many by dynamic
rewriting and/or fibbing.
p.p.s.
Compressing series of maven artifact is quite interesting ;
 for example, the ten releases of common-math3 (to 3.6) contain 40.9 MiB
 of uncompressed contents:

17.8 MiB as jars.
  6.4 MiB when the jars are packed in version order in .tar.xz format,
  4.4 MiB if the jars are run through pack200 and xz'ed individually.
  1.6 MiB if the compressed entries of the jar files are reflated first.
  1.5 MiB if run through pack200 then tar.xz

[GitHub] commons-text issue #44: [TEXT-80]: Fixed confusing StrLookup API

[ameyjadiye]

Github user ameyjadiye commented on the issue:

https://github.com/apache/commons-text/pull/44
  
Hi @chtompki , since commons-text is relatively new there are very [low 
usage](https://mvnrepository.com/artifact/org.apache.commons/commons-text), 
```clirr:check``` is also passed whoever is using it and wants to bump version 
needs minor change in their code, but its ok we can park it till 2.X release.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [NUMBERS] Proposal for refactoring and extension of Gamma functions.

[Gilles]

Hello.

On Wed, 07 Jun 2017 12:53:42 +, Amey Jadiye wrote:

Hi Gilles,

Thanks for inputs, I will generate some stats with jmh let's see if 
we are

getting benefits with my proposal.

Mean time I have submitted test cases[1] for NUMBERS-38, please 
review.


Tabs is a "no-no". ;-)

I find it quite unusual to test equality of numbers by first
converting them to (truncated) strings.

Finally, I think that it is not that helpful to have the _same_
code as the one being checked, duplicated in the unit test class.
[I mean, it is obvious that they will give the same answer...]
It is more robust to run a code externally, and copy/paste the
results as an array of "reference values" to be checked against.
[See e.g. in class "GammaTest".]

But don't rush into making another pass at it before we decide
whether it is necessary at all to have more unit tests: If the
code is somehow covered adequately by the other tests, we might
just resolve the issue as "Not a problem" (and a comment in the
test class).

IMO, it would be more useful to figure out whether this bit of
code should be renamed: it would be wrong to have a class called
"LanczosApproximation" in the public API if what it does is not
what would one expect from such a class.
And consequently, also, we need (before the first release) to
figure out whether it is possible to make it "internal", and fix
"GammaDistribution" accordingly.


Best,
Gilles



[1] https://github.com/apache/commons-numbers/pull/5

Regards,
Amey

On Wed, Jun 7, 2017, 4:44 AM Gilles  
wrote:



Hi Amey.

On Wed, 7 Jun 2017 01:15:01 +0530, Amey Jadiye wrote:
> Hi,
>
> Gamma class is written keeping in mind that it should handle fair
> situation
> (if n < 20) it computes with normal gamma function else it uses
> LanczosApproximation
> for higher numbers, for now I think we should keep it behaviour as 
it

> is
> and do just code segrigation, by segregation of there 
functionalities

> we
> are making it switchable so Gamma class by optional providing
> constructor
> args of Lanzoz, Stinling or Spouge's algo, same thing we have to 
do

> in
> Math's Gamma distribution.
>
> Ex.
> Gamma g = Gamma(Algo.LANCZOS));

Just from the look of it, it is difficult to figure out whether
alternative algorithms are useful when numbers are represented
as 64-bits "double".

If you are willing to go that route, you should provide code that
shows the advantages (speed and/or precision).

Now, if we want to support an arbirary precision number type[1],
then the alternate algorithms that can provide accuracy below
~1e-16 would certainly be worth considering.[2]

> I'd like other people from group chime in discussion.


Regards,
Gilles

[1] See the "Dfp" class in CM's "o.a.c.math4.dfp" package.
[2] But IMO this should be postponed to after 1.0 since there
 is perhaps a need of a general discussion about designing
 high-precision algorithms (and whether there are volunteers
 to develop and support them in the long term).
 I may be wrong, but somehow I have the intuition that people
 requiring those functionalities might not be using Java...

>
> Regards,
> Amey
>
> On Tue, Jun 6, 2017 at 3:31 AM, Gilles 


> wrote:
>
>> On Tue, 6 Jun 2017 01:14:38 +0530, Amey Jadiye wrote:
>>
>>> Hi All,
>>>
>>> Coming from discussion happened here
>>> https://issues.apache.org/jira/browse/NUMBERS-38
>>>
>>> As Gamma is nothing but advanced factorial function 
gamma(n)=(n-1)!

>>> with
>>> advantages like we can have factorial of whole numbers as well 
as

>>> factional. Now as [Gamma functions (
>>> https://en.wikipedia.org/wiki/Gamma_function ) which is having
>>> general
>>> formula {{Gamma( x ) = integral( t^(x-1) e^(-t), t = 0 ..
>>> infinity)}} is a
>>> plane old base function however Lanczos approximation / 
Stirling's

>>> approximation /Spouge's Approximation  *is a* gamma function so
>>> they
>>> should
>>> be extend Gamma.
>>>
>>> Exact algorithm and formulas here :
>>>  - Lanczo's Approximation -
>>> https://en.wikipedia.org/wiki/Lanczos_approximation
>>>  - Stirling's Approximation  -
>>> https://en.wikipedia.org/wiki/Stirling%27s_approximation
>>>  - Spouge's Approximation -
>>> https://en.wikipedia.org/wiki/Spouge%27s_approximation
>>>
>>> Why to refactor code is because basic gamma function computes 
not

>>> so
>>> accurate/precision values so someone who need quick computation
>>> without
>>> precision can choose it, while someone who need precision overs
>>> cost of
>>> performance (Lanczos approximation is accurate so its slow takes
>>> more cpu
>>> cycle) can choose which algorithm they want.
>>>
>>> for some scientific application all values should be computed 
with

>>> great
>>> precision, with out Gamma class no choice is given for choosing
>>> which
>>> algorithm user want.
>>>
>>> I'm proposing to create something like:
>>>
>>> Gamma gammaFun = new Gamma(); gammaFun.value( x );
>>> Gamma gammaFun = new LanczosGamma(); 

Re: [LANG] Add Automatic-Module-Name MANIFEST entry

[Stefan Bodewig]

On 2017-06-07, Jörg Schaible wrote:

> Stefan Bodewig wrote:

>> On 2017-06-07, Benedikt Ritter wrote:

>>> here [1] is my proposal on how to add the Automatic-Module-Name entry
>>> to MANIFEST. This just duplicates the maven-jar-plugin configuration
>>> from parent pom. I don’t want to wait much longer to release
>>> 3.6. After we have implemented a more general solution in parent pom,
>>> we can revert this fix.

>> I've done something similar to Compress already. As Compress has been
>> overriding the jar-plugin configuration already (in order to add a
>> main-class) there's been no other option anyway.

>> I'm afraid Compress is not the only component that overrides the
>> parent's jar config and thus will require copying the change manually
>> even if you happen to find a solution for parent.

> You don't have to overwrite the jar's parent config. Simply append/overwrite
> the existing entries:

>   
> 
>   
> org.apache.commons.compress.archivers.Lister
>   
> 
>   

> That's it ;-)

I'm pretty sure we've tried that before. I'll give it another shot,
thanks.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-text issue #44: [TEXT-80]: Fixed confusing StrLookup API

[chtompki]

Github user chtompki commented on the issue:

https://github.com/apache/commons-text/pull/44
  
The change is generally all right with me, but we can't release this until 
a 2.X release though because of signature changes.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [LANG] Add Automatic-Module-Name MANIFEST entry

[Jörg Schaible]

Stefan Bodewig wrote:

> On 2017-06-07, Benedikt Ritter wrote:
> 
>> here [1] is my proposal on how to add the Automatic-Module-Name entry
>> to MANIFEST. This just duplicates the maven-jar-plugin configuration
>> from parent pom. I don’t want to wait much longer to release
>> 3.6. After we have implemented a more general solution in parent pom,
>> we can revert this fix.
> 
> I've done something similar to Compress already. As Compress has been
> overriding the jar-plugin configuration already (in order to add a
> main-class) there's been no other option anyway.
> 
> I'm afraid Compress is not the only component that overrides the
> parent's jar config and thus will require copying the change manually
> even if you happen to find a solution for parent.

You don't have to overwrite the jar's parent config. Simply append/overwrite 
the existing entries:

  

  
org.apache.commons.compress.archivers.Lister
  

  

That's it ;-)

Cheers,
Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [NUMBERS] Proposal for refactoring and extension of Gamma functions.

[Amey Jadiye]

Hi Gilles,

Thanks for inputs, I will generate some stats with jmh let's see if we are
getting benefits with my proposal.

Mean time I have submitted test cases[1] for NUMBERS-38, please review.

[1] https://github.com/apache/commons-numbers/pull/5

Regards,
Amey

On Wed, Jun 7, 2017, 4:44 AM Gilles  wrote:

> Hi Amey.
>
> On Wed, 7 Jun 2017 01:15:01 +0530, Amey Jadiye wrote:
> > Hi,
> >
> > Gamma class is written keeping in mind that it should handle fair
> > situation
> > (if n < 20) it computes with normal gamma function else it uses
> > LanczosApproximation
> > for higher numbers, for now I think we should keep it behaviour as it
> > is
> > and do just code segrigation, by segregation of there functionalities
> > we
> > are making it switchable so Gamma class by optional providing
> > constructor
> > args of Lanzoz, Stinling or Spouge's algo, same thing we have to do
> > in
> > Math's Gamma distribution.
> >
> > Ex.
> > Gamma g = Gamma(Algo.LANCZOS));
>
> Just from the look of it, it is difficult to figure out whether
> alternative algorithms are useful when numbers are represented
> as 64-bits "double".
>
> If you are willing to go that route, you should provide code that
> shows the advantages (speed and/or precision).
>
> Now, if we want to support an arbirary precision number type[1],
> then the alternate algorithms that can provide accuracy below
> ~1e-16 would certainly be worth considering.[2]
>
> > I'd like other people from group chime in discussion.
>
>
> Regards,
> Gilles
>
> [1] See the "Dfp" class in CM's "o.a.c.math4.dfp" package.
> [2] But IMO this should be postponed to after 1.0 since there
>  is perhaps a need of a general discussion about designing
>  high-precision algorithms (and whether there are volunteers
>  to develop and support them in the long term).
>  I may be wrong, but somehow I have the intuition that people
>  requiring those functionalities might not be using Java...
>
> >
> > Regards,
> > Amey
> >
> > On Tue, Jun 6, 2017 at 3:31 AM, Gilles 
> > wrote:
> >
> >> On Tue, 6 Jun 2017 01:14:38 +0530, Amey Jadiye wrote:
> >>
> >>> Hi All,
> >>>
> >>> Coming from discussion happened here
> >>> https://issues.apache.org/jira/browse/NUMBERS-38
> >>>
> >>> As Gamma is nothing but advanced factorial function gamma(n)=(n-1)!
> >>> with
> >>> advantages like we can have factorial of whole numbers as well as
> >>> factional. Now as [Gamma functions (
> >>> https://en.wikipedia.org/wiki/Gamma_function ) which is having
> >>> general
> >>> formula {{Gamma( x ) = integral( t^(x-1) e^(-t), t = 0 ..
> >>> infinity)}} is a
> >>> plane old base function however Lanczos approximation / Stirling's
> >>> approximation /Spouge's Approximation  *is a* gamma function so
> >>> they
> >>> should
> >>> be extend Gamma.
> >>>
> >>> Exact algorithm and formulas here :
> >>>  - Lanczo's Approximation -
> >>> https://en.wikipedia.org/wiki/Lanczos_approximation
> >>>  - Stirling's Approximation  -
> >>> https://en.wikipedia.org/wiki/Stirling%27s_approximation
> >>>  - Spouge's Approximation -
> >>> https://en.wikipedia.org/wiki/Spouge%27s_approximation
> >>>
> >>> Why to refactor code is because basic gamma function computes not
> >>> so
> >>> accurate/precision values so someone who need quick computation
> >>> without
> >>> precision can choose it, while someone who need precision overs
> >>> cost of
> >>> performance (Lanczos approximation is accurate so its slow takes
> >>> more cpu
> >>> cycle) can choose which algorithm they want.
> >>>
> >>> for some scientific application all values should be computed with
> >>> great
> >>> precision, with out Gamma class no choice is given for choosing
> >>> which
> >>> algorithm user want.
> >>>
> >>> I'm proposing to create something like:
> >>>
> >>> Gamma gammaFun = new Gamma(); gammaFun.value( x );
> >>> Gamma gammaFun = new LanczosGamma(); gammaFun.value( x );
> >>> Gamma gammaFun = new StirlingsGamma(); gammaFun.value( x );
> >>> Gamma gammaFun = new SpougesGamma(); gammaFun.value( x );
> >>>
> >>> Also as the class name suggestion {{LanczosApproximation}} it
> >>> should
> >>> execute/implement full *Lanczos Algoritham* but we are just
> >>> computing
> >>> coefficients in that class which is incorrect, so just refactoring
> >>> is
> >>> needed which wont break any dependency of this class anywhere.
> >>> (will
> >>> modify
> >>> code such way).
> >>>
> >>> let me know your thoughts?
> >>>
> >>>
> >> I've added a comment (about the multiple implementations) on the
> >> JIRA page.
> >>
> >> I agree that if the class currently named "LanczosApproximation" is
> >> not what the references define as "Lanczos' approximation", it
> >> should
> >> be renamed.
> >> My preference would be to "hide" it inside the "Gamma" class, if we
> >> can sort out how to modify the "GammaDistribution" class (in Commons
> >> Math) accordingly.
> >>
> >> Regards,
> >> Gilles
> >>
> >>
>
>
> 

Re: [VOTE] Release Commons Fileupload 1.3.3 based on RC5

[Rob Tompkins]

> On Jun 7, 2017, at 3:19 AM, Bruno P. Kinoshita 
>  wrote:
> 
> [ X ] +1 Release it.
> 
> All tests pass, artifacts generated successfully, and site correctly 
> generated too with `mvn clean test install -e -X` on the following 
> environments.
> 
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-11T05:41:47+13:00)
> Maven home: /opt/maven
> Java version: 1.8.0_131, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-oracle/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"
> 
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-11T05:41:47+13:00)
> Maven home: /opt/maven
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-7-oracle/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"
> 
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-11T05:41:47+13:00)
> Maven home: /opt/maven
> Java version: 1.8.0, vendor: IBM Corporation
> Java home: /home/kinow/Development/java/ibm-java-x86_64-80/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"
> 
> 
> Reports look OK. Noticed that coverage could be enhanced for future releases. 
> There are some classes with 0 tests (PortletFileUpload and 
> PortletRequestContext) so I'm adding a note in my todo list to write some 
> tests when I have some spare time (happy if anyone does so first :).
> 
> I think NOTICE.txt was not updated to include 2017 in the year (I believe we 
> manually update this file?), but that's trivial and definitely not a blocker 
> (I guess we just fix it later - if necessary).
> 
> My local web site has changes report showing 1.3.3 with date as tbd. Yours is 
> showing 1.4 with date set to today, but I guess it's temporary and after the 
> release it will display 1.3.3 and another date? Anyway, FILEUPLOAD-279 is not 
> there, but this shouldn't be a blocker.

I actually uploaded the site from the master branch because there were 
considerable differences between the RC and the master branch. I figured we 
would use the site from the master branch. I’ve just changed that for the sake 
of release validation.

-Rob

> 
> Didn't have much time so checked only the main jar gpg signature, and it's 
> also looking OK.
> 
> Go for it, and thanks for preparing the release!
> Cheers
> 
> Bruno
> 
> ps: first time I look at the DOAP file while reviewing a release... there are 
> some releases missing there, but I guess it's not updated automagically by 
> Maven... maybe those blocks could be removed?
> 
> From: Rob Tompkins 
> To: Commons Developers List  
> Sent: Wednesday, 7 June 2017 6:26 AM
> Subject: [VOTE] Release Commons Fileupload 1.3.3 based on RC5
> 
> 
> 
> Hello all,
> 
> 
> This is a [VOTE] for releasing Apache Commons Fileupload 1.3.3 (from RC5).
> 
> 
> Tag name:
> 
>   commons-fileupload-1.3.3-RC5 (signature can be checked from git using 'git 
> tag -v')
> 
> 
> Tag URL:
> 
>  
> https://git-wip-us.apache.org/repos/asf?p=commons-fileupload.git;a=commit;h=dd2238b1671644cfead0e87c24a8ac61b4039084
> 
> 
> Commit ID the tag points at:
> 
>   dd2238b1671644cfead0e87c24a8ac61b4039084
> 
> 
> Site:
> 
>  http://home.apache.org/~chtompki/commons-fileupload-1.3.3-RC5
> 
> 
> Distribution files (committed at revision 19901):
> 
>  https://dist.apache.org/repos/dist/dev/commons/fileupload/
> 
> 
> Distribution files hashes (SHA1):
> 
>   commons-fileupload-1.3.3-bin.tar.gz
> 
>   (SHA1: 2f4a9672168641ff726974a3b7cc68b97d1212fa)
> 
>   commons-fileupload-1.3.3-bin.zip
> 
>   (SHA1: b66e2c434ddbda90dfc9e92af4775d9777524bfa)
> 
>   commons-fileupload-1.3.3-src.tar.gz
> 
>   (SHA1: 71294a7d737a8ced04934c222ae6dfb16e4d8d73)
> 
>   commons-fileupload-1.3.3-src.zip
> 
>   (SHA1: 661172a2f62b460c4b754b7a0f04d412afabde52)
> 
> 
> These are the Maven artifacts and their hashes:
> 
>   commons-fileupload-1.3.3-javadoc.jar
> 
>   (SHA1: 92d2fc371379d64a822150ca3882157564dd3f99)
> 
>   commons-fileupload-1.3.3-sources.jar
> 
>   (SHA1: c8c7bcb851fb5af0b19e4ea845cf2fc03de6f673)
> 
>   commons-fileupload-1.3.3-test-sources.jar
> 
>   (SHA1: 5e0d8c621d38694e0f2960ab2899ee1d67f2b708)
> 
>   commons-fileupload-1.3.3-tests.jar
> 
>   (SHA1: 20510147958fc759582e6ede789ccf31d056b232)
> 
>   commons-fileupload-1.3.3.jar
> 
>   (SHA1: fd754c7518772453aea1d5ffc32cb5ce0ebc0e40)
> 
>   commons-fileupload-1.3.3.pom
> 
>   (SHA1: 97d781eafc190f4fee3abf11f9ec8076f5f7b58c)
> 
> 
> KEYS file to check signatures:
> 
>  http://www.apache.org/dist/commons/KEYS
> 
> 
> Maven artifacts:
> 
>  https://repository.apache.org/content/repositories/orgapachecommons-1249
> 
> 
> Please select one of the following options[1]:
> 
>  [ 

Re: [LANG] Add Automatic-Module-Name MANIFEST entry

[Stefan Bodewig]

On 2017-06-07, Benedikt Ritter wrote:

> here [1] is my proposal on how to add the Automatic-Module-Name entry
> to MANIFEST. This just duplicates the maven-jar-plugin configuration
> from parent pom. I don’t want to wait much longer to release
> 3.6. After we have implemented a more general solution in parent pom,
> we can revert this fix.

I've done something similar to Compress already. As Compress has been
overriding the jar-plugin configuration already (in order to add a
main-class) there's been no other option anyway.

I'm afraid Compress is not the only component that overrides the
parent's jar config and thus will require copying the change manually
even if you happen to find a solution for parent.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [LANG] Add Automatic-Module-Name MANIFEST entry

[Rob Tompkins]

> On Jun 7, 2017, at 4:25 AM, Benedikt Ritter  wrote:
> 
> Hi,
> 
> here [1] is my proposal on how to add the Automatic-Module-Name entry to 
> MANIFEST. This just duplicates the maven-jar-plugin configuration from parent 
> pom. I don’t want to wait much longer to release 3.6. After we have 
> implemented a more general solution in parent pom, we can revert this fix.

Regarding naming of the property used in the parent, I went with 
“commons.module.name” because all of the other properties seem to be period 
delimited and contain no dashes. That said, I’m ok with 
“commons.automatic-module-name” and am willing to go through and rename them 
all.

-Rob

> 
> If nobody objects, I’m going to merge this later this week and prepare RC3.
> 
> Cheers,
> Benedikt
> 
> [1] https://github.com/apache/commons-lang/pull/270
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [LANG] Add Automatic-Module-Name MANIFEST entry

[Stephen Colebourne]

This looks fine in terms of what it does. Obviously not ideal to have
the copying, but that is the right choice to make right now.
Stephen


On 7 June 2017 at 09:25, Benedikt Ritter  wrote:
> Hi,
>
> here [1] is my proposal on how to add the Automatic-Module-Name entry to 
> MANIFEST. This just duplicates the maven-jar-plugin configuration from parent 
> pom. I don’t want to wait much longer to release 3.6. After we have 
> implemented a more general solution in parent pom, we can revert this fix.
>
> If nobody objects, I’m going to merge this later this week and prepare RC3.
>
> Cheers,
> Benedikt
>
> [1] https://github.com/apache/commons-lang/pull/270
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: OSGi Version at Package Level

[Gilles]

On Wed, 7 Jun 2017 10:54:54 +0100, sebb wrote:
On 7 June 2017 at 09:02, Bertrand Delacretaz  
wrote:
On Wed, Jun 7, 2017 at 9:57 AM, Emmanuel Bourg  
wrote:

Le 7/06/2017 à 09:23, Bertrand Delacretaz a écrit :
... Implementing semantic versioning at the java package level as 
opposed

to bundle level.


That's the theory, I'm actually curious to see what real issue it 
solves

with commons-compress


I agree that what I explained is "the theory" which is very valid in
complex systems fully based on OSGi, avoiding problems if for 
example

an API package is provided by multiple bundles.

But maybe it doesn't make sense for commons-compress, I don't know
that code well enough to comment.


I doubt package-level versions make sense for (m)any Commons 
components.

AFAIK most components are only usable and released as a whole.


It would have made sense in a certain component that is so big that
many parts of it did not fundamentally change between two releases,
yet where bumped into a different top-level package because other
parts required an incompatible release.

For a single "real" component (small scope), it is not necessary,
almost by definition.

For a bunch of utilities, e.g. (maven) modules, that can evolve
independently or at different paces, it seems like a neat idea.
[As was explained by Stian some time ago (when I had proposed to
allow module versions, it is a political decision, not a technical
one.]


Regards,
Gilles



It might make sense for VFS I suppose, if that wants to release
implementations separately.


-Bertrand




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: OSGi Version at Package Level

[sebb]

On 7 June 2017 at 09:02, Bertrand Delacretaz  wrote:
> On Wed, Jun 7, 2017 at 9:57 AM, Emmanuel Bourg  wrote:
>> Le 7/06/2017 à 09:23, Bertrand Delacretaz a écrit :
>>>... Implementing semantic versioning at the java package level as opposed
>>> to bundle level.
>>
>> That's the theory, I'm actually curious to see what real issue it solves
>> with commons-compress
>
> I agree that what I explained is "the theory" which is very valid in
> complex systems fully based on OSGi, avoiding problems if for example
> an API package is provided by multiple bundles.
>
> But maybe it doesn't make sense for commons-compress, I don't know
> that code well enough to comment.

I doubt package-level versions make sense for (m)any Commons components.
AFAIK most components are only usable and released as a whole.

It might make sense for VFS I suppose, if that wants to release
implementations separately.

> -Bertrand
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[LANG] Add Automatic-Module-Name MANIFEST entry

[Benedikt Ritter]

Hi,

here [1] is my proposal on how to add the Automatic-Module-Name entry to 
MANIFEST. This just duplicates the maven-jar-plugin configuration from parent 
pom. I don’t want to wait much longer to release 3.6. After we have implemented 
a more general solution in parent pom, we can revert this fix.

If nobody objects, I’m going to merge this later this week and prepare RC3.

Cheers,
Benedikt

[1] https://github.com/apache/commons-lang/pull/270
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [lang] Java 9 module investigations

[Benedikt Ritter]

Hi,

> Am 23.05.2017 um 12:13 schrieb Emmanuel Bourg :
> 
> Le 23/05/2017 à 00:52, Stephen Colebourne a écrit :
> 
>> One final option is to declare an optional dependency on java.desktop,
>> such that the AbstractCircuitBreaker will fail to load unless the
>> end-user manually chooses to add java.desktop. I don't like it, but it
>> may be a compromise for compatibility.
> 
> Would it be possible to:
> 
> 1. deprecate add/removeChangeListener, keep only empty methods
> 2. remove the underlying PropertyChangeSupport
> 3. not declare a dependency on java.desktop, even optional
> 
> In this situation will Java 9 be able to load and use
> AbstractCircuitBreaker as long as the add/removeChangeListener methods
> are never used? Or will the runtime check the method signatures when
> loading the class?

I have created https://issues.apache.org/jira/browse/LANG-1339 
 for this. Let’s discuss 
possible solutions to the problem there.

Benedikt

> 
> Emmanuel Bourg
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

Re: OSGi Version at Package Level

[Bertrand Delacretaz]

On Wed, Jun 7, 2017 at 9:57 AM, Emmanuel Bourg  wrote:
> Le 7/06/2017 à 09:23, Bertrand Delacretaz a écrit :
>>... Implementing semantic versioning at the java package level as opposed
>> to bundle level.
>
> That's the theory, I'm actually curious to see what real issue it solves
> with commons-compress

I agree that what I explained is "the theory" which is very valid in
complex systems fully based on OSGi, avoiding problems if for example
an API package is provided by multiple bundles.

But maybe it doesn't make sense for commons-compress, I don't know
that code well enough to comment.

-Bertrand

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: OSGi Version at Package Level

[Emmanuel Bourg]

Le 7/06/2017 à 09:23, Bertrand Delacretaz a écrit :

> With the right tools as mentioned in my previous message it's quite easy.

Easier but not easy.


> Implementing semantic versioning at the java package level as opposed
> to bundle level.

That's the theory, I'm actually curious to see what real issue it solves
with commons-compress. What incompatibility in commons-compress caused
an issue with an OSGi application? And was there no other alternative to
solve this issue?

Emmanuel Bourg

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Commons Fileupload 1.3.3 based on RC5

[Bruno P. Kinoshita]

> Anyway, FILEUPLOAD-279 is not there, but this shouldn't be a blocker.


Just to be clear, it is not in 
http://home.apache.org/~chtompki/commons-fileupload-1.3.3-RC5/changes-report.html,
 but it's correctly displayed in my local generated site. So no issues I think.

Bruno



From: Bruno P. Kinoshita 
To: Commons Developers List  
Sent: Wednesday, 7 June 2017 7:19 PM
Subject: Re: [VOTE] Release Commons Fileupload 1.3.3 based on RC5



[ X ] +1 Release it.

All tests pass, artifacts generated successfully, and site correctly generated 
too with `mvn clean test install -e -X` on the following environments.

Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
2015-11-11T05:41:47+13:00)
Maven home: /opt/maven
Java version: 1.8.0_131, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-oracle/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"

Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
2015-11-11T05:41:47+13:00)
Maven home: /opt/maven
Java version: 1.7.0_80, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-7-oracle/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"

Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
2015-11-11T05:41:47+13:00)
Maven home: /opt/maven
Java version: 1.8.0, vendor: IBM Corporation
Java home: /home/kinow/Development/java/ibm-java-x86_64-80/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"


Reports look OK. Noticed that coverage could be enhanced for future releases. 
There are some classes with 0 tests (PortletFileUpload and 
PortletRequestContext) so I'm adding a note in my todo list to write some tests 
when I have some spare time (happy if anyone does so first :).

I think NOTICE.txt was not updated to include 2017 in the year (I believe we 
manually update this file?), but that's trivial and definitely not a blocker (I 
guess we just fix it later - if necessary).

My local web site has changes report showing 1.3.3 with date as tbd. Yours is 
showing 1.4 with date set to today, but I guess it's temporary and after the 
release it will display 1.3.3 and another date? Anyway, FILEUPLOAD-279 is not 
there, but this shouldn't be a blocker.

Didn't have much time so checked only the main jar gpg signature, and it's also 
looking OK.

Go for it, and thanks for preparing the release!
Cheers

Bruno

ps: first time I look at the DOAP file while reviewing a release... there are 
some releases missing there, but I guess it's not updated automagically by 
Maven... maybe those blocks could be removed?

From: Rob Tompkins 
To: Commons Developers List  
Sent: Wednesday, 7 June 2017 6:26 AM
Subject: [VOTE] Release Commons Fileupload 1.3.3 based on RC5



Hello all,


This is a [VOTE] for releasing Apache Commons Fileupload 1.3.3 (from RC5).


Tag name:

   commons-fileupload-1.3.3-RC5 (signature can be checked from git using 'git 
tag -v')


Tag URL:

  
https://git-wip-us.apache.org/repos/asf?p=commons-fileupload.git;a=commit;h=dd2238b1671644cfead0e87c24a8ac61b4039084


Commit ID the tag points at:

   dd2238b1671644cfead0e87c24a8ac61b4039084


Site:

  http://home.apache.org/~chtompki/commons-fileupload-1.3.3-RC5


Distribution files (committed at revision 19901):

  https://dist.apache.org/repos/dist/dev/commons/fileupload/


Distribution files hashes (SHA1):

   commons-fileupload-1.3.3-bin.tar.gz

   (SHA1: 2f4a9672168641ff726974a3b7cc68b97d1212fa)

   commons-fileupload-1.3.3-bin.zip

   (SHA1: b66e2c434ddbda90dfc9e92af4775d9777524bfa)

   commons-fileupload-1.3.3-src.tar.gz

   (SHA1: 71294a7d737a8ced04934c222ae6dfb16e4d8d73)

   commons-fileupload-1.3.3-src.zip

   (SHA1: 661172a2f62b460c4b754b7a0f04d412afabde52)


These are the Maven artifacts and their hashes:

   commons-fileupload-1.3.3-javadoc.jar

   (SHA1: 92d2fc371379d64a822150ca3882157564dd3f99)

   commons-fileupload-1.3.3-sources.jar

   (SHA1: c8c7bcb851fb5af0b19e4ea845cf2fc03de6f673)

   commons-fileupload-1.3.3-test-sources.jar

   (SHA1: 5e0d8c621d38694e0f2960ab2899ee1d67f2b708)

   commons-fileupload-1.3.3-tests.jar

   (SHA1: 20510147958fc759582e6ede789ccf31d056b232)

   commons-fileupload-1.3.3.jar

   (SHA1: fd754c7518772453aea1d5ffc32cb5ce0ebc0e40)

   commons-fileupload-1.3.3.pom

   (SHA1: 97d781eafc190f4fee3abf11f9ec8076f5f7b58c)


KEYS file to check signatures:

  http://www.apache.org/dist/commons/KEYS


Maven artifacts:

  https://repository.apache.org/content/repositories/orgapachecommons-1249


Please select one of the following options[1]:

  [ ] +1 Release it.

  [ ] +0 Go ahead; I don't care.

  [ ] -0 There are a few minor glitches: ...

  [ ] -1 No, 

Re: OSGi Version at Package Level

[Bertrand Delacretaz]

On Wed, Jun 7, 2017 at 9:10 AM, Emmanuel Bourg  wrote:
> ...Do I understand well that we would have to micro manage versions at the
> package level different from the version at the component level, and
> sometimes significantly different versions (like foo 1.2.3 and
> org.apache.commons.foo.bar 2.3.4)?...

That's how it's done in OSGi-based systems.

>... That sounds like a nightmare...

With the right tools as mentioned in my previous message it's quite easy.

> ...What existing problem would that solve exactly?...

Implementing semantic versioning at the java package level as opposed
to bundle level.

In heavily componentized systems that's a big help, assuming the Java
packages make sense - to paraphrase Grady Booch, one package should do
one thing and one thing well.

On the other hand, if you don't care about package-level versioning
and consider your bundle as one big thing on which other things
depend, that doesn't help much.

-Bertrand

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Commons Fileupload 1.3.3 based on RC5

[Bruno P. Kinoshita]

[ X ] +1 Release it.

All tests pass, artifacts generated successfully, and site correctly generated 
too with `mvn clean test install -e -X` on the following environments.

Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
2015-11-11T05:41:47+13:00)
Maven home: /opt/maven
Java version: 1.8.0_131, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-oracle/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"

Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
2015-11-11T05:41:47+13:00)
Maven home: /opt/maven
Java version: 1.7.0_80, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-7-oracle/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"

Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
2015-11-11T05:41:47+13:00)
Maven home: /opt/maven
Java version: 1.8.0, vendor: IBM Corporation
Java home: /home/kinow/Development/java/ibm-java-x86_64-80/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"


Reports look OK. Noticed that coverage could be enhanced for future releases. 
There are some classes with 0 tests (PortletFileUpload and 
PortletRequestContext) so I'm adding a note in my todo list to write some tests 
when I have some spare time (happy if anyone does so first :).

I think NOTICE.txt was not updated to include 2017 in the year (I believe we 
manually update this file?), but that's trivial and definitely not a blocker (I 
guess we just fix it later - if necessary).

My local web site has changes report showing 1.3.3 with date as tbd. Yours is 
showing 1.4 with date set to today, but I guess it's temporary and after the 
release it will display 1.3.3 and another date? Anyway, FILEUPLOAD-279 is not 
there, but this shouldn't be a blocker.

Didn't have much time so checked only the main jar gpg signature, and it's also 
looking OK.

Go for it, and thanks for preparing the release!
Cheers

Bruno

ps: first time I look at the DOAP file while reviewing a release... there are 
some releases missing there, but I guess it's not updated automagically by 
Maven... maybe those blocks could be removed?

From: Rob Tompkins 
To: Commons Developers List  
Sent: Wednesday, 7 June 2017 6:26 AM
Subject: [VOTE] Release Commons Fileupload 1.3.3 based on RC5



Hello all,


This is a [VOTE] for releasing Apache Commons Fileupload 1.3.3 (from RC5).


Tag name:

   commons-fileupload-1.3.3-RC5 (signature can be checked from git using 'git 
tag -v')


Tag URL:

  
https://git-wip-us.apache.org/repos/asf?p=commons-fileupload.git;a=commit;h=dd2238b1671644cfead0e87c24a8ac61b4039084


Commit ID the tag points at:

   dd2238b1671644cfead0e87c24a8ac61b4039084


Site:

  http://home.apache.org/~chtompki/commons-fileupload-1.3.3-RC5


Distribution files (committed at revision 19901):

  https://dist.apache.org/repos/dist/dev/commons/fileupload/


Distribution files hashes (SHA1):

   commons-fileupload-1.3.3-bin.tar.gz

   (SHA1: 2f4a9672168641ff726974a3b7cc68b97d1212fa)

   commons-fileupload-1.3.3-bin.zip

   (SHA1: b66e2c434ddbda90dfc9e92af4775d9777524bfa)

   commons-fileupload-1.3.3-src.tar.gz

   (SHA1: 71294a7d737a8ced04934c222ae6dfb16e4d8d73)

   commons-fileupload-1.3.3-src.zip

   (SHA1: 661172a2f62b460c4b754b7a0f04d412afabde52)


These are the Maven artifacts and their hashes:

   commons-fileupload-1.3.3-javadoc.jar

   (SHA1: 92d2fc371379d64a822150ca3882157564dd3f99)

   commons-fileupload-1.3.3-sources.jar

   (SHA1: c8c7bcb851fb5af0b19e4ea845cf2fc03de6f673)

   commons-fileupload-1.3.3-test-sources.jar

   (SHA1: 5e0d8c621d38694e0f2960ab2899ee1d67f2b708)

   commons-fileupload-1.3.3-tests.jar

   (SHA1: 20510147958fc759582e6ede789ccf31d056b232)

   commons-fileupload-1.3.3.jar

   (SHA1: fd754c7518772453aea1d5ffc32cb5ce0ebc0e40)

   commons-fileupload-1.3.3.pom

   (SHA1: 97d781eafc190f4fee3abf11f9ec8076f5f7b58c)


KEYS file to check signatures:

  http://www.apache.org/dist/commons/KEYS


Maven artifacts:

  https://repository.apache.org/content/repositories/orgapachecommons-1249


Please select one of the following options[1]:

  [ ] +1 Release it.

  [ ] +0 Go ahead; I don't care.

  [ ] -0 There are a few minor glitches: ...

  [ ] -1 No, do not release it because ...


This vote will be open at least 72 hours, i.e. until 

2017-06-09T19:00:00Z

(this is UTC time).




Cheers,

-Rob


[1] http://apache.org/foundation/voting.html

-

To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org

For additional commands, e-mail: dev-h...@commons.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For 

Re: OSGi Version at Package Level

[Emmanuel Bourg]

Le 7/06/2017 à 02:10, Jörg Schaible a écrit :

> Your opinions?

Do I understand well that we would have to micro manage versions at the
package level different from the version at the component level, and
sometimes significantly different versions (like foo 1.2.3 and
org.apache.commons.foo.bar 2.3.4)? That sounds like a nightmare. What is
the real gain? What existing problem would that solve exactly?

Emmanuel Bourg

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: OSGi Version at Package Level

[Bertrand Delacretaz]

Hi,

On Wed, Jun 7, 2017 at 2:10 AM, Jörg Schaible  wrote:
> ...maybe you have missed the discussion for
> https://issues.apache.org/jira/browse/COMPRESS-399, but in short we face a
> PR that introduces individual versions at package level for a component

That's standard practice for OSGi bundles.

The https://github.com/apache/commons-compress/pull/26 changes look
suboptimal because they set the same initial version for each exported
package, but that's correct as a way to start doing that.

The "baseline" goal of the Apache Felix maven-bundle-plugin can then
be used to automatically recommend changes to those version numbers to
implement semantic versioning *at the java package level* which is the
way OSGi handles this.

We're using this extensively in Apache Sling, where we release a large
number of bundles each with their own package-level version numbers
which evolve independently from the bundle version. It works well once
it's setup, which is what that pull/26 does AFAICS.

Here's example output from that plugin building [1] after adding a
method to a class in the o.a.s.distribution package:

[INFO] Baseline Report - Generated by Apache Felix Maven Bundle Plugin
on 2017-06-07T08:54Z based on Bnd - see http://www.aqute.biz/Bnd/Bnd
[INFO] Comparing bundle org.apache.sling.distribution.api version
0.3.1-SNAPSHOT to version 0.3.0
[INFO]
[INFO]   PACKAGE_NAME   DELTA
CUR_VERBASE_VER   REC_VERWARNINGS
[INFO] = == ==
== == == ==
[INFO] * org.apache.sling.distribution  minor
0.3.0  0.3.0  0.4.0  Version increase required
[INFO]  < interface org.apache.sling.distribution.Distributor
[INFO]  + method doNothing()
[INFO]  + access abstract
[INFO] 
---
[INFO]   org.apache.sling.distribution.eventunchanged
0.1.1  0.1.1  0.1.1  -
[INFO] 
---
[INFO]   org.apache.sling.distribution.transportunchanged
0.1.0  0.1.0  0.1.0  -
[INFO] 
---
[ERROR] org.apache.sling.distribution: Version increase required;
detected 0.3.0, suggested 0.4.0
[INFO] Baseline analysis complete, 1 error(s), 0 warning(s)

HTH,
-Bertrand

[1] 
https://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/distribution/api

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org