Re: [compress] [Poll] Dealing with uncaught RuntimeExceptions

[Oliver Heger]

Am 30.06.21 um 14:41 schrieb Gary Gregory:

On Tue, Jun 29, 2021 at 4:24 PM Stefan Bodewig  wrote:


Hi

I'm sorry, but I'm unable to see what would or would not work for the
people who chimed in. Short of calling for a vote, lets try with a poll
that could show whether there is some sort of solution that is
acceptable to everybody.

Please use +1 to mean "I like this option", +0 to mean "the option is
OK, but I'd prefer a different one", -0 for "I don't like the option but
I can live with it" and -1 for "this option is not acceptable to me.

Options raised during the thread:

(1) catch all RuntimeExceptions, wrap them in an IOException (possibly a
 subclass) and throw the IOException


-1. There will no end to this and our code will be riddled and
cluttered with try-catch clauses.



(2) catch only a subset of all RuntimeExceptions, wrap them in an
 IOException (possibly a subclass) and throw the IOException - allow
 the remaining RuntimeExceptions to fly through


-0. Selective implementation might be OK but I prefer throwing
unchecked exceptions for unrecoverable errors like a negative index.



(3) catch all RuntimeExceptions, wrap them in an specific unchecked
 exception (which one could be discussed later) and throw this one


-1. That one does not make sense to me.



(4) don't catch RuntimeExceptions at all, just document broken archives
 can cause arbitrary RuntimeExceptions and code that tries to read
 archives from untrusted sources is expected to deal with them
 itself.


+0.

Here what I would prefer to see on our APIs:

- Throw IOException where we surface JRE IOException.
- Throw NPE where we use methods like Objects.requireNonNull().
- Throw IllegalArgumentException on other garbage API input arguments.
- Throw IllegalStateException when the archive is broken.


IIUC, the problem is that [compress] states that it throws an 
IOException, but in practice can throw arbitrary runtime exceptions as 
well. So IMHO, it would be a great improvement for the users to come to 
a definition under which circumstances what outcome is expected.


This will probably require some kind of translation from exceptions 
thrown during parsing to the exceptions declared by [compress]. How such 
a translation then looks like, is certainly a matter of taste. As the 
API currently uses IOExceptions anyway, using sub classes of this type 
would be fine with me.


In any case, I think we should implement some translation and not let 
all kinds of unexpected exceptions fall on our users.


Oliver



Gary


"Just harden all parsers" is a variation of (4) in my view as I don't
believe we would manage to cover all cases no matter how hard and long
we try.

I hope I didn't overlook any.

Thanks

 Stefan

-
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: The case for a Commons component

[Oliver Heger]

Am 05.05.21 um 21:54 schrieb Gilles Sadowski:

Le mer. 5 mai 2021 à 20:33, Oliver Heger
 a écrit :




Am 05.05.21 um 20:26 schrieb Gilles Sadowski:

Le mer. 5 mai 2021 à 18:57, Gary Gregory  a écrit :


IMO the lack of +1s shows the lack of appetite to manage another component


That's certainly true.
And nobody is forced to do anything.

When the other CM spin-offs started, there was only _one_ person
willing to do the work.


What about the sandbox? IIUC, every committer can start a new component
there. If then a community forms around this component, it can move to
proper (which would then require a vote).

Would this be an option to get started?


[Graph] is listed in the sandbox[1], yet when someone expressed a willingness
to contribute, we had a "git" repository created[2] (even though the
web site has
remained outdated[3], probably because the attempt was short-lived).

So indeed, I could have already created the repository a few weeks ago...

However in this instance, what would it mean to have codes that have lived
within a "proper" component for 6 years and more be moved to "sandbox"?


A way to move forward?

Oliver



Regards,
Gilles

[1] http://commons.apache.org/sandbox/commons-graph/
[2] https://gitbox.apache.org/repos/asf?p=commons-graph.git
[3] http://commons.apache.org/sandbox/commons-graph/source-repository.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: The case for a Commons component

[Oliver Heger]

Am 05.05.21 um 20:26 schrieb Gilles Sadowski:

Le mer. 5 mai 2021 à 18:57, Gary Gregory  a écrit :


IMO the lack of +1s shows the lack of appetite to manage another component


That's certainly true.
And nobody is forced to do anything.

When the other CM spin-offs started, there was only _one_ person
willing to do the work.


What about the sandbox? IIUC, every committer can start a new component 
there. If then a community forms around this component, it can move to 
proper (which would then require a vote).


Would this be an option to get started?

Oliver



Gilles


[...]


-
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: [CLI] CLI for Scala

[Oliver Heger]

Hi Gilles,

Am 20.09.20 um 19:44 schrieb Gilles Sadowski:
> Hello.
> 
> 2020-09-17 21:47 UTC+02:00, Oliver Heger :
>> Hi all,
>>
>> once we had a discussion (it must be one or two years ago) whether
>> Commons could support components in other (JVM) languages, too. IIRC,
>> there were no strong objections, but there has never been a follow up.
>>
>> For a project in Scala, I needed some limited functionality to process
>> command line parameters. I came up with a functional solution that
>> seemed to be pretty flexible. So I extracted the code into a separate
>> repository [1] and enhanced it.
>>
>> It is now in a shape that it supports a lot of the features typical to a
>> CLI library. The functional programming (FP) approach is probably
>> somewhat special: you define extractors using a DSL, which are actually
>> monads and thus can be nicely transformed and composed to more complex
>> structures. The end product is a configuration object representing all
>> the parameters passed to the application in a type-safe manner. The
>> repository contains a README describing the high-level concepts and a
>> tutorial [2] with a comprehensive description of all the features
>> available.
> 
> How does it compare with e.g.
> https://github.com/remkop/picocli
> ?

The philosophy is a bit different and more targeted to Scala, which
traditionally emphasizes a more functional approach. So no annotations
are used to declare targets for parameter injection, but you call a
function and get a data object back.

Currently, not all the functionality of picocli is available, but the
footprint is smaller.

Whether another CLI library is needed is a valid question, but I cannot
answer this.

> 
>> So I would like to ask again the question whether Commons could have
>> components in other programming languages, and more specifically,
>> whether this CLI for Scala library could be a candidate.
> 
> Given the current drift towards GitHub-centered development,
> what do you expect from bringing the code here?
Frankly, more popularity. It is pretty unlikely that a repository on
Github with a single contributor will be successful.

Thanks,
Oliver

> 
>> Notes:
>> - Except for the domain, there is no relation to the original [CLI]; the
>> concepts are completely different.
>> - The Scala CLI has been written in and for Scala; so the API can
>> probably not be used from Java directly.
>> - As special Scala language features are used, it won't be trivial to
>> port this code to Java; but maybe some of the ideas could be
>> incorporated into [CLI]?
> 
> IIRC, last time significant improvements were evoked for [CLI]
> someone mentioned "picocli"...
> 
> Regards,
> Gilles
> 
>>
>> Thanks
>> Oliver
>>
>> [1] https://github.com/oheger/scli
>> [2] https://github.com/oheger/scli/blob/master/Tutorial.adoc
> 
> -
> 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

[ALL][CLI] CLI for Scala

[Oliver Heger]

Resending with a different subject to potentially reach a broader audience.

Am 17.09.20 um 21:47 schrieb Oliver Heger:
> Hi all,
> 
> once we had a discussion (it must be one or two years ago) whether
> Commons could support components in other (JVM) languages, too. IIRC,
> there were no strong objections, but there has never been a follow up.
> 
> For a project in Scala, I needed some limited functionality to process
> command line parameters. I came up with a functional solution that
> seemed to be pretty flexible. So I extracted the code into a separate
> repository [1] and enhanced it.
> 
> It is now in a shape that it supports a lot of the features typical to a
> CLI library. The functional programming (FP) approach is probably
> somewhat special: you define extractors using a DSL, which are actually
> monads and thus can be nicely transformed and composed to more complex
> structures. The end product is a configuration object representing all
> the parameters passed to the application in a type-safe manner. The
> repository contains a README describing the high-level concepts and a
> tutorial [2] with a comprehensive description of all the features available.
> 
> So I would like to ask again the question whether Commons could have
> components in other programming languages, and more specifically,
> whether this CLI for Scala library could be a candidate.
> 
> Notes:
> - Except for the domain, there is no relation to the original [CLI]; the
> concepts are completely different.
> - The Scala CLI has been written in and for Scala; so the API can
> probably not be used from Java directly.
> - As special Scala language features are used, it won't be trivial to
> port this code to Java; but maybe some of the ideas could be
> incorporated into [CLI]?
> 
> Thanks
> Oliver
> 
> [1] https://github.com/oheger/scli
> [2] https://github.com/oheger/scli/blob/master/Tutorial.adoc
> 
> 
> 
> -
> 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

[CLI] CLI for Scala

[Oliver Heger]

Hi all,

once we had a discussion (it must be one or two years ago) whether
Commons could support components in other (JVM) languages, too. IIRC,
there were no strong objections, but there has never been a follow up.

For a project in Scala, I needed some limited functionality to process
command line parameters. I came up with a functional solution that
seemed to be pretty flexible. So I extracted the code into a separate
repository [1] and enhanced it.

It is now in a shape that it supports a lot of the features typical to a
CLI library. The functional programming (FP) approach is probably
somewhat special: you define extractors using a DSL, which are actually
monads and thus can be nicely transformed and composed to more complex
structures. The end product is a configuration object representing all
the parameters passed to the application in a type-safe manner. The
repository contains a README describing the high-level concepts and a
tutorial [2] with a comprehensive description of all the features available.

So I would like to ask again the question whether Commons could have
components in other programming languages, and more specifically,
whether this CLI for Scala library could be a candidate.

Notes:
- Except for the domain, there is no relation to the original [CLI]; the
concepts are completely different.
- The Scala CLI has been written in and for Scala; so the API can
probably not be used from Java directly.
- As special Scala language features are used, it won't be trivial to
port this code to Java; but maybe some of the ideas could be
incorporated into [CLI]?

Thanks
Oliver

[1] https://github.com/oheger/scli
[2] https://github.com/oheger/scli/blob/master/Tutorial.adoc



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

Re: [all] Dependabot PRs

[Oliver Heger]

Am 22.07.20 um 18:28 schrieb Stefan Bodewig:
> On 2020-07-22, Rob Tompkins wrote:
> 
>> I’m happy to merge them….will get to them by tomorrow morning ok?
> 
> TBH I'd prefer to turn them off and reject the PRs.
> 
> Personally I don't see any value for our downstream users if we update
> our dependencies without actually needing an update - with the exception
> of security updates. I don't like the idea of forcing our users to
> update a different dependency just because they update our component, it
> should be their choice when to update what.
> 
> Of course this is just my opinion and I'm not exactly known as somebody
> who embraces the idea of automatic resolution of transitive dependencies
> in the first place ;-)

Stefan has a valid point here IMHO. From out user's POV, our components
are in some sense "more compatible" if they reference the oldest
possible version of a dependency rather than the newest one.

If we upgrade dependencies rather aggressively, it would be nice to
document a version range for the dependencies that has been tested. This
could save users from possible version conflicts with other 3rd party
dependencies. Creating such a documentation is probably hard though; I
do not think that this can be automated.

Oliver

> 
> Stefan
> 
> -
> 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: [CVE-2020-1953] Uncontrolled class instantiation when loading YAML files in Apache Commons Configuration

[Oliver Heger]

The form at Mitre was just submitted, so I assume that the issue will be
visible soon.

Oliver

Am 12.03.20 um 19:18 schrieb Gary Gregory:
> Note that  https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-1953 is not
> "live" yet.
> 
> Gary
> 
> On Thu, Mar 12, 2020 at 1:53 PM Oliver Heger  wrote:
> 
>> CVE-2020-1953: Uncontrolled class instantiation when loading YAML files
>> in Apache Commons Configuration
>>
>> Severity: Moderate
>>
>> Vendor:
>> The Apache Software Foundation
>>
>> Versions Affected:
>> 2.2 to 2.6
>>
>> Description:
>> Apache Commons Configuration uses a third-party library to parse YAML
>> files which by default allows the instantiation of classes if the YAML
>> includes special statements. If a YAML file is from an untrusted source,
>> it can therefore load and execute code out of the control of the host
>> application.
>>
>> Mitigation:
>> Users should upgrade to to 2.7, which prevents class instantiation by
>> the YAML processor.
>>
>> Credit:
>> This issue was discovered by Daniel Kalinowski of ISEC.pl Research Team
>>
>> Oliver Heger
>> on behalf of the Apache Commons PMC
>>
>>
>> -
>> 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

[CVE-2020-1953] Uncontrolled class instantiation when loading YAML files in Apache Commons Configuration

[Oliver Heger]

CVE-2020-1953: Uncontrolled class instantiation when loading YAML files
in Apache Commons Configuration

Severity: Moderate

Vendor:
The Apache Software Foundation

Versions Affected:
2.2 to 2.6

Description:
Apache Commons Configuration uses a third-party library to parse YAML
files which by default allows the instantiation of classes if the YAML
includes special statements. If a YAML file is from an untrusted source,
it can therefore load and execute code out of the control of the host
application.

Mitigation:
Users should upgrade to to 2.7, which prevents class instantiation by
the YAML processor.

Credit:
This issue was discovered by Daniel Kalinowski of ISEC.pl Research Team

Oliver Heger
on behalf of the Apache Commons PMC


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

Re: [VOTE] Release Apache Commons Configuration 2.7 based on RC2

[Oliver Heger]

+1

Build works fine with Java 8, artifacts and site look good.

Oliver

Am 09.03.20 um 15:55 schrieb Rob Tompkins:
> We have fixed quite a few bugs and added some significant enhancements since 
> Apache Commons Configuration 2.6 was released, so I would like to release 
> Apache Commons Configuration 2.7.
> 
> Apache Commons Configuration 2.7 RC2 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/configuration/2.7-RC2 (svn 
> revision 38450)
> 
> The Git tag commons-configuration-2.7-RC2 commit for this RC is 
> 03baa3bfbe123972da39c23e52fcd2d458e805fc which you can browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-configuration.git;a=commit;h=03baa3bfbe123972da39c23e52fcd2d458e805fc
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-configuration.git 
> --branch commons-configuration-2.7-RC2 commons-configuration-2.7-RC2
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-${commons.nexus.repo.id}/org/apache/commons/commons-configuration2/2.7/
> 
> These are the artifacts and their hashes:
> 
> #Nexus SHA-1s
> commons-configuration2-2.7-sources.jar=ff209aff7768faf4f01f9cd8ed37caa1558d062a
> commons-configuration2-2.7.pom=0c68e52d5e7af3b587be9b12a0e39f326f3501a5
> commons-configuration2-2.7-javadoc.jar=7eae6541d54684bb197ac60f8fe60c3e6997f821
> commons-configuration2-2.7-test-sources.jar=4a554ae0ccc754ee6208921ef993b5ef1fca8c22
> commons-configuration2-2.7-tests.jar=0d6d5929981144464be944c071cf845e3faf5a29
> commons-configuration2-2.7.jar=593326399e5fb5e1f986607f06f63c1250ab36b4
> 
> #Release SHA-512s
> #Mon Mar 09 10:30:13 EDT 2020
> commons-configuration2-2.7-bin.tar.gz=769646c10ccbff009526897d68bf19ccae1382d3d299d0133c034104fe9dc291927c5ddaa413b819b29d366cd2bc309ac0dace00b261ddc40aff7e72fca4ff8d
> commons-configuration2-2.7-bin.zip=80731fdd2c01b78fa0e8e5ad09e589ce6998bd071ea80d3df29c6212a7ee46613ec64076eae63d8955cf8f2c8a180d90fa5b8a75498d581b02e2965470a29b7e
> commons-configuration2-2.7-src.tar.gz=dcb66f53d8e593025dcc1824b6b86adc6227cc34a8e4ff39d7ff80204153d2b798c8d16f2f0c4d92a8839e36442f5f0247d1b00fd2875b9e1671c8d0cbe22ef5
> commons-configuration2-2.7-src.zip=3233020b71e67681c43d3470862236cfec130e9da597fbb37afdac115ffacf1aa94096eb6966f585ae9945c2ce6b45b4a6f572d0d303d096440da24e7281e60b
> 
> 
> I have tested this with 'mvn clean install site' using: 
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /usr/local/Cellar/maven/3.6.3_1/libexec
> Java version: 1.8.0_242, vendor: Amazon.com Inc., runtime: 
> /Library/Java/JavaVirtualMachines/amazon-corretto-8.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.15.3", arch: "x86_64", family: "mac"
> 
> Details of changes since 2.6 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/configuration/2.7-RC2/RELEASE-NOTES.txt
> 
> https://dist.apache.org/repos/dist/dev/commons/configuration/2.7-RC2/site/changes-report.html
> 
> Site:
> 
> https://dist.apache.org/repos/dist/dev/commons/configuration/2.7-RC2/site/index.html
> (note some *relative* links are broken and the 2.7 directories are not 
> yet created - these will be OK once the site is deployed.)
> 
> Japicmp.
> Still missing, not sure how to re-create this. Was working under 
> -SHAPSHOT. If warranted, willing to attempt an RC3 to try to get the report 
> created.
> 
> RAT Report:
> 
> https://dist.apache.org/repos/dist/dev/commons/configuration/2.7-RC2/site/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.
> 
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
> 
> Thank you,
> 
> Rob Tompkins, 
> Release Manager (using key B6E73D84EA4FCC47166087253FAAD2CD5ECBB314)
> 
> For following is intended as a helper and refresher for reviewers.
> 
> Validating a release candidate
> ==
> 
> These guidelines are NOT complete.
> 
> Requirements: Git, Java, Maven.
> 
> You can validate a release from a release candidate (RC) tag as follows.
> 
> 1) Clone and checkout the RC tag
> 
> git clone https://gitbox.apache.org/repos/asf/commons-configuration.git 
> --branch commons-configuration-2.7-RC2 commons-configuration-2.7-RC2
> cd commons-configuration-2.7-RC2
> 
> 2) Check Apache licenses
> 
> This step is not required if the site includes a RAT report page which you 
> then must check.
> 
> mvn apache-rat:check
> 
> 3) Check binary compatibility
> 
> Older components still use Apache Clirr:
> 
> This step is not required if the site includes a Clirr report page which you 
> then must check.
> 
> mvn clirr:check
> 
> Newer components use JApiCmp with the japicmp Maven Profile:
> 
> This step 

Re: [CANCEL][VOTE] Release Apache Commons Configuration 2.7 based on RC1

[Oliver Heger]

Hi Rob,

many thanks for working on the release.

I also did a check. The builds of the jar and the site were successful
with the configuration below. Artifacts and site look good.

The NOTICE file has still a copyright year of 2019; so if you re-roll
the RC, you should adapt this. Otherwise, I found no problems.

Oliver

Apache Maven 3.6.0
Maven home: /usr/share/maven
Java version: 1.8.0_242, vendor: Amazon.com Inc., runtime:
/opt/amazon-corretto-8.242.08.1-linux-x64/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: "linux", version: "5.3.0-40-generic", arch: "amd64", family: "unix"

Am 08.03.20 um 18:04 schrieb Rob Tompkins:
> This vote is cancelled.
> 
> I’m not particular as to how it’s built. My convention was to use latest long 
> term support, hence my using java 11 here. Thus, based on your point below, 
> I’ll re-roll the RC later today.
> 
> Many thanks for the eyes there,
> -Eob
> 
>> On Mar 8, 2020, at 9:53 AM, Gary Gregory  wrote:
>>
>> Hm... I do not think we should be build Java 8 components with Java 11.
>> It's too risky to bind to Buffer APIs that have different return types
>> starting in Java 9 and end up with potential problems when running on Java
>> 8.
>>
>> Sure, it's nice to have searchable Javadocs but if we really want that, we
>> can build the Javadoc with Java 9+ as a separate step.
>>
>> Gary
>>
>>> On Sat, Mar 7, 2020 at 3:32 PM Rob Tompkins  wrote:
>>>
>>> We have fixed quite a few bugs and added some significant enhancements
>>> since Apache Commons Configuration 2.6 was released, so I would like to
>>> release Apache Commons Configuration 2.7.
>>>
>>> Apache Commons Configuration 2.7 RC1 is available for review here:
>>>https://dist.apache.org/repos/dist/dev/commons/configuration/2.7-RC1
>>> (svn revision 38432)
>>>
>>> The Git tag commons-configuration-2.7-RC1 commit for this RC is
>>> 6bb7c21c14849169415b2afdfb2d2057bc2adb08 which you can browse here:
>>>
>>> https://gitbox.apache.org/repos/asf?p=commons-configuration.git;a=commit;h=6bb7c21c14849169415b2afdfb2d2057bc2adb08
>>> You may checkout this tag using:
>>>git clone
>>> https://gitbox.apache.org/repos/asf/commons-configuration.git --branch
>>> commons-configuration-2.7-RC1 commons-configuration-2.7-RC1
>>>
>>> Maven artifacts are here:
>>>
>>> https://repository.apache.org/content/repositories/orgapachecommons-1493/org/apache/commons/commons-configuration2/2.7/
>>>
>>> These are the artifacts and their hashes:
>>>
>>> #Nexus SHA-1s
>>>
>>> commons-configuration2-2.7-sources.jar=818bedbcfee18f8d845714f2f25bc134b5c55df6
>>> commons-configuration2-2.7.pom=161b149bcc081f3bb7424e2240eb40bcc42d5e63
>>>
>>> commons-configuration2-2.7-javadoc.jar=60e703ae819555b5e11f1809d1eed9a796e30785
>>>
>>> commons-configuration2-2.7-test-sources.jar=7e6ae52be57ae2bf55a3c78da9d7ddf1f34c5e72
>>>
>>> commons-configuration2-2.7-tests.jar=30e2de8e75127812dfd0065798ba57960530b940
>>> commons-configuration2-2.7.jar=c3774a0e5125e7c517e09dafd838b526cca7f3af
>>>
>>> #Release SHA-512s
>>> #Sat Mar 07 14:51:49 EST 2020
>>>
>>> commons-configuration2-2.7-src.zip=67f7243d9c9af313689d772340421e282956f0435df53afc117ae5b6b37947903157078845a8fb78e4ec4de565fd692f01cb7c145ae41fb8484b836d08343dca
>>>
>>> commons-configuration2-2.7-bin.tar.gz=ee03921e17e3998c5f613956e518caff5a324b5b33b23e85751394f92f19221079d6a1b3e6d1f71e704f531f017ccd28a6bd7c2e555bc37431e34be48bb96f57
>>>
>>> commons-configuration2-2.7-src.tar.gz=b7570dc57a065d15229faa84babdb5d0be223322444b787cb190345105e69c67a86cbf673c0df0b62b30223451d052695e84a5337c3273c5a599eaa19bb541a1
>>>
>>> commons-configuration2-2.7-bin.zip=331c11e96d3361c6414b7eb9b19dbdcde3d3b495ad6b46237db0da594d86d46df29e44a3a5c038503dc47ef7e3aeb04af4c733fa26c13e7373301a319b9b3071
>>>
>>>
>>>
>>> I have tested this with 'mvn clean install site' using:
>>> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
>>> Maven home: /usr/local/Cellar/maven/3.6.3_1/libexec
>>> Java version: 11.0.6, vendor: Amazon.com Inc., runtime:
>>> /Library/Java/JavaVirtualMachines/amazon-corretto-11.jdk/Contents/Home
>>> Default locale: en_US, platform encoding: UTF-8
>>> OS name: "mac os x", version: "10.15.3", arch: "x86_64", family: "mac"
>>>
>>>
>>> Details of changes since 2.6 are in the release notes:
>>>
>>> https://dist.apache.org/repos/dist/dev/commons/configuration/2.7-RC1/RELEASE-NOTES.txt
>>>
>>> https://dist.apache.org/repos/dist/dev/commons/configuration/2.7-RC1/site/changes-report.html
>>>
>>> Site:
>>>
>>> https://dist.apache.org/repos/dist/dev/commons/configuration/2.7-RC1/site/index.html
>>>
>>> RAT Report:
>>>
>>> https://dist.apache.org/repos/dist/dev/commons/configuration/2.7-RC1/site/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.
>>>
>>>  [ ] +1 Release these artifacts
>>>  [ ] +0 OK, but...
>>>  [ ] -0 OK, but really should fix...
>>>  [ ] -1 I oppose this 

Re: [compress] What to do with the changed OSGi Bundle Name?

[Oliver Heger]

Am 02.01.20 um 12:08 schrieb Bruno P. Kinoshita:
> Also not a user of OSGi. But I feel like it is a bug that could be reverted 
> and informed in the changelog and release email?
> But not too sure if that's the best option.
> Bruno
> 
> Sent from Yahoo Mail on Android 
>  
>   On Thu, 2 Jan 2020 at 22:56, Stefan Bodewig wrote:   Hi 
> all
> 
> due to a change in the parent POM the Bundle-SymbolicName of the
> commons-compress JAR changed from org.apache.commons.compress to
> org.apache.commons.commons-compress with version 1.18. So we've had a
> lot of releases up to 1.17 with one name and two newer releases with a
> different name in 1.18 and 1.19.
> 
> https://issues.apache.org/jira/browse/COMPRESS-498
> 
> Now we've got two options.
> 
> 1. Call this a bug and revert to org.apache.commons.compress in 1.20.
> 
>   This will make users of Compress up to 1.17 happy when they upgrade.
>   But it alienates people who used 1.1[89], in particular if they have
>   already adapted to the new symbolic name.
> 
> 2. Call this a mistake but stick to org.apache.commons.commons-compress
>   for 1.20 and future releases.
> 
>   This will make users of Compress up to 1.17 unhappy when they
>   upgrade, but makes upgrades seemless for people using 1.18 or 19.
> 
> I'm more or less on the fence here as I'm not an OSGi user myself.
> 
> Given that COMPRESS-498 came up more than a year after 1.18 has been
> released makes me think we either haven't got many OSGi users, they
> don't upgrade Compress frequently or they silently suffer and adapt to
> whatever we do.

The change of the bundle name does not necessarily break all OSGi users.
AFAIK, the recommended way to use an OSGi bundle is to import the
packages, not to require a specific bundle - this use case would not be
affected by the change of the bundle name.

As the change happened a while ago without major complaints, I would
tend towards keeping the new name; but this is more or less a gut feeling.

Oliver

> 
> Stefan
> 
> -
> 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: [Configuration] Optional Includes in Properties files

[Oliver Heger]

Am 20.05.19 um 16:19 schrieb sebb:
> On Mon, 20 May 2019 at 14:58, Gary Gregory  wrote:
>>
>> On Mon, May 20, 2019 at 9:16 AM Gilles Sadowski 
>> wrote:
>>
>>> Le lun. 20 mai 2019 à 14:51, Gary Gregory  a
>>> écrit :

 Hi All:

 Right now, if you uses an 'include' in a properties file and that file is
 missing, the rest of the file does not load.
>>>
>>> IMHO, it seems like a bug.
>>>
>>> If the contents is required, failure should occur because of that
>>> (later, according to code logic), not because the file is missing.
>>>
 I'd like to add a 'includesoptional' where nothing happens if the file is
 missing.

 Any objections or thoughts on a better name?
>>>
>>> includeifexist
>>> (?)
>>>
>>
>> Maybe; with includeoptional, I was imitating
>> https://httpd.apache.org/docs/2.4/mod/core.html#includeoptional
> 
> I find includeoptional marginally easier to read.
> And it avoids having to remember if the spelling is includeifexist or
> includeifexists
> 
> But I agree with Gilles that it seems like a bug if a missing include
> does not throw an error.

Note that the builder mechanism for combined configuration sources
already supports optional configuration sources. Details can be found in
the user's guide [1].

Oliver

[1]
https://commons.apache.org/proper/commons-configuration/userguide/howto_combinedbuilder.html#Optional_configuration_sources

> 
>> Gary
>>
>>
>>>
>>> Gilles
>>>

 Gary
>>>
>>> -
>>> 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: [lang] Deamon thread factory

[Oliver Heger]

Hi,

BasicThreadFactory has an option to create daemon threads. I assume, you
have found out in the meantime?

Oliver

Am 01.05.19 um 23:07 schrieb Gary Gregory:
> Hi All,
> 
> Hard to believe, but we do not have one yet.
> 
> https://issues.apache.org/jira/browse/LANG-1455
> 
> Assigned to your truly.
> 
> Gary
> 

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

Re: [VOTE] Redirect github notifications to issues@

[Oliver Heger]

+1

Oliver

Am 19.02.19 um 22:35 schrieb Marcelo Vanzin:
> I'm opening a vote based on recent discussions about the extra noise
> generated by github updates going to dev@. So please vote:
> 
> - +1 to redirect github updates of all commons repos to the issues@ list
> - -1 to keep things as is
> 
> If the vote passes, I'll take care of opening an infra ticket
> referencing the result.
> 

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

Re: [VOTE][LAZY] Move all proper svn repos to gitbox

[Oliver Heger]

+1

Oliver

Am 08.01.19 um 17:25 schrieb Rob Tompkins:
> Vote statement: "I propose we move all ‘proper' svn repos to gitbox."
> 
> I went though, and I think these are the ones that need to be migrated:
> 
> bcel/
> beanutils/
> bsf/
> chain/
> codec/
> commons-parent/
> commons-skin (???)
> commons-configuration/
> daemon/
> digester/
> email/
> exec/
> functor/
> jci/
> jcs/
> jelly/
> jexl/
> jxpath/
> logging/ (???)
> net/
> ognl/
> proxy/
> validator/
> vfs/
> weaver/
> 
> I’m not quite sure if this list is complete. It would be good to have someone 
> come behind me to check the list. After this vote my plan is to work peace 
> meal through the repositories and move them up to gitbox.
> 
> Cheers,
> -Rob
> -
> 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][LAZY] move commons git-wip repos to gitbox

[Oliver Heger]

+1

Oliver

Am 08.12.2018 um 21:09 schrieb Rob Tompkins:
> Infra stated that we need documented consensus on this. So, let’s have at it. 
> 
> I propose that we move the following repos over to gitbox:
> 
> commons-build-plugin.git   11 weeks ago
> commons-cli.git30 weeks ago
> commons-collections.git15 days ago
> commons-compress.git   19 days ago
> commons-crypto.git  9 weeks ago
> commons-csv.git 7 weeks ago
> commons-dbcp.git   24 days ago
> commons-dbutils.git30 weeks ago
> commons-fileupload.git 29 weeks ago
> commons-imaging.git 6 weeks ago
> commons-io.git 18 days ago
> commons-lang.git6 days ago
> commons-math.git   15 weeks ago
> commons-numbers.git 8 days ago
> commons-pool.git   16 days ago
> commons-rdf.git25 weeks ago
> commons-release-plugin.git 25 days ago
> commons-rng.git   < 2 days ago
> commons-scxml.git   7 weeks ago
> commons-statistics.git 30 weeks ago
> commons-testing.git30 weeks ago
> commons-text.git   14 days ago
> 
> This vote will close in 72 hours.
> 
> Cheers,
> -Rob
> -
> 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: svn commit: r1842139 - in /commons/proper/configuration/trunk: pom.xml src/changes/changes.xml src/main/java/org/apache/commons/configuration2/interpol/ConfigurationInterpolator.java src/main/java

[Oliver Heger]

Am 27.09.2018 um 20:43 schrieb ggreg...@apache.org:
> Author: ggregory
> Date: Thu Sep 27 18:43:37 2018
> New Revision: 1842139
> 
> URL: http://svn.apache.org/viewvc?rev=1842139=rev
> Log:
> [CONFIGURATION-720] Replace use of deprecated Commons Lang string 
> substitution code for Commons Text.
> 
> Modified:
> commons/proper/configuration/trunk/pom.xml
> commons/proper/configuration/trunk/src/changes/changes.xml
> 
> commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration2/interpol/ConfigurationInterpolator.java
> 
> commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration2/interpol/ExprLookup.java
> 
> Modified: commons/proper/configuration/trunk/pom.xml
> URL: 
> http://svn.apache.org/viewvc/commons/proper/configuration/trunk/pom.xml?rev=1842139=1842138=1842139=diff
> ==
> --- commons/proper/configuration/trunk/pom.xml (original)
> +++ commons/proper/configuration/trunk/pom.xml Thu Sep 27 18:43:37 2018
> @@ -274,6 +274,11 @@
>commons-lang3
>3.8.1
>  
> +
> +  org.apache.commons
> +  commons-text
> +  1.4
> +

In the site there is a manually maintained page with the dependencies of
this project (dependencies.xml). This one should be updated as well for
the new dependency to [text].

Thanks.

Oliver

>  
>  
>commons-logging
> 
> Modified: commons/proper/configuration/trunk/src/changes/changes.xml
> URL: 
> http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/changes/changes.xml?rev=1842139=1842138=1842139=diff
> ==
> --- commons/proper/configuration/trunk/src/changes/changes.xml (original)
> +++ commons/proper/configuration/trunk/src/changes/changes.xml Thu Sep 27 
> 18:43:37 2018
> @@ -44,6 +44,9 @@
>
>  Configuration properties can now be converted to regular expressions.
>
> +  
> +Replace use of deprecated Commons Lang string substitution code for 
> Commons Text.
> +  
>  
>  
>   
> Modified: 
> commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration2/interpol/ConfigurationInterpolator.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration2/interpol/ConfigurationInterpolator.java?rev=1842139=1842138=1842139=diff
> ==
> --- 
> commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration2/interpol/ConfigurationInterpolator.java
>  (original)
> +++ 
> commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration2/interpol/ConfigurationInterpolator.java
>  Thu Sep 27 18:43:37 2018
> @@ -26,8 +26,8 @@ import java.util.Set;
>  import java.util.concurrent.ConcurrentHashMap;
>  import java.util.concurrent.CopyOnWriteArrayList;
>  
> -import org.apache.commons.lang3.text.StrLookup;
> -import org.apache.commons.lang3.text.StrSubstitutor;
> +import org.apache.commons.text.StringSubstitutor;
> +import org.apache.commons.text.lookup.StringLookup;
>  
>  /**
>   * 
> @@ -107,7 +107,7 @@ public class ConfigurationInterpolator
>  private final List defaultLookups;
>  
>  /** The helper object performing variable substitution. */
> -private final StrSubstitutor substitutor;
> +private final StringSubstitutor substitutor;
>  
>  /** Stores a parent interpolator objects if the interpolator is nested 
> hierarchically. */
>  private volatile ConfigurationInterpolator parentInterpolator;
> @@ -474,9 +474,9 @@ public class ConfigurationInterpolator
>   *
>   * @return the {@code StrSubstitutor} used by this object
>   */
> -private StrSubstitutor initSubstitutor()
> +private StringSubstitutor initSubstitutor()
>  {
> -return new StrSubstitutor(new StrLookup()
> +return new StringSubstitutor(new StringLookup()
>  {
>  @Override
>  public String lookup(String key)
> 
> Modified: 
> commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration2/interpol/ExprLookup.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration2/interpol/ExprLookup.java?rev=1842139=1842138=1842139=diff
> ==
> --- 
> commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration2/interpol/ExprLookup.java
>  (original)
> +++ 
> commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration2/interpol/ExprLookup.java
>  Thu Sep 27 18:43:37 2018
> @@ -18,16 +18,16 @@ package org.apache.commons.configuration
>  
>  import java.util.ArrayList;
>  
> -import org.apache.commons.configuration2.io.ConfigurationLogger;
>  

Re: [configuration] Update from java 7 to Java 8.

[Oliver Heger]

Am 27.09.2018 um 19:27 schrieb Gary Gregory:
> Hi All:
> 
> I'd like to update [configuration] from java 7 to Java 8.

Just go on. I think it was consensus that after the latest release the
Java version should be upgraded.

Oliver

> 
> Gary
> 

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

Re: [jira] [Deleted] (COMMONSSITE-126) Menghapus klien bugs

[Oliver Heger]

Any chance this guy can be blocked? There has been similar spam like
this for other projects.

Oliver

Am 25.09.2018 um 15:35 schrieb Benedikt Ritter (JIRA):
> 
>  [ 
> https://issues.apache.org/jira/browse/COMMONSSITE-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>  ]
> 
> Benedikt Ritter deleted COMMONSSITE-126:
> 
> 
> 
>> Menghapus klien bugs
>> 
>>
>> Key: COMMONSSITE-126
>> URL: https://issues.apache.org/jira/browse/COMMONSSITE-126
>> Project: Commons All
>>  Issue Type: Bug
>> Environment: Menghapus perangkat lunak
>>Reporter: Moh.riza
>>Priority: Major
>>
>> Menghapus spam issue klien
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v7.6.3#76005)
> 

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

Re: [VOTE] Release Apache Commons Lang 3.8.1 based on RC1

[Oliver Heger]

Hi Rob,

build works fine with Java 8 on Windows 10. Artifacts and site look good.

+1

Some remarks:
- When running mvn site it did an SVN checkout to a folder named
site-content. What is the background of this?
- The japicmp report on the site you referenced looks pretty strange -
given the fact that only the pom was changed. When I build the site
locally the report consists only of an empty page.

Oliver

Am 19.09.2018 um 18:04 schrieb Rob Tompkins:
> We have fixed LANG-1419 "Restore BundleSymbolicName / regression in version 
> 3.8.0", so I would like to release Apache Commons Lang 3.8.1.
> 
> Apache Commons Lang 3.8.1 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/lang/3.8.1-RC1 (svn 
> revision 29514)
> 
> 
> The Git tag LANG_3_8_1_RC1 commit for this RC is 
> eb5b11a25c9e61f9b25a540682816ebb103b735c which you can browse here:
> 
> https://git-wip-us.apache.org/repos/asf?p=commons-lang.git;a=tag;h=refs/tags/LANG_3_8_1_RC1
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1381/org/apache/commons/commons-lang3/3.8.1/
> 
> These are the Maven artifacts and their hashes in Nexus:
> 
> #Nexus SHA-1s
> commons-lang3-3.8.1-tests.jar
> (SHA1: 05f58ffeafc75593ce46d73062165dc5d6cca765)
> commons-lang3-3.8.1.jar
> (SHA1: 6505a72a097d9270f7a9e7bf42c4238283247755)
> commons-lang3-3.8.1-sources.jar
> (SHA1: e9748d7783594da3735ad9724390a10e7cebc01d)
> commons-lang3-3.8.1-test-sources.jar
> (SHA1: 1308a9d4723d5cd2a4f1c3e0cec0054a48ccf2d2)
> commons-lang3-3.8.1.pom
> (SHA1: 59092f9d06947b986318dfbe297312e08379b0ae)
> commons-lang3-3.8.1-javadoc.jar
> (SHA1: e7e19f37a0e712862967e39558b888fb59ee5b6a)
> 
> #Release SHA-1s
> #Wed Sep 19 11:24:27 EDT 2018
> commons-lang3-3.8.1-javadoc-javadoc=e7e19f37a0e712862967e39558b888fb59ee5b6a
> commons-lang3-3.8.1-bin-zip=77bcf40ff7df6da4012411f121000b6576b96ca7
> commons-lang3-3.8.1-sources-java-source=e9748d7783594da3735ad9724390a10e7cebc01d
> commons-lang3-3.8.1-test-sources-java-source=1308a9d4723d5cd2a4f1c3e0cec0054a48ccf2d2
> commons-lang3-3.8.1-tests-test-jar=05f58ffeafc75593ce46d73062165dc5d6cca765
> commons-lang3-3.8.1-src-tar.gz=cc04982add9f5eb6c3759fa43a5878d9f11caeb7
> commons-lang3-3.8.1-src-zip=b94464fd51e8f322d9216327dfb82e602101fb0a
> commons-lang3-3.8.1-bin-tar.gz=62c84f0b3b99803d24f2e242dd05087f1ab0fed0
> 
> #Release SHA-256s
> #Wed Sep 19 11:24:27 EDT 2018
> commons-lang3-3.8.1-javadoc-javadoc=9581660137ce6b90a2f2b56775bddbac6fe2924bc73bcec1869cfb1af2908928
> commons-lang3-3.8.1-bin-zip=5bb02b0e30221c8545cdfadcf140df2fc1bcd8591da25ce93a930e78e69271e0
> commons-lang3-3.8.1-sources-java-source=a6589a5acef187a9c032b2afe22384acc3ae0bf15bb91ff67db8731ebb4323ca
> commons-lang3-3.8.1-test-sources-java-source=a2f26272ccc1817fc590f8b2544403bf4235f33c8de9dbdba89182eb19864c93
> commons-lang3-3.8.1-tests-test-jar=1594433d480e6e9ba7f2e6d2f60f18b855db42db1a35dbf0b4bc72e388b3c86e
> commons-lang3-3.8.1-src-tar.gz=9682e67375b6f03700e5bbaa2acceac60bc2f9049e11cafae3ce411ccaf633fb
> commons-lang3-3.8.1-src-zip=3109bf11a85342ddd31aa17e720bf5ca2f88f666e2cd073158d3a2f72b97b89c
> commons-lang3-3.8.1-bin-tar.gz=56fab92fb3e8a84385cac0d579bb85aa0bdb9f26f975a74a73d63edc121e7ff5
> 
> 
> 
> I have tested this with mvn clean install site' using: 
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 
> 2018-06-17T14:33:14-04:00)
> Maven home: /usr/local/Cellar/maven/3.5.4/libexec
> Java version: 1.8.0_172, vendor: Oracle Corporation, runtime: 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_172.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac"
> 
> Details of changes since 3.8 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/lang/3.8.1-RC1/RELEASE-NOTES.txt
> 
> https://dist.apache.org/repos/dist/dev/commons/lang/3.8.1-RC1/site/changes-report.html
> 
> Site:
> https://dist.apache.org/repos/dist/dev/commons/lang/3.8.1-RC1/site
> (note some *relative* links are broken and the 3.8.1 directories are not 
> yet created - these will be OK once the site is deployed.)
> 
> CLIRR Report (compared to 3.8):
> 
> https://dist.apache.org/repos/dist/dev/commons/lang/3.8.1-RC1/site/clirr-report.html
> 
> JApiCmp Report (compared to 3.8):
> 
> https://dist.apache.org/repos/dist/dev/commons/lang/3.8.1-RC1/site/japicmp.html
> 
> RAT Report:
> 
> https://dist.apache.org/repos/dist/dev/commons/lang/3.8.1-RC1/site/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.
> 
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
> 
> Thank you,
> 
> Rob Tompkins, 
> Release Manager (using key B6E73D84EA4FCC47166087253FAAD2CD5ECBB314)
> 

Re: [VOTE] Release Apache Commons Lang 3.8 based on RC1

[Oliver Heger]

Build works fine with Java 1.7 and 1.8 on Windows 10. Artifacts and site
look good.

One minor nit: I was a bit confused by the sentence in the release notes
"Lang 3.0 and onwards now targets Java 5.0...". This sounds as if the
minimum Java requirement was 5.0. A bit later it is correctly stated
that Java 7 is required.

+1

Oliver

Am 16.08.2018 um 03:54 schrieb Rob Tompkins:
> We have fixed quite a few bugs and added some significant enhancements since 
> Apache Commons Lang 3.7 was released, so I would like to release Apache 
> Commons Lang 3.8.
> 
> Apache Commons Lang 3.8 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/lang/3.8-RC1 (revision 
> 28761)
> 
> The Git tag LANG_3_8_RC1 commit for this RC is 
> 9801e2fb9fcbf7ddd19221e9342608940d778f8c which you can browse here:
> 
> https://git-wip-us.apache.org/repos/asf?p=commons-lang.git;a=tag;h=refs/tags/LANG_3_8_RC1
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1368/org/apache/commons/commons-lang3/3.8/
> 
> These are the Maven artifacts and their hashes in Nexus:
> 
> #Nexus SHA-1s
> commons-lang3-3.8-sources.jar
> (SHA1: 546b07aafba4fe00a514627bfb854ffc0c23406a)
> commons-lang3-3.8-tests.jar
> (SHA1: c57207c4a515d2ebf764324e042c9c950b15f1cd)
> commons-lang3-3.8-test-sources.jar
> (SHA1: 3916bf439aa10c0fa7d4b81cb2b6b880a1ad78e8)
> commons-lang3-3.8.pom
> (SHA1: e536d0d78a5e3d3f0b297d221c3304b134483d7d)
> commons-lang3-3.8-javadoc.jar
> (SHA1: 4da9bb80271149d6199aecb592e018f72e4650fe)
> commons-lang3-3.8.jar
> (SHA1: 222fc4cf714a63f27cbdafdbd863efd0d30c8a1e)
> 
> #Release SHA-1s
> #Wed Aug 15 21:37:09 EDT 2018
> commons-lang3-3.8-test-sources-java-source=3916bf439aa10c0fa7d4b81cb2b6b880a1ad78e8
> commons-lang3-3.8-tests-test-jar=c57207c4a515d2ebf764324e042c9c950b15f1cd
> commons-lang3-3.8-src-zip=284e181b3fe3b32f1538b984bdd08189a1700dca
> commons-lang3-3.8-src-tar.gz=bb2e1631483cad0287b9751a5d6cfd2241c1abc2
> commons-lang3-3.8-bin-zip=15ca9898683ec3e21af1f0806366099aa2628644
> commons-lang3-3.8-bin-tar.gz=cdf6ecbc93355be416875aba51010b8bc51d9352
> commons-lang3-3.8-javadoc-javadoc=4da9bb80271149d6199aecb592e018f72e4650fe
> commons-lang3-3.8-sources-java-source=546b07aafba4fe00a514627bfb854ffc0c23406a
> 
> #Release SHA-256s
> #Wed Aug 15 21:37:09 EDT 2018
> commons-lang3-3.8-test-sources-java-source=1d5520746e1a49d259eed468bb90e4b2469bc5a358dedcd3932ff8078ecb189d
> commons-lang3-3.8-tests-test-jar=30490d1099ec915f276489383e93ea23bd906400a8598487496abe46b368f5de
> commons-lang3-3.8-src-zip=38dc4b78ea9e6ee5b8348357be29eaa938bfb550e7daea83f3b8eac3e642be4f
> commons-lang3-3.8-src-tar.gz=600dcd0bfe1b5afc52be0c66962611f3e91d3b8042deb3ae276ca6fe2b717378
> commons-lang3-3.8-bin-zip=c008a7a278cedf8db065b3664435cb9dc8aaeed52aeb60581563f460d7dd79ae
> commons-lang3-3.8-bin-tar.gz=70c659a90805cec1f546ebe812e571d00f8ca5b3fcd968c7149df6f6b740193e
> commons-lang3-3.8-javadoc-javadoc=95dea8706a65eae013ad58aba3731568092c6624e8b17ead6726bae91dbdf558
> commons-lang3-3.8-sources-java-source=4be2bb042cee507fe8f3d93b15cf4f5d7bc6c69c41dc48df303c7ebe5fe8a8eb
> 
> 
> 
> I have tested this with 'mvn clean install site' using: 
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 
> 2018-06-17T14:33:14-04:00)
> Maven home: /usr/local/Cellar/maven/3.5.4/libexec
> Java version: 1.8.0_172, vendor: Oracle Corporation, runtime: 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_172.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac"
> 
> Details of changes since 3.7 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/lang/3.8-RC1/RELEASE-NOTES.txt
> 
> https://dist.apache.org/repos/dist/dev/commons/lang/3.8-RC1/site/changes-report.html
> 
> Site:
> 
> https://dist.apache.org/repos/dist/dev/commons/lang/3.8-RC1/site/index.html
> (note some *relative* links are broken and the 3.8 directories are not 
> yet created - these will be OK once the site is deployed.)
> 
> CLIRR Report (compared to 3.7):
> 
> https://dist.apache.org/repos/dist/dev/commons/lang/3.8-RC1/site/clirr-report.html
> 
> JApiCmp Report (compared to 3.7):
> 
> https://dist.apache.org/repos/dist/dev/commons/lang/3.8-RC1/site/japicmp.html
> 
> RAT Report:
> 
> https://dist.apache.org/repos/dist/dev/commons/lang/3.8-RC1/site/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.
> 
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
> 
> Thank you,
> 
> Rob Tompkins, 
> Release Manager (using key B6E73D84EA4FCC47166087253FAAD2CD5ECBB314)
> 
> 
> -
> To unsubscribe, e-mail: 

[ANNOUNCEMENT] Commons Configuration 2.3 Released

[Oliver Heger]

The Apache Commons Team is pleased to announce the availability of
Apache Commons Configuration 2.3.

The Apache Commons Configuration software library provides a generic
configuration interface which enables an application to read
configuration data from a variety of sources.

Version 2.3 is another maintenance release for the Configuration 2.x
series. It contains bug fixes and also a few new features like support
for File and Path as data types. The release is fully source and binary
compatible with version 2.2.

A full list of all changes can be found in the release notes at
  http://www.apache.org/dist/commons/configuration/RELEASE-NOTES.txt

A user's guide describing all the features of Configuration 2.x can be
found at
  http://commons.apache.org/configuration/userguide/user_guide.html

Source and binary distributions are available for download from the
Apache Commons download site:

http://commons.apache.org/proper/commons-configuration/download_configuration.cgi

Please verify signatures using the KEYS file available at the above
location when downloading the release.

For complete information on Commons Configuration, including
instructions on how to submit bug reports, patches, or suggestions for
improvement, see the Apache Commons Configuration website:

http://commons.apache.org/proper/commons-configuration/

Oliver Heger, on behalf of the Apache Commons community



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

[RESULT][VOTE] Release Apache Commons Configuration 2.3 based on RC2

[Oliver Heger]

The vote to release Apache Commons Configuration 2.3 based on RC2 passed
with the following votes (all are binding):

Gary Gregory:   +1
Rob Tompkins:   +1
Oliver Heger:   +1

Thanks to all reviewers. I will start with the tasks to publish the
release probably tomorrow.

Oliver

Am 04.08.2018 um 21:19 schrieb Oliver Heger:
> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons Configuration 2.2 was released, so I would like to
> release Apache Commons Configuration 2.3.
> 
> Apache Commons Configuration 2.3 RC2 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/configuration/2.3-RC2
> (svn revision 28561)
> 
> The Subversion tag for this RC is here:
> 
> http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_2_3_RC2/
> (svn revision 1837444)
> N.B. the SVN revision is required because SVN tags are not immutable.
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1364/org/apache/commons/commons-configuration2/2.3/
> 
> These are the Maven artifacts and their hashes in Nexus:
> 
> #Release SHA-1s
> #Sat Aug 04 20:56:59 CEST 2018
> commons-configuration2-2.3-javadoc-javadoc=4961b7145db35f265155745b16b8094bb925708f
> commons-configuration2-2.3-test-sources-java-source=eb9f99be11bf577ea1335619d419e8ffdd32c2e7
> commons-configuration2-2.3-jar.asc=bd1d32e94fc0efe7dfca510eab9abd3e1e05776f
> commons-configuration2-2.3-bin-tar.gz.asc=d109f5885d9d11b52580d2248bdc4c2ed14a55cf
> commons-configuration2-2.3-bin-zip.asc=abc6a26bc0e489284a9cf361ed191a4aa2862a03
> commons-configuration2-2.3-sources-java-source=575d3e2fcf17ab103fc3206d90f61814e8b6668b
> commons-configuration2-2.3-test-sources-jar.asc=0f15ec717bb94682cf9f6e776196b7f8b17bef1f
> commons-configuration2-2.3-sources-jar.asc=0a27a6ebb6daf6c46ab030a727b843560166c4be
> commons-configuration2-2.3-src-tar.gz.asc=b1688c590fe5bd86aca830e6bb9c4ad19c30a12b
> commons-configuration2-2.3-src-zip=0d86da2d889aa8df62e1ae4cc877232c2cd7b580
> commons-configuration2-2.3-tests-test-jar=43e201891a2323ead5d776d3287ecdd0c4d6b46d
> commons-configuration2-2.3-bin-zip=8a3a3497cd16e700544849d5c7b67afe1f935a3a
> commons-configuration2-2.3-src-zip.asc=c3d4e55be6759d847f15935fd5df73c423cf36ff
> commons-configuration2-2.3-tests-jar.asc=3eca0e7a77ab2906ae54220467398352c055b5de
> commons-configuration2-2.3-src-tar.gz=c8d0d6ed08cef777fb477f06d6b062c3325e4eec
> commons-configuration2-2.3-javadoc-jar.asc=15603f713ad761043421dac81969fbf9dcbf53b5
> commons-configuration2-2.3-pom.asc=327613c4c2f1a590c763f0007f0b165c6fbff62a
> commons-configuration2-2.3-bin-tar.gz=fdcf25d427601ad4b486a8fc0dfd252b9a81c2b2
> 
> #Release SHA-256s
> #Sat Aug 04 20:56:59 CEST 2018
> commons-configuration2-2.3-javadoc-javadoc=91026295092ec7dc3e2f85772231a324a311794321b169828b64ebbbdba78e0a
> commons-configuration2-2.3-test-sources-java-source=73f2a6b5f3ed922b8574604e066994a5a2f6125fd6e87ab4fe0b947a305776b7
> commons-configuration2-2.3-jar.asc=e559b26077dc066b15b44db114903bfb158992147a2022c466f4169ae5b7340e
> commons-configuration2-2.3-bin-tar.gz.asc=d7107eb40d0c9490377803335413a0284f180a2be0a475f69cf3affc9d6a2437
> commons-configuration2-2.3-bin-zip.asc=fb363dac48a827265c5b1e36a1434e74de48bf1f121a10be840f8434d5dc8cad
> commons-configuration2-2.3-sources-java-source=29f8fc6240365cb58c452b7956d62a7cee6d572d38ed8fc3698266ed5c97b9f2
> commons-configuration2-2.3-test-sources-jar.asc=bbd10fe4d7060637b71af2ad334c89b794ca2b93b955e18010400443834af625
> commons-configuration2-2.3-sources-jar.asc=7752e29a1d65115ffb8194aedcc12e3b1af79c5d31823eac0ff64f88579a8f58
> commons-configuration2-2.3-src-tar.gz.asc=74c09077856935a0296a506121220411129a8d01d879a77042e9d8915ab62645
> commons-configuration2-2.3-src-zip=c71efdc6f9037c216f1658703a0a3a785f75e2ce2cd9b99653949094e234d604
> commons-configuration2-2.3-tests-test-jar=b4ff650ba91676c3b470e6711c9289fa6beeabb6b6583fdfc42754f4d9457f2a
> commons-configuration2-2.3-bin-zip=db3dce5f4856091d33c7d704f2d179e8b6ad1ca06eddf19f26c7ee6e42d661e4
> commons-configuration2-2.3-src-zip.asc=b2a234015fb4f4ec8da838fcd53071ec3a6d901ac68952c64f71843ac0241ddf
> commons-configuration2-2.3-tests-jar.asc=baf299277a6ffdbaabd26405a7af9df4e277f36f1610650bc4bd5fed55484195
> commons-configuration2-2.3-src-tar.gz=75db3a4337920aca70cd50fae149a5c7fc8f3cf7b9b7b59002b65c4f66ce8d1a
> commons-configuration2-2.3-javadoc-jar.asc=72c7e9cf531f3487d1d85b9aee08c09e16e18ed923324423815d6c0acefa
> commons-configuration2-2.3-pom.asc=10be2d8c6dff95a6d58343e6e64e2dc68f5810517280f26871bf3005fa969d0a
> commons-configuration2-2.3-bin-tar.gz=0c84f5aa8fbbad79595076fc3d8af33355632a2c1ec9b5ab30b6b8e8fa5f6321
> 
> 
> (no need for .asc hashes!)
> 
> I have tested this with ***'mvn clean install sit

Re: [VOTE] Release Apache Commons Configuration 2.3 based on RC2

[Oliver Heger]

+1

Oliver

Am 04.08.2018 um 21:19 schrieb Oliver Heger:
> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons Configuration 2.2 was released, so I would like to
> release Apache Commons Configuration 2.3.
> 
> Apache Commons Configuration 2.3 RC2 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/configuration/2.3-RC2
> (svn revision 28561)
> 
> The Subversion tag for this RC is here:
> 
> http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_2_3_RC2/
> (svn revision 1837444)
> N.B. the SVN revision is required because SVN tags are not immutable.
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1364/org/apache/commons/commons-configuration2/2.3/
> 
> These are the Maven artifacts and their hashes in Nexus:
> 
> #Release SHA-1s
> #Sat Aug 04 20:56:59 CEST 2018
> commons-configuration2-2.3-javadoc-javadoc=4961b7145db35f265155745b16b8094bb925708f
> commons-configuration2-2.3-test-sources-java-source=eb9f99be11bf577ea1335619d419e8ffdd32c2e7
> commons-configuration2-2.3-jar.asc=bd1d32e94fc0efe7dfca510eab9abd3e1e05776f
> commons-configuration2-2.3-bin-tar.gz.asc=d109f5885d9d11b52580d2248bdc4c2ed14a55cf
> commons-configuration2-2.3-bin-zip.asc=abc6a26bc0e489284a9cf361ed191a4aa2862a03
> commons-configuration2-2.3-sources-java-source=575d3e2fcf17ab103fc3206d90f61814e8b6668b
> commons-configuration2-2.3-test-sources-jar.asc=0f15ec717bb94682cf9f6e776196b7f8b17bef1f
> commons-configuration2-2.3-sources-jar.asc=0a27a6ebb6daf6c46ab030a727b843560166c4be
> commons-configuration2-2.3-src-tar.gz.asc=b1688c590fe5bd86aca830e6bb9c4ad19c30a12b
> commons-configuration2-2.3-src-zip=0d86da2d889aa8df62e1ae4cc877232c2cd7b580
> commons-configuration2-2.3-tests-test-jar=43e201891a2323ead5d776d3287ecdd0c4d6b46d
> commons-configuration2-2.3-bin-zip=8a3a3497cd16e700544849d5c7b67afe1f935a3a
> commons-configuration2-2.3-src-zip.asc=c3d4e55be6759d847f15935fd5df73c423cf36ff
> commons-configuration2-2.3-tests-jar.asc=3eca0e7a77ab2906ae54220467398352c055b5de
> commons-configuration2-2.3-src-tar.gz=c8d0d6ed08cef777fb477f06d6b062c3325e4eec
> commons-configuration2-2.3-javadoc-jar.asc=15603f713ad761043421dac81969fbf9dcbf53b5
> commons-configuration2-2.3-pom.asc=327613c4c2f1a590c763f0007f0b165c6fbff62a
> commons-configuration2-2.3-bin-tar.gz=fdcf25d427601ad4b486a8fc0dfd252b9a81c2b2
> 
> #Release SHA-256s
> #Sat Aug 04 20:56:59 CEST 2018
> commons-configuration2-2.3-javadoc-javadoc=91026295092ec7dc3e2f85772231a324a311794321b169828b64ebbbdba78e0a
> commons-configuration2-2.3-test-sources-java-source=73f2a6b5f3ed922b8574604e066994a5a2f6125fd6e87ab4fe0b947a305776b7
> commons-configuration2-2.3-jar.asc=e559b26077dc066b15b44db114903bfb158992147a2022c466f4169ae5b7340e
> commons-configuration2-2.3-bin-tar.gz.asc=d7107eb40d0c9490377803335413a0284f180a2be0a475f69cf3affc9d6a2437
> commons-configuration2-2.3-bin-zip.asc=fb363dac48a827265c5b1e36a1434e74de48bf1f121a10be840f8434d5dc8cad
> commons-configuration2-2.3-sources-java-source=29f8fc6240365cb58c452b7956d62a7cee6d572d38ed8fc3698266ed5c97b9f2
> commons-configuration2-2.3-test-sources-jar.asc=bbd10fe4d7060637b71af2ad334c89b794ca2b93b955e18010400443834af625
> commons-configuration2-2.3-sources-jar.asc=7752e29a1d65115ffb8194aedcc12e3b1af79c5d31823eac0ff64f88579a8f58
> commons-configuration2-2.3-src-tar.gz.asc=74c09077856935a0296a506121220411129a8d01d879a77042e9d8915ab62645
> commons-configuration2-2.3-src-zip=c71efdc6f9037c216f1658703a0a3a785f75e2ce2cd9b99653949094e234d604
> commons-configuration2-2.3-tests-test-jar=b4ff650ba91676c3b470e6711c9289fa6beeabb6b6583fdfc42754f4d9457f2a
> commons-configuration2-2.3-bin-zip=db3dce5f4856091d33c7d704f2d179e8b6ad1ca06eddf19f26c7ee6e42d661e4
> commons-configuration2-2.3-src-zip.asc=b2a234015fb4f4ec8da838fcd53071ec3a6d901ac68952c64f71843ac0241ddf
> commons-configuration2-2.3-tests-jar.asc=baf299277a6ffdbaabd26405a7af9df4e277f36f1610650bc4bd5fed55484195
> commons-configuration2-2.3-src-tar.gz=75db3a4337920aca70cd50fae149a5c7fc8f3cf7b9b7b59002b65c4f66ce8d1a
> commons-configuration2-2.3-javadoc-jar.asc=72c7e9cf531f3487d1d85b9aee08c09e16e18ed923324423815d6c0acefa
> commons-configuration2-2.3-pom.asc=10be2d8c6dff95a6d58343e6e64e2dc68f5810517280f26871bf3005fa969d0a
> commons-configuration2-2.3-bin-tar.gz=0c84f5aa8fbbad79595076fc3d8af33355632a2c1ec9b5ab30b6b8e8fa5f6321
> 
> 
> (no need for .asc hashes!)
> 
> I have tested this with ***'mvn clean install site'*** using:
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
> 2018-06-17T20:33:14+02:00)
> Maven home: C:\data\dev\tools\apache-maven-3.5.4
> Java version: 1.8.0_172, vendor: Oracle Corporation, runtime: C:\Program
> Files\Java\

[VOTE] Release Apache Commons Configuration 2.3 based on RC2

[Oliver Heger]

We have fixed quite a few bugs and added some significant enhancements
since Apache Commons Configuration 2.2 was released, so I would like to
release Apache Commons Configuration 2.3.

Apache Commons Configuration 2.3 RC2 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/configuration/2.3-RC2
(svn revision 28561)

The Subversion tag for this RC is here:

http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_2_3_RC2/
(svn revision 1837444)
N.B. the SVN revision is required because SVN tags are not immutable.

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1364/org/apache/commons/commons-configuration2/2.3/

These are the Maven artifacts and their hashes in Nexus:

#Release SHA-1s
#Sat Aug 04 20:56:59 CEST 2018
commons-configuration2-2.3-javadoc-javadoc=4961b7145db35f265155745b16b8094bb925708f
commons-configuration2-2.3-test-sources-java-source=eb9f99be11bf577ea1335619d419e8ffdd32c2e7
commons-configuration2-2.3-jar.asc=bd1d32e94fc0efe7dfca510eab9abd3e1e05776f
commons-configuration2-2.3-bin-tar.gz.asc=d109f5885d9d11b52580d2248bdc4c2ed14a55cf
commons-configuration2-2.3-bin-zip.asc=abc6a26bc0e489284a9cf361ed191a4aa2862a03
commons-configuration2-2.3-sources-java-source=575d3e2fcf17ab103fc3206d90f61814e8b6668b
commons-configuration2-2.3-test-sources-jar.asc=0f15ec717bb94682cf9f6e776196b7f8b17bef1f
commons-configuration2-2.3-sources-jar.asc=0a27a6ebb6daf6c46ab030a727b843560166c4be
commons-configuration2-2.3-src-tar.gz.asc=b1688c590fe5bd86aca830e6bb9c4ad19c30a12b
commons-configuration2-2.3-src-zip=0d86da2d889aa8df62e1ae4cc877232c2cd7b580
commons-configuration2-2.3-tests-test-jar=43e201891a2323ead5d776d3287ecdd0c4d6b46d
commons-configuration2-2.3-bin-zip=8a3a3497cd16e700544849d5c7b67afe1f935a3a
commons-configuration2-2.3-src-zip.asc=c3d4e55be6759d847f15935fd5df73c423cf36ff
commons-configuration2-2.3-tests-jar.asc=3eca0e7a77ab2906ae54220467398352c055b5de
commons-configuration2-2.3-src-tar.gz=c8d0d6ed08cef777fb477f06d6b062c3325e4eec
commons-configuration2-2.3-javadoc-jar.asc=15603f713ad761043421dac81969fbf9dcbf53b5
commons-configuration2-2.3-pom.asc=327613c4c2f1a590c763f0007f0b165c6fbff62a
commons-configuration2-2.3-bin-tar.gz=fdcf25d427601ad4b486a8fc0dfd252b9a81c2b2

#Release SHA-256s
#Sat Aug 04 20:56:59 CEST 2018
commons-configuration2-2.3-javadoc-javadoc=91026295092ec7dc3e2f85772231a324a311794321b169828b64ebbbdba78e0a
commons-configuration2-2.3-test-sources-java-source=73f2a6b5f3ed922b8574604e066994a5a2f6125fd6e87ab4fe0b947a305776b7
commons-configuration2-2.3-jar.asc=e559b26077dc066b15b44db114903bfb158992147a2022c466f4169ae5b7340e
commons-configuration2-2.3-bin-tar.gz.asc=d7107eb40d0c9490377803335413a0284f180a2be0a475f69cf3affc9d6a2437
commons-configuration2-2.3-bin-zip.asc=fb363dac48a827265c5b1e36a1434e74de48bf1f121a10be840f8434d5dc8cad
commons-configuration2-2.3-sources-java-source=29f8fc6240365cb58c452b7956d62a7cee6d572d38ed8fc3698266ed5c97b9f2
commons-configuration2-2.3-test-sources-jar.asc=bbd10fe4d7060637b71af2ad334c89b794ca2b93b955e18010400443834af625
commons-configuration2-2.3-sources-jar.asc=7752e29a1d65115ffb8194aedcc12e3b1af79c5d31823eac0ff64f88579a8f58
commons-configuration2-2.3-src-tar.gz.asc=74c09077856935a0296a506121220411129a8d01d879a77042e9d8915ab62645
commons-configuration2-2.3-src-zip=c71efdc6f9037c216f1658703a0a3a785f75e2ce2cd9b99653949094e234d604
commons-configuration2-2.3-tests-test-jar=b4ff650ba91676c3b470e6711c9289fa6beeabb6b6583fdfc42754f4d9457f2a
commons-configuration2-2.3-bin-zip=db3dce5f4856091d33c7d704f2d179e8b6ad1ca06eddf19f26c7ee6e42d661e4
commons-configuration2-2.3-src-zip.asc=b2a234015fb4f4ec8da838fcd53071ec3a6d901ac68952c64f71843ac0241ddf
commons-configuration2-2.3-tests-jar.asc=baf299277a6ffdbaabd26405a7af9df4e277f36f1610650bc4bd5fed55484195
commons-configuration2-2.3-src-tar.gz=75db3a4337920aca70cd50fae149a5c7fc8f3cf7b9b7b59002b65c4f66ce8d1a
commons-configuration2-2.3-javadoc-jar.asc=72c7e9cf531f3487d1d85b9aee08c09e16e18ed923324423815d6c0acefa
commons-configuration2-2.3-pom.asc=10be2d8c6dff95a6d58343e6e64e2dc68f5810517280f26871bf3005fa969d0a
commons-configuration2-2.3-bin-tar.gz=0c84f5aa8fbbad79595076fc3d8af33355632a2c1ec9b5ab30b6b8e8fa5f6321


(no need for .asc hashes!)

I have tested this with ***'mvn clean install site'*** using:
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
2018-06-17T20:33:14+02:00)
Maven home: C:\data\dev\tools\apache-maven-3.5.4
Java version: 1.8.0_172, vendor: Oracle Corporation, runtime: C:\Program
Files\Java\jdk1.8.0_172\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Details of changes since 2.2 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/configuration/2.3-RC2/RELEASE-NOTES.txt

https://dist.apache.org/repos/dist/dev/commons/configuration/2.3-RC2/site/changes-report.html

Site:

Re: [RELEASE] Question about download page

[Oliver Heger]

Hi Gary,

Am 03.08.2018 um 18:08 schrieb Gary Gregory:
> Hi Oliver,
> 
> The old MD5 files should be gone from our dist release server and replaced
> by SHA files. I did that a month or two ago. So download pages need to be
> adjusted to point to the SHA files only.

thanks for the quick reply.

Just checked that a click on the md5 file on [lang]'s download page
gives me a 404.

But for newly released components the download pages generated
automatically will then be correct.

Regards
Oliver

> 
> Gary
> 
> On Fri, Aug 3, 2018 at 10:01 AM Oliver Heger 
> wrote:
> 
>> Hi all,
>>
>> one question regarding release preparation:
>>
>> Download pages now link to sha checksums rather than outdated md5
>> hashes. Thus, the commons-build plugin generates the corresponding links.
>>
>> There are some components, however, that list multiple versions on their
>> download pages, e.g. the new 2.x version and an older 1.x version. For
>> the newly released version the sha checksum should be generated
>> automatically.
>>
>> How is this done for the old version? Are manual steps required to
>> generate it? Or should the link to the checksum continue to reference
>> the md5 file?
>>
>> Thanks
>> Oliver
>>
>> -
>> 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

[RELEASE] Question about download page

[Oliver Heger]

Hi all,

one question regarding release preparation:

Download pages now link to sha checksums rather than outdated md5
hashes. Thus, the commons-build plugin generates the corresponding links.

There are some components, however, that list multiple versions on their
download pages, e.g. the new 2.x version and an older 1.x version. For
the newly released version the sha checksum should be generated
automatically.

How is this done for the old version? Are manual steps required to
generate it? Or should the link to the checksum continue to reference
the md5 file?

Thanks
Oliver

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

[CANCEL][VOTE] Release Apache Commons Configuration 2.3 based on RC1

[Oliver Heger]

This vote is cancelled because of problems with the RAT report.

Thanks for all reviews.

Oliver

Am 28.07.2018 um 22:38 schrieb Oliver Heger:
> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons Configuration 2.2 was released, so I would like to
> release Apache Commons Configuration 2.3.
> 
> Apache Commons Configuration 2.3 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/configuration/2.3-RC1
> (svn revision 28408)
> 
> The Subversion tag for this RC is here:
> 
> http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_2_3_RC1/
> (svn revision 1836945)
> N.B. the SVN revision is required because SVN tags are not immutable.
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1359/org/apache/commons/commons-configuration2/2.3/
> 
> These are the Maven artifacts and their hashes in Nexus:
> 
> #Release SHA-1s
> #Sat Jul 28 21:39:45 CEST 2018
> commons-configuration2-2.3-javadoc-javadoc=39271069902b856f39aaab2feb67fe5c747918e2
> commons-configuration2-2.3-test-sources-java-source=a24a39532a443675d66f660ca6f36240bdde5f08
> commons-configuration2-2.3-jar.asc=830e60da68e4e55d0d9f90fbc89d7b43d91234b1
> commons-configuration2-2.3-bin-tar.gz.asc=3a0133fa3ac1461c0ccc7247090024951946b9fd
> commons-configuration2-2.3-bin-zip.asc=fef5041fd94e19bacb85f38f19718650b157971f
> commons-configuration2-2.3-sources-java-source=3f1eb983c8e8fb14fa4beef7b007886b75fc17e7
> commons-configuration2-2.3-test-sources-jar.asc=29678f2e18b7dadd00f8be550093e96896fc15ee
> commons-configuration2-2.3-sources-jar.asc=99951b89187ed154482bcb61879c83b868624e25
> commons-configuration2-2.3-src-tar.gz.asc=a66c4810bbc31edcc975a553999c3a6a40d96089
> commons-configuration2-2.3-src-zip=a8a1dd83c98bed2933736e3b37b9e1028a649ec7
> commons-configuration2-2.3-tests-test-jar=63dc740e7bd7495cedd34224525d90c1bcdbd56e
> commons-configuration2-2.3-bin-zip=086b2195b31e871b5102d9a29882bd7d4c44aa0c
> commons-configuration2-2.3-src-zip.asc=416cffc6aec9173f2fc30665ee78b46ae8c23ee3
> commons-configuration2-2.3-tests-jar.asc=5a80150876658784b2711521c6496270f6c76b9d
> commons-configuration2-2.3-src-tar.gz=7f7f4219c1783c66236c144845150d7d1fcfa80a
> commons-configuration2-2.3-javadoc-jar.asc=be4a78a18a0e347dd7ada170ffa09a2111fbd4c7
> commons-configuration2-2.3-pom.asc=f6a8007fe0f7d74fdcee98e9e465e5ebc3c32e51
> commons-configuration2-2.3-bin-tar.gz=c51eab5074927576b7397c32dd4c78ca969b26ea
> 
> #Release SHA-256s
> #Sat Jul 28 21:39:45 CEST 2018
> commons-configuration2-2.3-javadoc-javadoc=3ad123d2a3f09f8e59ce157bd5e3aad7664f3524a3a8be01905f6b769bdc5b09
> commons-configuration2-2.3-test-sources-java-source=695d9f975bb02a3c2317560cff4980a0ae22c3c7c83bb2183066273a7b452c18
> commons-configuration2-2.3-jar.asc=b2f8d71b0005611ff90725de351cb59d74b885ed4be2c835c10fd4b9964fb6b4
> commons-configuration2-2.3-bin-tar.gz.asc=9dc01e19c967a0f633a9ca072843aabfa14ae0bdb13581ab627c8861ae94a865
> commons-configuration2-2.3-bin-zip.asc=6e94b7274866b3494eeda81cb2b602fb6e4c94f918145fccbeb6fdfc39fc4dac
> commons-configuration2-2.3-sources-java-source=73f20c446fd082655b130e515ab06f1cc1eb4ba3a3e9db463b55a4fe82bc941f
> commons-configuration2-2.3-test-sources-jar.asc=007d3c1712a8a5ce7da56fd387422dab180b3ec49437b8ae0835e61a638d2965
> commons-configuration2-2.3-sources-jar.asc=8015460d832424b5127bb798a88c814afbe48a471c86abe67099c2d06ea5
> commons-configuration2-2.3-src-tar.gz.asc=51ab6a928377810be85df3f14ed0ac5d50f1ab7f9ee6d71a8871a526f94645ab
> commons-configuration2-2.3-src-zip=232608f64a1eee7ff3f00fbb65005fce00fa7dc20065d1227585adea93c2e734
> commons-configuration2-2.3-tests-test-jar=07954d825f11fd9b006a2a6c4fa8e3558fc919208e52e7be01e96a6e60a5f51e
> commons-configuration2-2.3-bin-zip=f2d5e53e1ed86acac8cca3de6986c79bbb3c227f174804c83cb43ad3f365d54e
> commons-configuration2-2.3-src-zip.asc=889482ee837b06ffb7d3bc3d4a789691f2e5250816b6a526acf649915d04a1b3
> commons-configuration2-2.3-tests-jar.asc=ca25085acf2234f590bcedcdd4dd06576e0b476a60fba28d9a9af9771301c496
> commons-configuration2-2.3-src-tar.gz=f963ce5cf9eaaec22353d8a9d72a6d491f85442f6280fe27b3cda9d8ab083af5
> commons-configuration2-2.3-javadoc-jar.asc=f6a19adb4bb5c087394d5071e4e715c81b56c9d744e6e3473fa87f443d0ec650
> commons-configuration2-2.3-pom.asc=1321aaab060b97bedc1d1d027d77ac30329d69cf53a7dd949594ef5a7e22d904
> commons-configuration2-2.3-bin-tar.gz=bd74b0d47721478d55fceab0881a4788626f76863b45792ec8816f19d0e94db0
> 
> 
> (no need for .asc hashes!)
> 
> I have tested this with ***'mvn clean install site'*** using:
> 
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
> 2018-06-17T20:33:14+02:00)
> Maven home: C:\data\dev\tools\apache-maven-3.5.4
> Java

Re: [VOTE] Release Apache Commons Configuration 2.3 based on RC1

[Oliver Heger]

Am 31.07.2018 um 04:21 schrieb Gary Gregory:
> On Mon, Jul 30, 2018 at 1:29 PM Oliver Heger 
> wrote:
> 
>> Hi Gary,
>>
>> Am 30.07.2018 um 16:25 schrieb Gary Gregory:
>>> -1
>>>
>>> :-( RAT check fails:
>>> - Unzip src zip & run 'mvn apache-rat:check'
>>>
>>> I know it might be trivial but this kind of check must pass IMO to give
>> us
>>> and users confidence that we are on solid ground WRT licenses.
>>
>> this is very strange. When building the site the RAT report is clean
>> (also in the referenced site).
>>
> 
> This is because the RAT check is _only_ configured in the POM's reporting
> section. I added the RAT check to the build section in trunk so that 'mvn
> apache-rat:check' passes.

Thanks for fixing.

> 
> The files affected are not new and are contained in the code-base since
>> multiple releases. They actually do not contain license headers (AFAIK
>> comments are not even supported by JSON). Therefore, they have been
>> excluded from the RAT report (lines 801-802 in pom.xml). Obviously, this
>> is not effective when invoking the plugin directly. Any idea how to fix
>> this?
>>
>> As the site build is not affected, and the solution will probably be
>> adding another exclude somewhere, do you consider this blocking for the
>> release?
>>
> 
> I would like to see another RC to pick up the change to trunk I just made
> and a couple of items below. Overall, the rest of my local build is fine
> but this should be addressed:
> 
> In changes.xml and changes-report.html, the 2.3 release date says "In SVN",
> it should be the date of the RC.
I used to update the date with the correct release date when deploying
the site. But be it.

> 
> Another hiccup are these easy fixes from Checkstyle:
> 
> [INFO] --- maven-checkstyle-plugin:2.15:check (default) @
> commons-configuration2 ---
> [INFO] There are 7 errors reported by Checkstyle 6.1.1 with
> C:\vcs\svn\apache\commons\trunks-proper\configuration/conf/checkstyle.xml
> ruleset.
> [ERROR]
> src\main\java\org\apache\commons\configuration2\AbstractYAMLBasedConfiguration.java[0]
> (misc) NewlineAtEndOfFile: File does not end with a newline.
> [ERROR]
> src\main\java\org\apache\commons\configuration2\builder\fluent\INIBuilderParameters.java[0]
> (misc) NewlineAtEndOfFile: File does not end with a newline.
> [ERROR]
> src\main\java\org\apache\commons\configuration2\builder\INIBuilderParametersImpl.java[0]
> (misc) NewlineAtEndOfFile: File does not end with a newline.
> [ERROR]
> src\main\java\org\apache\commons\configuration2\builder\INIBuilderProperties.java[0]
> (misc) NewlineAtEndOfFile: File does not end with a newline.
> [ERROR]
> src\main\java\org\apache\commons\configuration2\JSONConfiguration.java[0]
> (misc) NewlineAtEndOfFile: File does not end with a newline.
> [ERROR]
> src\main\java\org\apache\commons\configuration2\XMLListReference.java[0]
> (misc) NewlineAtEndOfFile: File does not end with a newline.
> [ERROR]
> src\main\java\org\apache\commons\configuration2\YAMLConfiguration.java[0]
> (misc) NewlineAtEndOfFile: File does not end with a newline.
These warnings are another mystery to me. When preparing the RC I fixed
all checkstyle warnings, and a site build on trunk actually gives me a
clean checkstyle report. So the line-ending issues seem to have got in
when tagging the RC. Also, I have no clue why just these files are
affected; the set seems to be unrelated with classes I have touched
recently.

> 
> There are lots of Javadocs warnings building with Java 8 but I am not
> worried about this for this release.
Most of them are probably caused by classes generated via JavaCC.

Okay, I will wait for the end of the vote period, and if I do not get
enough +1s, I will prepare another RC. However, it might take some days
until I come to it.

Oliver

> 
> Gary
> 
>>
>> Oliver
>>
>>>
>>> Gary
>>>
>>> *
>>>
>>> Files with unapproved licenses:
>>>
>>>   src/test/resources/test.json
>>>   src/test/resources/test.yaml
>>>
>>> On Sat, Jul 28, 2018 at 2:38 PM Oliver Heger <
>> oliver.he...@oliver-heger.de>
>>> wrote:
>>>
>>>> We have fixed quite a few bugs and added some significant enhancements
>>>> since Apache Commons Configuration 2.2 was released, so I would like to
>>>> release Apache Commons Configuration 2.3.
>>>>
>>>> Apache Commons Configuration 2.3 RC1 is available for review here:
>>>>
>> https://dist.apache.org/repos/dist/dev

Re: [VOTE] Release Apache Commons Configuration 2.3 based on RC1

[Oliver Heger]

Hi Gary,

Am 30.07.2018 um 16:25 schrieb Gary Gregory:
> -1
> 
> :-( RAT check fails:
> - Unzip src zip & run 'mvn apache-rat:check'
> 
> I know it might be trivial but this kind of check must pass IMO to give us
> and users confidence that we are on solid ground WRT licenses.

this is very strange. When building the site the RAT report is clean
(also in the referenced site).

The files affected are not new and are contained in the code-base since
multiple releases. They actually do not contain license headers (AFAIK
comments are not even supported by JSON). Therefore, they have been
excluded from the RAT report (lines 801-802 in pom.xml). Obviously, this
is not effective when invoking the plugin directly. Any idea how to fix
this?

As the site build is not affected, and the solution will probably be
adding another exclude somewhere, do you consider this blocking for the
release?

Oliver

> 
> Gary
> 
> *
> 
> Files with unapproved licenses:
> 
>   src/test/resources/test.json
>   src/test/resources/test.yaml
> 
> On Sat, Jul 28, 2018 at 2:38 PM Oliver Heger 
> wrote:
> 
>> We have fixed quite a few bugs and added some significant enhancements
>> since Apache Commons Configuration 2.2 was released, so I would like to
>> release Apache Commons Configuration 2.3.
>>
>> Apache Commons Configuration 2.3 RC1 is available for review here:
>> https://dist.apache.org/repos/dist/dev/commons/configuration/2.3-RC1
>> (svn revision 28408)
>>
>> The Subversion tag for this RC is here:
>>
>>
>> http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_2_3_RC1/
>> (svn revision 1836945)
>> N.B. the SVN revision is required because SVN tags are not immutable.
>>
>> Maven artifacts are here:
>>
>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1359/org/apache/commons/commons-configuration2/2.3/
>>
>> These are the Maven artifacts and their hashes in Nexus:
>>
>> #Release SHA-1s
>> #Sat Jul 28 21:39:45 CEST 2018
>>
>> commons-configuration2-2.3-javadoc-javadoc=39271069902b856f39aaab2feb67fe5c747918e2
>>
>> commons-configuration2-2.3-test-sources-java-source=a24a39532a443675d66f660ca6f36240bdde5f08
>> commons-configuration2-2.3-jar.asc=830e60da68e4e55d0d9f90fbc89d7b43d91234b1
>>
>> commons-configuration2-2.3-bin-tar.gz.asc=3a0133fa3ac1461c0ccc7247090024951946b9fd
>>
>> commons-configuration2-2.3-bin-zip.asc=fef5041fd94e19bacb85f38f19718650b157971f
>>
>> commons-configuration2-2.3-sources-java-source=3f1eb983c8e8fb14fa4beef7b007886b75fc17e7
>>
>> commons-configuration2-2.3-test-sources-jar.asc=29678f2e18b7dadd00f8be550093e96896fc15ee
>>
>> commons-configuration2-2.3-sources-jar.asc=99951b89187ed154482bcb61879c83b868624e25
>>
>> commons-configuration2-2.3-src-tar.gz.asc=a66c4810bbc31edcc975a553999c3a6a40d96089
>> commons-configuration2-2.3-src-zip=a8a1dd83c98bed2933736e3b37b9e1028a649ec7
>>
>> commons-configuration2-2.3-tests-test-jar=63dc740e7bd7495cedd34224525d90c1bcdbd56e
>> commons-configuration2-2.3-bin-zip=086b2195b31e871b5102d9a29882bd7d4c44aa0c
>>
>> commons-configuration2-2.3-src-zip.asc=416cffc6aec9173f2fc30665ee78b46ae8c23ee3
>>
>> commons-configuration2-2.3-tests-jar.asc=5a80150876658784b2711521c6496270f6c76b9d
>>
>> commons-configuration2-2.3-src-tar.gz=7f7f4219c1783c66236c144845150d7d1fcfa80a
>>
>> commons-configuration2-2.3-javadoc-jar.asc=be4a78a18a0e347dd7ada170ffa09a2111fbd4c7
>> commons-configuration2-2.3-pom.asc=f6a8007fe0f7d74fdcee98e9e465e5ebc3c32e51
>>
>> commons-configuration2-2.3-bin-tar.gz=c51eab5074927576b7397c32dd4c78ca969b26ea
>>
>> #Release SHA-256s
>> #Sat Jul 28 21:39:45 CEST 2018
>>
>> commons-configuration2-2.3-javadoc-javadoc=3ad123d2a3f09f8e59ce157bd5e3aad7664f3524a3a8be01905f6b769bdc5b09
>>
>> commons-configuration2-2.3-test-sources-java-source=695d9f975bb02a3c2317560cff4980a0ae22c3c7c83bb2183066273a7b452c18
>>
>> commons-configuration2-2.3-jar.asc=b2f8d71b0005611ff90725de351cb59d74b885ed4be2c835c10fd4b9964fb6b4
>>
>> commons-configuration2-2.3-bin-tar.gz.asc=9dc01e19c967a0f633a9ca072843aabfa14ae0bdb13581ab627c8861ae94a865
>>
>> commons-configuration2-2.3-bin-zip.asc=6e94b7274866b3494eeda81cb2b602fb6e4c94f918145fccbeb6fdfc39fc4dac
>>
>> commons-configuration2-2.3-sources-java-source=73f20c446fd082655b130e515ab06f1cc1eb4ba3a3e9db463b55a4fe82bc941f
>>
>> commons-configuration2-2.3-test-sources-jar.asc=007d3c1712a8a5ce7da56fd387422dab180b3ec49437b8ae0

[VOTE] Release Apache Commons Configuration 2.3 based on RC1

[Oliver Heger]

We have fixed quite a few bugs and added some significant enhancements
since Apache Commons Configuration 2.2 was released, so I would like to
release Apache Commons Configuration 2.3.

Apache Commons Configuration 2.3 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/configuration/2.3-RC1
(svn revision 28408)

The Subversion tag for this RC is here:

http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_2_3_RC1/
(svn revision 1836945)
N.B. the SVN revision is required because SVN tags are not immutable.

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1359/org/apache/commons/commons-configuration2/2.3/

These are the Maven artifacts and their hashes in Nexus:

#Release SHA-1s
#Sat Jul 28 21:39:45 CEST 2018
commons-configuration2-2.3-javadoc-javadoc=39271069902b856f39aaab2feb67fe5c747918e2
commons-configuration2-2.3-test-sources-java-source=a24a39532a443675d66f660ca6f36240bdde5f08
commons-configuration2-2.3-jar.asc=830e60da68e4e55d0d9f90fbc89d7b43d91234b1
commons-configuration2-2.3-bin-tar.gz.asc=3a0133fa3ac1461c0ccc7247090024951946b9fd
commons-configuration2-2.3-bin-zip.asc=fef5041fd94e19bacb85f38f19718650b157971f
commons-configuration2-2.3-sources-java-source=3f1eb983c8e8fb14fa4beef7b007886b75fc17e7
commons-configuration2-2.3-test-sources-jar.asc=29678f2e18b7dadd00f8be550093e96896fc15ee
commons-configuration2-2.3-sources-jar.asc=99951b89187ed154482bcb61879c83b868624e25
commons-configuration2-2.3-src-tar.gz.asc=a66c4810bbc31edcc975a553999c3a6a40d96089
commons-configuration2-2.3-src-zip=a8a1dd83c98bed2933736e3b37b9e1028a649ec7
commons-configuration2-2.3-tests-test-jar=63dc740e7bd7495cedd34224525d90c1bcdbd56e
commons-configuration2-2.3-bin-zip=086b2195b31e871b5102d9a29882bd7d4c44aa0c
commons-configuration2-2.3-src-zip.asc=416cffc6aec9173f2fc30665ee78b46ae8c23ee3
commons-configuration2-2.3-tests-jar.asc=5a80150876658784b2711521c6496270f6c76b9d
commons-configuration2-2.3-src-tar.gz=7f7f4219c1783c66236c144845150d7d1fcfa80a
commons-configuration2-2.3-javadoc-jar.asc=be4a78a18a0e347dd7ada170ffa09a2111fbd4c7
commons-configuration2-2.3-pom.asc=f6a8007fe0f7d74fdcee98e9e465e5ebc3c32e51
commons-configuration2-2.3-bin-tar.gz=c51eab5074927576b7397c32dd4c78ca969b26ea

#Release SHA-256s
#Sat Jul 28 21:39:45 CEST 2018
commons-configuration2-2.3-javadoc-javadoc=3ad123d2a3f09f8e59ce157bd5e3aad7664f3524a3a8be01905f6b769bdc5b09
commons-configuration2-2.3-test-sources-java-source=695d9f975bb02a3c2317560cff4980a0ae22c3c7c83bb2183066273a7b452c18
commons-configuration2-2.3-jar.asc=b2f8d71b0005611ff90725de351cb59d74b885ed4be2c835c10fd4b9964fb6b4
commons-configuration2-2.3-bin-tar.gz.asc=9dc01e19c967a0f633a9ca072843aabfa14ae0bdb13581ab627c8861ae94a865
commons-configuration2-2.3-bin-zip.asc=6e94b7274866b3494eeda81cb2b602fb6e4c94f918145fccbeb6fdfc39fc4dac
commons-configuration2-2.3-sources-java-source=73f20c446fd082655b130e515ab06f1cc1eb4ba3a3e9db463b55a4fe82bc941f
commons-configuration2-2.3-test-sources-jar.asc=007d3c1712a8a5ce7da56fd387422dab180b3ec49437b8ae0835e61a638d2965
commons-configuration2-2.3-sources-jar.asc=8015460d832424b5127bb798a88c814afbe48a471c86abe67099c2d06ea5
commons-configuration2-2.3-src-tar.gz.asc=51ab6a928377810be85df3f14ed0ac5d50f1ab7f9ee6d71a8871a526f94645ab
commons-configuration2-2.3-src-zip=232608f64a1eee7ff3f00fbb65005fce00fa7dc20065d1227585adea93c2e734
commons-configuration2-2.3-tests-test-jar=07954d825f11fd9b006a2a6c4fa8e3558fc919208e52e7be01e96a6e60a5f51e
commons-configuration2-2.3-bin-zip=f2d5e53e1ed86acac8cca3de6986c79bbb3c227f174804c83cb43ad3f365d54e
commons-configuration2-2.3-src-zip.asc=889482ee837b06ffb7d3bc3d4a789691f2e5250816b6a526acf649915d04a1b3
commons-configuration2-2.3-tests-jar.asc=ca25085acf2234f590bcedcdd4dd06576e0b476a60fba28d9a9af9771301c496
commons-configuration2-2.3-src-tar.gz=f963ce5cf9eaaec22353d8a9d72a6d491f85442f6280fe27b3cda9d8ab083af5
commons-configuration2-2.3-javadoc-jar.asc=f6a19adb4bb5c087394d5071e4e715c81b56c9d744e6e3473fa87f443d0ec650
commons-configuration2-2.3-pom.asc=1321aaab060b97bedc1d1d027d77ac30329d69cf53a7dd949594ef5a7e22d904
commons-configuration2-2.3-bin-tar.gz=bd74b0d47721478d55fceab0881a4788626f76863b45792ec8816f19d0e94db0


(no need for .asc hashes!)

I have tested this with ***'mvn clean install site'*** using:

Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
2018-06-17T20:33:14+02:00)
Maven home: C:\data\dev\tools\apache-maven-3.5.4
Java version: 1.8.0_172, vendor: Oracle Corporation, runtime: C:\Program
Files\Java\jdk1.8.0_172\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Details of changes since 2.2 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/configuration/2.3-RC1/RELEASE-NOTES.txt

https://dist.apache.org/repos/dist/dev/commons/configuration/2.3-RC1/site/changes-report.html

Site:

Re: [RELEASE PLUGIN] Questions

[Oliver Heger]

Many thanks, this did the trick!

Oliver

Am 28.07.2018 um 20:29 schrieb Gary Gregory:
> - Make sure the dev dist folder is EMPTY before you start.
> - mvn -Dcommons.release-plugin.version=1.4-SNAPSHOT
> org.apache.commons:commons-release-plugin:1.4-SNAPSHOT:vote-txt
> 
> Gary
> 
> On Sat, Jul 28, 2018 at 9:21 AM Oliver Heger 
> wrote:
> 
>> Hi,
>>
>> for the 2.3 release of [configuration] I am trying out the cool release
>> plugin.
>>
>> Everything works fine, but I get a build failure when it adds the site
>> to SVN (see below). Do I have to prepare something in the dist area
>> before this can be done?
>>
>> And another question: How can I generate such a nice release vote mail?
>>
>> Thanks
>> Oliver
>>
>> [INFO] --- commons-release-plugin:1.3:stage-distributions
>> (stage-distributions) @ commons-configuration2 ---
>> [INFO] Preparing to stage distributions
>> [INFO] Checking out dist from:
>> scm:svn:https://dist.apache.org/repos/dist/dev/commons/configuration
>> Executing: cmd.exe /X /C "svn --username oheger --no-auth-cache
>> --non-interactive checkout
>> https://dist.apache.org/repos/dist/dev/commons/configuration
>>
>> C:\data\dev\projects\OpenSource\Apache\release\CONFIGURATION_2_3_RC1\target\commons-release-plugin\scm"
>> Working directory:
>>
>> C:\data\dev\projects\OpenSource\Apache\release\CONFIGURATION_2_3_RC1\target\commons-release-plugin
>> [INFO] Copying RELEASE-NOTES.txt to working directory.
>> Executing: cmd.exe /X /C "svn add --parents --non-recursive --targets
>> C:\Users\hacker\AppData\Local\Temp\maven-scm-4650853585445408999-targets"
>> Working directory:
>>
>> C:\data\dev\projects\OpenSource\Apache\release\CONFIGURATION_2_3_RC1\target\commons-release-plugin\scm
>> [INFO]
>> 
>> [INFO] BUILD FAILURE
>> [INFO]
>> 
>> [INFO] Total time: 09:55 min
>> [INFO] Finished at: 2018-07-28T17:14:14+02:00
>> [INFO]
>> 
>> [ERROR] Failed to execute goal
>> org.apache.commons:commons-release-plugin:1.3:stage-distributions
>> (stage-distributions) on project commons-configuration2: Failed to add
>> files to scm -> [Help 1]
>>
>> -
>> 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

[RELEASE PLUGIN] Questions

[Oliver Heger]

Hi,

for the 2.3 release of [configuration] I am trying out the cool release
plugin.

Everything works fine, but I get a build failure when it adds the site
to SVN (see below). Do I have to prepare something in the dist area
before this can be done?

And another question: How can I generate such a nice release vote mail?

Thanks
Oliver

[INFO] --- commons-release-plugin:1.3:stage-distributions
(stage-distributions) @ commons-configuration2 ---
[INFO] Preparing to stage distributions
[INFO] Checking out dist from:
scm:svn:https://dist.apache.org/repos/dist/dev/commons/configuration
Executing: cmd.exe /X /C "svn --username oheger --no-auth-cache
--non-interactive checkout
https://dist.apache.org/repos/dist/dev/commons/configuration
C:\data\dev\projects\OpenSource\Apache\release\CONFIGURATION_2_3_RC1\target\commons-release-plugin\scm"
Working directory:
C:\data\dev\projects\OpenSource\Apache\release\CONFIGURATION_2_3_RC1\target\commons-release-plugin
[INFO] Copying RELEASE-NOTES.txt to working directory.
Executing: cmd.exe /X /C "svn add --parents --non-recursive --targets
C:\Users\hacker\AppData\Local\Temp\maven-scm-4650853585445408999-targets"
Working directory:
C:\data\dev\projects\OpenSource\Apache\release\CONFIGURATION_2_3_RC1\target\commons-release-plugin\scm
[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 09:55 min
[INFO] Finished at: 2018-07-28T17:14:14+02:00
[INFO]

[ERROR] Failed to execute goal
org.apache.commons:commons-release-plugin:1.3:stage-distributions
(stage-distributions) on project commons-configuration2: Failed to add
files to scm -> [Help 1]

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

Re: svn commit: r1836755 - /commons/proper/configuration/trunk/pom.xml

[Oliver Heger]

Am 26.07.2018 um 22:30 schrieb Gary Gregory:
> Hi Oliver,
> 
> Once you've released [configuration], I expect you will bring the component
> back to Java 8, right?
Yes, this is the plan.

Oliver

> 
> Gary
> 
> On Thu, Jul 26, 2018 at 1:39 PM  wrote:
> 
>> Author: oheger
>> Date: Thu Jul 26 19:39:40 2018
>> New Revision: 1836755
>>
>> URL: http://svn.apache.org/viewvc?rev=1836755=rev
>> Log:
>> Switched back to Java 7.
>>
>> Also downgraded a test dependency that is not Java 7 compatible.
>>
>> Modified:
>> commons/proper/configuration/trunk/pom.xml
>>
>> Modified: commons/proper/configuration/trunk/pom.xml
>> URL:
>> http://svn.apache.org/viewvc/commons/proper/configuration/trunk/pom.xml?rev=1836755=1836754=1836755=diff
>>
>> ==
>> --- commons/proper/configuration/trunk/pom.xml (original)
>> +++ commons/proper/configuration/trunk/pom.xml Thu Jul 26 19:39:40 2018
>> @@ -427,7 +427,7 @@
>>  
>>org.hsqldb
>>hsqldb
>> -  2.4.1
>> +  2.3.5
>>test
>>  
>>
>> @@ -539,8 +539,8 @@
>>  RC1
>>  CONFIGURATION
>>  12310467
>> -1.8
>> -1.8
>> +1.7
>> +1.7
>>
>>  
>> https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-configuration
>> 
>>
>>
>>
>>
> 

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

Re: commons-dbcp git commit: [DBCP-517] Make defensive copies of char[] passwords.

[Oliver Heger]

Am 25.07.2018 um 23:36 schrieb Gary Gregory:
> I'd we do not already have that, the name does not need "defensive".
> Commons Collections would be where to put collections related code.

I would rather think that this copy functionality is pretty basic, so I
would put it in [lang]. I would not want to depend on [collections] just
to use one or two copy methods. And the utility class could support
non-collection types (mainly arrays) as well.

Oliver

> 
> Gary
> 
> On Wed, Jul 25, 2018, 14:00 Oliver Heger 
> wrote:
> 
>> +1, Thank you.
>>
>> I had planned to create a patch for this issue, but did not find the
>> time so far.
>>
>> BTW, I have quite often the need to create defensive copies of arrays or
>> collections in some variants (e.g. null safe, with wrapping to an
>> unmodifiable collection, etc.). Could this be an addition to [lang]? A
>> new utility class like DefensiveCopyUtils?
>>
>> Oliver
>>
>> Am 25.07.2018 um 00:34 schrieb ggreg...@apache.org:
>>> Repository: commons-dbcp
>>> Updated Branches:
>>>   refs/heads/master 70822f11d -> d7969ac93
>>>
>>>
>>> [DBCP-517] Make defensive copies of char[] passwords.
>>>
>>> Project: http://git-wip-us.apache.org/repos/asf/commons-dbcp/repo
>>> Commit:
>> http://git-wip-us.apache.org/repos/asf/commons-dbcp/commit/d7969ac9
>>> Tree: http://git-wip-us.apache.org/repos/asf/commons-dbcp/tree/d7969ac9
>>> Diff: http://git-wip-us.apache.org/repos/asf/commons-dbcp/diff/d7969ac9
>>>
>>> Branch: refs/heads/master
>>> Commit: d7969ac934e752e7a7b258fa5a5af9a563c40a13
>>> Parents: 70822f1
>>> Author: Gary Gregory 
>>> Authored: Tue Jul 24 16:34:43 2018 -0600
>>> Committer: Gary Gregory 
>>> Committed: Tue Jul 24 16:34:43 2018 -0600
>>>
>>> --
>>>  src/changes/changes.xml |  5 -
>>>  src/main/java/org/apache/commons/dbcp2/Utils.java   | 12
>> 
>>>  .../commons/dbcp2/cpdsadapter/DriverAdapterCPDS.java|  4 ++--
>>>  .../dbcp2/datasources/CPDSConnectionFactory.java| 11 ++-
>>>  .../dbcp2/cpdsadapter/TestDriverAdapterCPDS.java|  9 +
>>>  .../dbcp2/datasources/TestCPDSConnectionFactory.java| 10 ++
>>>  6 files changed, 47 insertions(+), 4 deletions(-)
>>> --
>>>
>>>
>>>
>> http://git-wip-us.apache.org/repos/asf/commons-dbcp/blob/d7969ac9/src/changes/changes.xml
>>> --
>>> diff --git a/src/changes/changes.xml b/src/changes/changes.xml
>>> index c924411..8f1de55 100644
>>> --- a/src/changes/changes.xml
>>> +++ b/src/changes/changes.xml
>>> @@ -61,9 +61,12 @@ The  type attribute can be
>> add,update,fix,remove.
>>>
>>>
>>>  
>>> -  
>>> +  
>>>  Allow DBCP to register with a
>> TransactionSynchronizationRegistry for XA cases.
>>>
>>> +  > due-to="Gary Gregory">
>>> +Make defensive copies of char[] passwords.
>>> +  
>>>  
>>>  
>>>> due-to="Gary Gregory">
>>>
>>>
>> http://git-wip-us.apache.org/repos/asf/commons-dbcp/blob/d7969ac9/src/main/java/org/apache/commons/dbcp2/Utils.java
>>> --
>>> diff --git a/src/main/java/org/apache/commons/dbcp2/Utils.java
>> b/src/main/java/org/apache/commons/dbcp2/Utils.java
>>> index 8e798c4..244b51b 100644
>>> --- a/src/main/java/org/apache/commons/dbcp2/Utils.java
>>> +++ b/src/main/java/org/apache/commons/dbcp2/Utils.java
>>> @@ -72,6 +72,17 @@ public final class Utils {
>>>  }
>>>
>>>  /**
>>> + * Clones the given char[] if not null.
>>> + *
>>> + * @param value
>>> + *may be null.
>>> + * @return a cloned char[] or null.
>>> + */
>>> +public static char[] clone(final char[] value) {
>>> +return value == null ? null : value.clone();
>>> +}
>>> +
>>> +/**
>>>   * Closes the ResultSet (which may be null).
>>>   *
>>>   * @param resultSet
>>> @@ -169,4 +180,5 @@ public fin

[configuration] Release with Java 7 compatibility

[Oliver Heger]

Hi,

the current codebase for [configuration] has been updated to require
Java 8. However, no Java 8 feature is used so far.

I would therefore like to go back to Java 7 and get a release out.
Afterwards we can switch to Java 8.

Thoughts?
Oliver

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

Re: commons-dbcp git commit: [DBCP-517] Make defensive copies of char[] passwords.

[Oliver Heger]

+1, Thank you.

I had planned to create a patch for this issue, but did not find the
time so far.

BTW, I have quite often the need to create defensive copies of arrays or
collections in some variants (e.g. null safe, with wrapping to an
unmodifiable collection, etc.). Could this be an addition to [lang]? A
new utility class like DefensiveCopyUtils?

Oliver

Am 25.07.2018 um 00:34 schrieb ggreg...@apache.org:
> Repository: commons-dbcp
> Updated Branches:
>   refs/heads/master 70822f11d -> d7969ac93
> 
> 
> [DBCP-517] Make defensive copies of char[] passwords.
> 
> Project: http://git-wip-us.apache.org/repos/asf/commons-dbcp/repo
> Commit: http://git-wip-us.apache.org/repos/asf/commons-dbcp/commit/d7969ac9
> Tree: http://git-wip-us.apache.org/repos/asf/commons-dbcp/tree/d7969ac9
> Diff: http://git-wip-us.apache.org/repos/asf/commons-dbcp/diff/d7969ac9
> 
> Branch: refs/heads/master
> Commit: d7969ac934e752e7a7b258fa5a5af9a563c40a13
> Parents: 70822f1
> Author: Gary Gregory 
> Authored: Tue Jul 24 16:34:43 2018 -0600
> Committer: Gary Gregory 
> Committed: Tue Jul 24 16:34:43 2018 -0600
> 
> --
>  src/changes/changes.xml |  5 -
>  src/main/java/org/apache/commons/dbcp2/Utils.java   | 12 
>  .../commons/dbcp2/cpdsadapter/DriverAdapterCPDS.java|  4 ++--
>  .../dbcp2/datasources/CPDSConnectionFactory.java| 11 ++-
>  .../dbcp2/cpdsadapter/TestDriverAdapterCPDS.java|  9 +
>  .../dbcp2/datasources/TestCPDSConnectionFactory.java| 10 ++
>  6 files changed, 47 insertions(+), 4 deletions(-)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/commons-dbcp/blob/d7969ac9/src/changes/changes.xml
> --
> diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> index c924411..8f1de55 100644
> --- a/src/changes/changes.xml
> +++ b/src/changes/changes.xml
> @@ -61,9 +61,12 @@ The  type attribute can be add,update,fix,remove.
>  
>
>  
> -  
> +  
>  Allow DBCP to register with a TransactionSynchronizationRegistry for 
> XA cases.
>
> +  
> +Make defensive copies of char[] passwords.
> +  
>  
>  
>
> 
> http://git-wip-us.apache.org/repos/asf/commons-dbcp/blob/d7969ac9/src/main/java/org/apache/commons/dbcp2/Utils.java
> --
> diff --git a/src/main/java/org/apache/commons/dbcp2/Utils.java 
> b/src/main/java/org/apache/commons/dbcp2/Utils.java
> index 8e798c4..244b51b 100644
> --- a/src/main/java/org/apache/commons/dbcp2/Utils.java
> +++ b/src/main/java/org/apache/commons/dbcp2/Utils.java
> @@ -72,6 +72,17 @@ public final class Utils {
>  }
>  
>  /**
> + * Clones the given char[] if not null.
> + *
> + * @param value
> + *may be null.
> + * @return a cloned char[] or null.
> + */
> +public static char[] clone(final char[] value) {
> +return value == null ? null : value.clone();
> +}
> +
> +/**
>   * Closes the ResultSet (which may be null).
>   *
>   * @param resultSet
> @@ -169,4 +180,5 @@ public final class Utils {
>  public static String toString(final char[] value) {
>  return value == null ? null : String.valueOf(value);
>  }
> +
>  }
> 
> http://git-wip-us.apache.org/repos/asf/commons-dbcp/blob/d7969ac9/src/main/java/org/apache/commons/dbcp2/cpdsadapter/DriverAdapterCPDS.java
> --
> diff --git 
> a/src/main/java/org/apache/commons/dbcp2/cpdsadapter/DriverAdapterCPDS.java 
> b/src/main/java/org/apache/commons/dbcp2/cpdsadapter/DriverAdapterCPDS.java
> index bbc8831..0844c9b 100644
> --- 
> a/src/main/java/org/apache/commons/dbcp2/cpdsadapter/DriverAdapterCPDS.java
> +++ 
> b/src/main/java/org/apache/commons/dbcp2/cpdsadapter/DriverAdapterCPDS.java
> @@ -423,8 +423,8 @@ public class DriverAdapterCPDS implements 
> ConnectionPoolDataSource, Referenceabl
>   */
>  public void setPassword(final char[] userPassword) {
>  assertInitializationAllowed();
> -this.userPassword = userPassword;
> -update(connectionProperties, KEY_PASSWORD, 
> Utils.toString(userPassword));
> +this.userPassword = Utils.clone(userPassword);
> +update(connectionProperties, KEY_PASSWORD, 
> Utils.toString(this.userPassword));
>  }
>  
>  /**
> 
> http://git-wip-us.apache.org/repos/asf/commons-dbcp/blob/d7969ac9/src/main/java/org/apache/commons/dbcp2/datasources/CPDSConnectionFactory.java
> --
> diff --git 
> a/src/main/java/org/apache/commons/dbcp2/datasources/CPDSConnectionFactory.java
>  
> 

Re: [LANG] Java 9 problems because of dependencies to java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)

[Oliver Heger]

Am 17.07.2018 um 19:11 schrieb Pascal Schumacher:
> I think we should deprecate without replacement.
> 
> There are already plenty Apache 2.0 licensed libraries offering circuit
> breaker implementations:
> 
> https://github.com/Netflix/Hystrix
> https://github.com/jhalterman/failsafe
> https://github.com/resilience4j/resilience4j

This seems to be a quite drastic solution to me. In the past we have
deprecated classes that became obsolete because replacements were added
to the JDK.

But here situation is different. The classes work as documented, and
simply deprecating them without replacement is not very user friendly.
This would pretty much contradict our long tradition of preserving
backwards compatibility as much as possible.

Oliver

> 
> Cheers,
> Pascal
> 
> Am 16.07.2018 um 23:30 schrieb Bruno P. Kinoshita:
>>> What about introducing our own state listener interface? The original
>>> interface from the beans package was used just for convenience because
>>> it already existed. But it would of course be possible to have a simple
>>> functional interface to notify listeners about state changes.
>> Hmmm, that's an option as well.
>> Looks like they had the beans interface which we used, then later we
>> had the java.util.Observable for a while, and now they are suggesting
>> users to move to the beans interface, as one of the alternatives.
>> As some Java 9 users possibly wouldn't want to import the java.beans
>> module, perhaps having this new interface could be an interesting
>> alternative.
>> I believe we would have to
>> [ ] decide whether to introduce an interface similar to
>> PropertyListener, or to Observable[ ] if the backward compatibility
>> changed, we must deprecate the existing classes
>> [ ] release a new version of lang with this new interface and the
>> updated circuit breakers[ ] and either delete the deprecated classes
>> or leave it until for some more releases
>> I wonder what others think about this option?
>>
>> Cheers
>> Bruno
>>
>>
>>    From: Oliver Heger 
>>   To: dev@commons.apache.org
>>   Sent: Tuesday, 17 July 2018 4:13 AM
>>   Subject: Re: [LANG] Java 9 problems because of dependencies to
>> java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)
>>    
>>
>> Am 16.07.2018 um 13:40 schrieb Bruno P. Kinoshita:
>>> Saw some recent activity around lang 3.8, and remembered about this
>>> issue, and then looked for this thread.
>>>
>>> Gilles' point is really good! Here's the Java 9 docs with the
>>> deprecation warning, copied below as well
>>> https://docs.oracle.com/javase/9/docs/api/index.html?java/util/Observable.html
>>>
>>>
>>>
>>> "This class and the Observer interface have been deprecated. The
>>> event model supported by Observer and Observable is quite limited,
>>> the order of notifications delivered by Observable is unspecified,
>>> and state changes are not in one-for-one correspondence with
>>> notifications. For a richer event model, consider using the
>>> java.beans package.  For reliable and ordered messaging among
>>> threads, consider using one of the concurrent data structures in the
>>> java.util.concurrent package. For reactive streams style programming,
>>> see the Flow API."
>>>
>>>
>>>
>>> So I guess the best we can do right now is add the @deprecated
>>> annotations, with an explanation in the javadocs. And also add a note
>>> about it in the release notes.
>>>
>>> Does that sound like a good plan? Adding a link to this thread in the
>>> pull request as well.
>>>
>> What about introducing our own state listener interface? The original
>> interface from the beans package was used just for convenience because
>> it already existed. But it would of course be possible to have a simple
>> functional interface to notify listeners about state changes.
>>
>> Oliver
>>
>>> Cheers
>>> Bruno
>>>
>>>
>>>
>>>
>>> 
>>> From: Stephen Colebourne 
>>> To: Commons Developers List 
>>> Sent: Monday, 11 June 2018 9:26 AM
>>> Subject: Re: [LANG] Java 9 problems because of dependencies to
>>> java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)
>>>
>>>
>>>
>>> Good spot. I think that means [lang] would have to have its own copy
>>> of the JDK interfaces. or just deprecate the functionality without
>>> replacement.
>>> S

Re: [LANG] Java 9 problems because of dependencies to java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)

[Oliver Heger]

Am 16.07.2018 um 13:40 schrieb Bruno P. Kinoshita:
> Saw some recent activity around lang 3.8, and remembered about this issue, 
> and then looked for this thread.
> 
> Gilles' point is really good! Here's the Java 9 docs with the deprecation 
> warning, copied below as well 
> https://docs.oracle.com/javase/9/docs/api/index.html?java/util/Observable.html
> 
> 
> "This class and the Observer interface have been deprecated. The event model 
> supported by Observer and Observable is quite limited, the order of 
> notifications delivered by Observable is unspecified, and state changes are 
> not in one-for-one correspondence with notifications. For a richer event 
> model, consider using the java.beans package.  For reliable and ordered 
> messaging among threads, consider using one of the concurrent data structures 
> in the java.util.concurrent package. For reactive streams style programming, 
> see the Flow API."
> 
> 
> 
> So I guess the best we can do right now is add the @deprecated annotations, 
> with an explanation in the javadocs. And also add a note about it in the 
> release notes.
> 
> Does that sound like a good plan? Adding a link to this thread in the pull 
> request as well.
> 

What about introducing our own state listener interface? The original
interface from the beans package was used just for convenience because
it already existed. But it would of course be possible to have a simple
functional interface to notify listeners about state changes.

Oliver

> 
> Cheers
> Bruno
> 
> 
> 
> 
> 
> From: Stephen Colebourne 
> To: Commons Developers List  
> Sent: Monday, 11 June 2018 9:26 AM
> Subject: Re: [LANG] Java 9 problems because of dependencies to java.desktop 
> (Was: Re: [LANG] Thoughts about Lang 4.0)
> 
> 
> 
> Good spot. I think that means [lang] would have to have its own copy
> of the JDK interfaces. or just deprecate the functionality without
> replacement.
> Stephen
> 
> On 10 June 2018 at 22:11, Gilles  wrote:
>> Hello.
>>
>> On Sun, 10 Jun 2018 21:34:49 +0200, Oliver Heger wrote:
>>>
>>> Hi Bruno,
>>>
>>> Am 10.06.2018 um 00:52 schrieb Bruno P. Kinoshita:
>>>>
>>>> Hi all,
>>>>
>>>> There is a patch [1] for LANG-1339 [2] that I would like to merge. The
>>>> discussion around this issue can be found in the rest of this e-mail 
>>>> thread.
>>>>
>>>> The patch basically deprecates the existing classes that depend on
>>>> java.desktop, and provide alternative implementations. The previous classes
>>>> used java.desktop classes for the PropertyChangeListener. And the
>>>> alternative ones instead use Java 7's java.util.Observer.
>>
>>
>> Is it a good idea to use deprecated classes[1] in new code?
>>
>> Regards,
>> Gilles
>>
>> [1] https://docs.oracle.com/javase/9/docs/api/java/util/Observable.html
>>
>>
>>>>
>>>>
>>>> This will make it easier to provide [lang] as java 9, without requiring
>>>> users to include a dependency to java.desktop.
>>>> Planning to merge it during the next week if there are no objections
>>>> here.
>>>>
>>>> Thanks,
>>>> Bruno
>>>
>>>
>>> agreed. This seems to be the best what we can do.
>>>
>>> Oliver
>>>
>>>>
>>>>
>>>> [1] https://github.com/apache/commons-lang/pull/275
>>>>
>>>> [2] https://issues.apache.org/jira/browse/LANG-1339
>>>>
>>>>
>>>>
>>>> From: Benedikt Ritter
>>>> 
>>>> To: Commons Developers List 
>>>> Sent: Monday, 5 June 2017 10:49 PM
>>>> Subject: [LANG] Java 9 problems because of dependencies to java.desktop
>>>> (Was: Re: [LANG] Thoughts about Lang 4.0)
>>>>
>>>>
>>>>
>>>>
>>>>> Am 25.05.2017 um 18:23 schrieb Oliver Heger
>>>>> :
>>>>>
>>>>>
>>>>>
>>>>> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
>>>>>>
>>>>>> On 23 May 2017 at 17:17, sebb  wrote:
>>>>>>>>
>>>>>>>> Yes, the
>>>>>>>> code compiles and both can be on the classpath, but it is a pain to
>>>>>>>> use, just a different kind of hell.
>>>>>>>
>>>>>>>
>>>>>>> I 

Re: [VOTE] Release Apache Commons DBCP 2.5.0 based on RC1

[Oliver Heger]

Am 16.07.2018 um 02:17 schrieb Gary Gregory:
> Thank you for your review; more below.
> '
> On Sun, Jul 15, 2018 at 12:20 PM Oliver Heger 
> wrote:
> 
>> Build works fine on Windows 10 with Java 8. Artifacts and site look good.
>>
>> +1
>>
>> I noticed the following things:
>> * In the first sentence of RELEASE-NOTES.txt the version has a -SNAPSHOT.
>>
> 
> That is not the case here or in the git release branch:
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.5.0-RC1/RELEASE-NOTES.txt
> 
> You should not look in git master.
It is in the file that is included in the source and binary distributions.

Oliver

> 
> * In README.txt it is stated that "DBCP version 2 requires JDK 1.7.".
>> This is not true for version 2.5.
>>
> 
> Bummer but not a blocker IMO since other sources make the correct reference
> to Java 8.
> 
> 
>> * I had some problems with the site build: My machine was under high
>> load created by another process. While executing the unit tests there
>> were some messages about ARJUNA, the build was hanging, and produced
>> high CPU load. Another build (with no other processes running) was
>> successful. I assume that some transactions ran in timeouts; maybe some
>> parameters or timeout settings could be fine-tuned. Another point is
>> that the site build printed some exception stack-traces, but this does
>> not seem to have an effect.
>> * There are some FindBugs warnings about internal state that is exposed,
>> I think most of them are about arrays storing a user password. Should
>> these be fixed by copying the arrays defensively?
>>
> 
> Sure, we can do that after this release IMO. Would you like to provide a
> patch/PR/commit?
> 
> Gary
> 
> 
>>
>> Oliver
>>
>> Am 13.07.2018 um 02:43 schrieb Gary Gregory:
>>> We have fixed quite a few bugs and added some significant enhancements
>>> since Apache Commons DBCP 2.4.0 was released, so I would like to release
>>> Apache Commons DBCP 2.5.0.
>>>
>>> The most significant change is support for JDCB 4.2 which now requires
>> Java
>>> 8.
>>>
>>> Apache Commons DBCP 2.5.0 RC1 is available for review here:
>>> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.5.0-RC1 (svn
>>> revision 28082)
>>>
>>> The Git tag commons-dbcp-2.5.0-RC1 commit for this RC is
>>> 00fd9d9b69caffef91aabc4091a9fe2fda787c7e which you can browse here:
>>>
>>>
>> https://git-wip-us.apache.org/repos/asf?p=commons-dbcp.git;a=tag;h=refs/tags/commons-dbcp-2.5.0-RC1
>>>
>>> Maven artifacts are here:
>>>
>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1345/org/apache/commons/commons-dbcp2/2.5.0/
>>>
>>> These are the Maven artifacts and their hashes in Nexus:
>>>
>>> #Release SHA-1s
>>> #Thu Jul 12 18:34:09 MDT 2018
>>> commons-dbcp2-2.5.0-src-zip=334d6ca8f17af2b3cdfecefee80be9ef4c1b0a6d
>>> commons-dbcp2-2.5.0-src-zip.asc=9afc06323785921dd3b3fbbefdb7fc2305f5edcd
>>>
>> commons-dbcp2-2.5.0-javadoc-jar.asc=ac52ea589eeadc010f94873b0ceda03526f960a8
>>>
>> commons-dbcp2-2.5.0-bin-tar.gz.asc=18307255d2067b0558ce27666e5521e58bb2b4fa
>>>
>> commons-dbcp2-2.5.0-sources-jar.asc=56134e00f522745803afa4a00dbb5f559835461e
>>> commons-dbcp2-2.5.0-bin-zip=b700f62f9b227ab5678979cd82146e9f7fb6e668
>>> commons-dbcp2-2.5.0-src-tar.gz=1c2322dbe89a23c626cc319e597547fe3d5b9c14
>>>
>> commons-dbcp2-2.5.0-src-tar.gz.asc=b8e4769bb919eb080c62e8219b9ada2b6ab2d42f
>>>
>> commons-dbcp2-2.5.0-test-sources-java-source=951e09cf75664e14d9c2860881c806ec8b9a2776
>>>
>> commons-dbcp2-2.5.0-javadoc-javadoc=ffd04b019c2ce18bd7aaf72560b11bcabf2f676f
>>> commons-dbcp2-2.5.0-bin-tar.gz=b69ef36e143bfe60edffd2da361e27e59d97fc20
>>> commons-dbcp2-2.5.0-pom.asc=af83bf99b904ddd1d913044c5f0bda17af0cf4bc
>>>
>> commons-dbcp2-2.5.0-tests-test-jar=b09d7729f5475a98896cd7b54c62c1e7a79f085d
>>>
>> commons-dbcp2-2.5.0-test-sources-jar.asc=139c97e3cfbb3212ddcbe557ddabb16271b89bde
>>>
>> commons-dbcp2-2.5.0-sources-java-source=31049a1a792aa8f2cd4ef7069bf1bdbc2eb66846
>>> commons-dbcp2-2.5.0-bin-zip.asc=fbe95bbdf474385465099fcb0e1298497b757e47
>>>
>> commons-dbcp2-2.5.0-tests-jar.asc=d0f9b231c86f35ac9afe8e96361fda9bbbd2d1ce
>>> commons-dbcp2-2.5.0-jar.asc=d70bcf8c312f33e4fd7a1d4ce4a014500cd81535
>>>
>>> #Release SHA-256s
>>> #Thu Jul 12 18:34:09 MDT 2018
>>>
>> commons-dbcp2-2.5.0

Re: [VOTE] Release Apache Commons DBCP 2.5.0 based on RC1

[Oliver Heger]

Build works fine on Windows 10 with Java 8. Artifacts and site look good.

+1

I noticed the following things:
* In the first sentence of RELEASE-NOTES.txt the version has a -SNAPSHOT.
* In README.txt it is stated that "DBCP version 2 requires JDK 1.7.".
This is not true for version 2.5.
* I had some problems with the site build: My machine was under high
load created by another process. While executing the unit tests there
were some messages about ARJUNA, the build was hanging, and produced
high CPU load. Another build (with no other processes running) was
successful. I assume that some transactions ran in timeouts; maybe some
parameters or timeout settings could be fine-tuned. Another point is
that the site build printed some exception stack-traces, but this does
not seem to have an effect.
* There are some FindBugs warnings about internal state that is exposed,
I think most of them are about arrays storing a user password. Should
these be fixed by copying the arrays defensively?

Oliver

Am 13.07.2018 um 02:43 schrieb Gary Gregory:
> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons DBCP 2.4.0 was released, so I would like to release
> Apache Commons DBCP 2.5.0.
> 
> The most significant change is support for JDCB 4.2 which now requires Java
> 8.
> 
> Apache Commons DBCP 2.5.0 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.5.0-RC1 (svn
> revision 28082)
> 
> The Git tag commons-dbcp-2.5.0-RC1 commit for this RC is
> 00fd9d9b69caffef91aabc4091a9fe2fda787c7e which you can browse here:
> 
> https://git-wip-us.apache.org/repos/asf?p=commons-dbcp.git;a=tag;h=refs/tags/commons-dbcp-2.5.0-RC1
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1345/org/apache/commons/commons-dbcp2/2.5.0/
> 
> These are the Maven artifacts and their hashes in Nexus:
> 
> #Release SHA-1s
> #Thu Jul 12 18:34:09 MDT 2018
> commons-dbcp2-2.5.0-src-zip=334d6ca8f17af2b3cdfecefee80be9ef4c1b0a6d
> commons-dbcp2-2.5.0-src-zip.asc=9afc06323785921dd3b3fbbefdb7fc2305f5edcd
> commons-dbcp2-2.5.0-javadoc-jar.asc=ac52ea589eeadc010f94873b0ceda03526f960a8
> commons-dbcp2-2.5.0-bin-tar.gz.asc=18307255d2067b0558ce27666e5521e58bb2b4fa
> commons-dbcp2-2.5.0-sources-jar.asc=56134e00f522745803afa4a00dbb5f559835461e
> commons-dbcp2-2.5.0-bin-zip=b700f62f9b227ab5678979cd82146e9f7fb6e668
> commons-dbcp2-2.5.0-src-tar.gz=1c2322dbe89a23c626cc319e597547fe3d5b9c14
> commons-dbcp2-2.5.0-src-tar.gz.asc=b8e4769bb919eb080c62e8219b9ada2b6ab2d42f
> commons-dbcp2-2.5.0-test-sources-java-source=951e09cf75664e14d9c2860881c806ec8b9a2776
> commons-dbcp2-2.5.0-javadoc-javadoc=ffd04b019c2ce18bd7aaf72560b11bcabf2f676f
> commons-dbcp2-2.5.0-bin-tar.gz=b69ef36e143bfe60edffd2da361e27e59d97fc20
> commons-dbcp2-2.5.0-pom.asc=af83bf99b904ddd1d913044c5f0bda17af0cf4bc
> commons-dbcp2-2.5.0-tests-test-jar=b09d7729f5475a98896cd7b54c62c1e7a79f085d
> commons-dbcp2-2.5.0-test-sources-jar.asc=139c97e3cfbb3212ddcbe557ddabb16271b89bde
> commons-dbcp2-2.5.0-sources-java-source=31049a1a792aa8f2cd4ef7069bf1bdbc2eb66846
> commons-dbcp2-2.5.0-bin-zip.asc=fbe95bbdf474385465099fcb0e1298497b757e47
> commons-dbcp2-2.5.0-tests-jar.asc=d0f9b231c86f35ac9afe8e96361fda9bbbd2d1ce
> commons-dbcp2-2.5.0-jar.asc=d70bcf8c312f33e4fd7a1d4ce4a014500cd81535
> 
> #Release SHA-256s
> #Thu Jul 12 18:34:09 MDT 2018
> commons-dbcp2-2.5.0-src-zip=36ace59006596586e8ea8952b194dd376f81a6cfc4333ab628aa10420e0ea6ad
> commons-dbcp2-2.5.0-src-zip.asc=11da753c934ac4643ccee6efb21702cf1ffe2a81505954870174a4face46dd94
> commons-dbcp2-2.5.0-javadoc-jar.asc=2423345b8316c5778d5025659bd675c803f88bc71a9b679880bd9285fa2e1d10
> commons-dbcp2-2.5.0-bin-tar.gz.asc=762012c3aa5471cf530d5c030c226bb9fd21adf03a5356c7ff9c72ed06a00155
> commons-dbcp2-2.5.0-sources-jar.asc=509e9dde87004d4f3deff97e951353d818fdd928c694e0db3c63bde8e17db0a2
> commons-dbcp2-2.5.0-bin-zip=2d94088c7514fc375abb93f013bf46782d77594511881457e3b75f00bafa9c3a
> commons-dbcp2-2.5.0-src-tar.gz=a8b0f36bcb855705f94b9241c9dd0e2bc6343cd018f75f1c79a8cf923fdcea88
> commons-dbcp2-2.5.0-src-tar.gz.asc=64eda94776b80f20a401061b2cffe8fac0504d086761b680e4bb3612e45dd2e7
> commons-dbcp2-2.5.0-test-sources-java-source=2b81b5c366ee5d5db7bd11075fc267a6ce89728c0e059aa37ca2fc24be5f3e9e
> commons-dbcp2-2.5.0-javadoc-javadoc=15678544a25b091ad1922e69d1e0ebd7513a7d2d2e3fdfecbbe7d44b23f7840d
> commons-dbcp2-2.5.0-bin-tar.gz=2e9da64b97af50951a3ac14b2269993fd8de323e00265d0e6a952fc108f05a22
> commons-dbcp2-2.5.0-pom.asc=a7b3a97deb8e8c90564754523440330f880b30ed8030bf74420c7974fbc404a8
> commons-dbcp2-2.5.0-tests-test-jar=3ddabb853de31e284ef5f8befdbc7c995c5d96ee892c53cb540d7f4fada4b81c
> commons-dbcp2-2.5.0-test-sources-jar.asc=37af73c51355665cc61e75892e024d1413d5abc8fff9b1b6d327aee6366aa8b1
> commons-dbcp2-2.5.0-sources-java-source=e6e9fc84c99b7816ac5d7f39f5babaec509b61d6527170f92896ffb841081c94
> 

Re: [ALL] Where should an OrderedObservable live in Commons?

[Oliver Heger]

Am 10.07.2018 um 19:13 schrieb Gary Gregory:
> Yeah, I dislike *Util names as well, it's not only a co-out but an
> encouragement to make such classes dumping-grounds/kitchen-sinks.
> 
> I was thinking [lang] or maybe [collections] but it's not a collection
> really.

As the implementation is thread-safe, I think it may belong in a similar
category as the circuit breaker classes and other concurrency utils we
have currently in [lang].

Oliver

> 
> Gary
> 
> On Tue, Jul 10, 2018 at 10:14 AM Rob Tompkins  wrote:
> 
>> Wouldn’t this be an argument for commons-util (specifically for extensions
>> of java.util)? Now, I whole heartedly disagree with naming things
>> “XxxxUtils” because I feel like the whole idea of naming a piece of a
>> machine a utility is a cop out and bad practice in semantics, so maybe this
>> goes with [pool] or [lang]??
>>
>>> On Jul 10, 2018, at 11:51 AM, Gary Gregory 
>> wrote:
>>>
>>> Does anyone have any thoughts on where an OrderedObservable should live
>> in
>>> Commons if at all?
>>>
>>> import java.util.ArrayList;
>>> import java.util.List;
>>> import java.util.concurrent.locks.Lock;
>>> import java.util.concurrent.locks.ReadWriteLock;
>>> import java.util.concurrent.locks.ReentrantReadWriteLock;
>>> import java.util.function.Consumer;
>>>
>>> public class OrderedObservable {
>>>
>>>private final ReadWriteLock readWriteLock = new
>>> ReentrantReadWriteLock(true);
>>>protected final Lock readLock = readWriteLock.readLock();
>>>protected final Lock writeLock = readWriteLock.writeLock();
>>>private final List listeners = new ArrayList<>();
>>>
>>>public void clearListeners() {
>>>listeners.clear();
>>>}
>>>
>>>public void notifyListeners(final Consumer algorithm) {
>>>this.readLock.lock();
>>>try {
>>>this.listeners.forEach(algorithm);
>>>} finally {
>>>this.readLock.unlock();
>>>}
>>>}
>>>
>>>public L register(final L listener) {
>>>this.writeLock.lock();
>>>try {
>>>this.listeners.add(listener);
>>>} finally {
>>>this.writeLock.unlock();
>>>}
>>>return listener;
>>>}
>>>
>>>public void unregister(final L listener) {
>>>this.writeLock.lock();
>>>try {
>>>this.listeners.remove(listener);
>>>} finally {
>>>this.writeLock.unlock();
>>>}
>>>}
>>>
>>> }
>>>
>>> Thank you,
>>> Gary
>>
>>
>> -
>> 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 Apache Commons Collections 4.2 based on RC1

[Oliver Heger]

Build works fine with Java 1.8 on Windows 10. Artifacts and site look good.

+1

Only one minor nit: On the site under Project Reports there is an empty
japicmp report.

Oliver

Am 08.07.2018 um 16:04 schrieb Gary Gregory:
> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons Collections 4.1 was released, so I would like to
> release Apache Commons Collections 4.2.
> 
> Apache Commons Collections 4.2 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/collections/4.2-RC1 (svn
> revision 27987)
> 
> The Git tag commons-collections-4.2-RC1 commit for this RC is
> 483cbbbf5a8b3c14edf3e6563e8f8ba380966d47 which you can browse here:
> 
> https://git-wip-us.apache.org/repos/asf?p=commons-collections.git;a=tag;h=refs/tags/commons-collections-4.2-RC1
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1344/org/apache/commons/commons-collections4/4.2/
> 
> These are the Maven artifacts and their hashes in Nexus:
> 
> #Release SHA-1s
> #Sun Jul 08 07:28:05 MDT 2018
> commons-collections4-4.2-sources-java-source=e8dd003d43b1f7dba173fb7e63f5c0b823f5e5c6
> commons-collections4-4.2-src-zip.asc=46c4d4c6fad99750abd5d28d14043dd76808ede2
> commons-collections4-4.2-src-zip=62d55eb312e5a25106420919d575b07a4e72136d
> commons-collections4-4.2-pom.asc=848fc1d0639b8fc98b991591363575e1f7752acb
> commons-collections4-4.2-src-tar.gz=8d26d4583c7d9f161dd133c5d24d269c40433532
> commons-collections4-4.2-test-sources-java-source=50b773aa645cc260761db2cc7b2187013f8e667e
> commons-collections4-4.2-tests-test-jar=f6a42da0fcc2daa4308b1c9bc1931339df3eca73
> commons-collections4-4.2-tests-jar.asc=080d6f5696fe1a0640fb2508b23003c82763799a
> commons-collections4-4.2-javadoc-javadoc=4ffc8a67913573ed78803875bf664b739564821d
> commons-collections4-4.2-bin-zip=ba2d36ec63545683f9792be799fe0ff6b323d8d9
> commons-collections4-4.2-bin-tar.gz=910a0d873d02796bf5999f244af73313465133eb
> commons-collections4-4.2-bin-tar.gz.asc=6517386ee43cf4eae752e22d2fe51b3c2de7d93a
> commons-collections4-4.2-test-sources-jar.asc=6a0a640a197434b0cc5cbc78a7a523ad57550430
> commons-collections4-4.2-bin-zip.asc=ee7e4096224e53ced1934536c8d3efa5df1f0518
> commons-collections4-4.2-sources-jar.asc=9e9bf9aa948876a7920353bc865a81896f5dc847
> commons-collections4-4.2-src-tar.gz.asc=c4ae85b480a35c1e1eb221ec5b4d116a80d80d65
> commons-collections4-4.2-jar.asc=1bd7e8ff20fffd02a82931f194d8942f09936144
> commons-collections4-4.2-javadoc-jar.asc=6505adb8ce085b57898c354a64b2542231633b5a
> 
> #Release SHA-256s
> #Sun Jul 08 07:28:05 MDT 2018
> commons-collections4-4.2-sources-java-source=c8d954f1dabd8c5aedbea8cee8b64e99c1167243285bcff0caf96bf8df5a8c97
> commons-collections4-4.2-src-zip.asc=1eec311645263ecbc640cc645f549e9863d4e5613911a7a0af7528642de18d30
> commons-collections4-4.2-src-zip=ead0ffd114f2de0593706c5d34b883e130ec53880e8be401523d7cac99875ff5
> commons-collections4-4.2-pom.asc=afa4c9052238e07b7651e06390918013cec6022aedff1915f34cccfcc4753741
> commons-collections4-4.2-src-tar.gz=8b35949fe044d68d141f7ff9ea2541b5001e6d940872722877211d211f90a477
> commons-collections4-4.2-test-sources-java-source=08e556c4c0f28a439d72a8772a449c43c497d7a9c1f500abe91137049e71e01e
> commons-collections4-4.2-tests-test-jar=d486614c3e2174b1d9b3aaee51ade2ba2e3ec64f29dc733648377d493e74aa65
> commons-collections4-4.2-tests-jar.asc=847ee3d4bd5fdccf6ec8b042afe6abdfc0727299ce43a65910b65ccbdb961665
> commons-collections4-4.2-javadoc-javadoc=d1a1516b43039538c992037f6522825a053799aa0ded04dd27dede5166e4a833
> commons-collections4-4.2-bin-zip=23b904d2ccb75083fbc9a3218e1ad956f5605c2ff4bcb7930c7c897a05adb5a8
> commons-collections4-4.2-bin-tar.gz=91cda7f59fc31462a2ba5b2a52d3c212e2ca41f1ccaaa5603fccaffeb66e9118
> commons-collections4-4.2-bin-tar.gz.asc=839eb945a960493e4dd6182c7d0274c99dfab4fdfc7ec0108f7da9cbbe060d9d
> commons-collections4-4.2-test-sources-jar.asc=488a6e8070b9bce2acd21516912ca537a41e9b000ca292097520c5f08b42d8f5
> commons-collections4-4.2-bin-zip.asc=9b7a4007b726b82f3cae5625d030a2ee70f433a1f0d449b8c27b5255a7061d79
> commons-collections4-4.2-sources-jar.asc=27a0b5d305cc5f95ed636c5df790ae62991cdae7aac248f410d47ad6278f20b1
> commons-collections4-4.2-src-tar.gz.asc=481acbe8f83ebd766d1069e539e5ec291fe6b212ec87b6313f3741b72a9381c1
> commons-collections4-4.2-jar.asc=2785044fbbe95e98fb8fb8b8c2cbb9a57aa730e233877bdf502aa2ce1452ee94
> commons-collections4-4.2-javadoc-jar.asc=0cfb4f2cb240c5306794423ce71e8bdc762af2e775898b00d911efd70c27184f
> 
> (no need for .asc hashes!)
> 
> I have tested this with 'mvn -V clean install site -P japicmp' using:
> 
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
> 2018-06-17T12:33:14-06:00)
> Maven home: C:\Java\apache-maven-3.5.4\bin\..
> Java version: 1.8.0_172, vendor: Oracle Corporation, runtime: C:\Program
> Files\Java\jdk1.8.0_172\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: 

Re: [VOTE] Release Apache Commons Pool 2.6.0 based on RC1

[Oliver Heger]

Build works fine with Java 8 on Windows 10. Artifacts and site look good.

+1

One minor point I noticed is that the release notes say that "Version 2
requires JDK level 1.6 or above", but the minimum JDK for 2.6 is 1.7.

There are also a few checkstyle errors that could be fixed with not too
much effort.

Oliver

Am 04.07.2018 um 00:27 schrieb Gary Gregory:
> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons Pool 2.5.0 was released, so I would like to release
> Apache Commons Pool 2.6.0.
> 
> Apache Commons Pool 2.6.0 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/pool/2.6.0-RC1 (svn
> revision 27911)
> 
> The Git tag commons-pool-2.6.0-RC1 commit for this RC is
> 281258e546f761a00e3379d7db4d6744e721d3c3 which you can browse here:
> 
> https://git-wip-us.apache.org/repos/asf?p=commons-pool.git;a=tag;h=refs/tags/commons-pool-2.6.0-RC1
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1342/org/apache/commons/commons-pool2/2.6.0/
> 
> These are the Maven artifacts and their hashes in Nexus:
> 
> #Release SHA-1s
> #Tue Jul 03 16:18:24 MDT 2018
> commons-pool2-2.6.0-src-tar.gz.asc=5a28d06adbac3b3775377ae8b62bd1938ae9c3dd
> commons-pool2-2.6.0-bin-tar.gz=ce825b0e6ed22538d4c7b53d4fedeada3430a711
> commons-pool2-2.6.0-pom.asc=7c00018a883cc14e09bff506985636280900f881
> commons-pool2-2.6.0-sources-jar.asc=3f7319a3259349b609d229c5e38e67b0fd2ec31b
> commons-pool2-2.6.0-bin-zip.asc=4817da837cce78457f3bece200179576d1ae14f7
> commons-pool2-2.6.0-jar.asc=7263fdf0061506d25f59b22ae86c2fc8ad6a308b
> commons-pool2-2.6.0-tests-jar.asc=ce1a3ac57b9257d3ea6491a807d3e59f1d3ad38f
> commons-pool2-2.6.0-javadoc-jar.asc=c126e1ffef27bda6116ca42041b4511bd562edbf
> commons-pool2-2.6.0-tests-test-jar=f29918fe848dd6393a77f944d7d8369703a90726
> commons-pool2-2.6.0-test-sources-jar.asc=b59fe31b13736e3437608cabb3643a53688b211e
> commons-pool2-2.6.0-src-zip=f5a584517eb4a2c048ae51ea3b2248ce4e59f4fb
> commons-pool2-2.6.0-bin-tar.gz.asc=b34b7a0a6db6e52292be0cd00d34fd20d2a7977c
> commons-pool2-2.6.0-src-zip.asc=b81401c71cb7213476f96f993ac35ee07a3cd80f
> commons-pool2-2.6.0-test-sources-java-source=7b959b3c98ddfcdc0ee296d4e3c2af0ffdbbe765
> commons-pool2-2.6.0-javadoc-javadoc=fd4b11c3fbf3bc883ce7df8de04962e212cc4277
> commons-pool2-2.6.0-src-tar.gz=e1944a581006117fa93bf3b2b9e2e3724d2383a6
> commons-pool2-2.6.0-bin-zip=954e155de24897caf192bf004111fd9d4d50c0df
> commons-pool2-2.6.0-sources-java-source=6b5036e509a52fe820c9c5a42dbf341f948e729f
> 
> #Release SHA-256s
> #Tue Jul 03 16:18:24 MDT 2018
> commons-pool2-2.6.0-src-tar.gz.asc=e28a47a44c58c25bc2bdbeee396de15e6d59ef1dc10d3b29472a6b5e31586a95
> commons-pool2-2.6.0-bin-tar.gz=961606add45d4212951482327d6b541214af1f95ea21b0528628eb031a4af522
> commons-pool2-2.6.0-pom.asc=755236bb99192f6c4280d781cf7b5c76c8b4215359e42649010dc0a431705b78
> commons-pool2-2.6.0-sources-jar.asc=4f5c54e1b05ad74eee66adde3efc984403cca577bb84d5e13469766185c3b846
> commons-pool2-2.6.0-bin-zip.asc=01d17755874efaf30bb6990682feea52a05ab7d668590385976d3ef8b6d3b3cf
> commons-pool2-2.6.0-jar.asc=867ed63ce33afab8543cc7b2e5eaa9b7112b6593eff1b3d13646ba0fc23aca10
> commons-pool2-2.6.0-tests-jar.asc=1aa0e7cfdd7709c477183a756ff00cc60d098b98eee63889e645a8b4ac974633
> commons-pool2-2.6.0-javadoc-jar.asc=95dd464a76b92be2a6e485c54cdc76d837ef4a09cc5e4b2c850bd9cdbcaf84b4
> commons-pool2-2.6.0-tests-test-jar=cefd3d7dde27c17a576b544055f71a346dce83b0276c9664a7aa180793a30468
> commons-pool2-2.6.0-test-sources-jar.asc=d3a504f2b76eefbb447fc58e5751b93892d5408db15ddbc1b559c1bb8165a6de
> commons-pool2-2.6.0-src-zip=8af7c55c3d80a9e8613f2af6a277067fa9d54d47acbc9a79c0c2e2f3f368a380
> commons-pool2-2.6.0-bin-tar.gz.asc=769e71cf3ec1152a04af14ec911494ee61ab33ba4e0cadb2e46b856005adcc82
> commons-pool2-2.6.0-src-zip.asc=b49da866c6f8ca2aa8f0389b97e0c21c563ea3e4367cdde3f0cc3e82130f2bf7
> commons-pool2-2.6.0-test-sources-java-source=44120179f216f5ca6e2633e29e03702f79158611e5305b589ab64ca83e8e4000
> commons-pool2-2.6.0-javadoc-javadoc=d40f49e0e5a86c482fca2d5fb7e4c63b6848ee7fe4e60fdb2141a3efa45c599b
> commons-pool2-2.6.0-src-tar.gz=006c9d76a3e8aeec908557ca06b9f33661b88e04ad075e4bb63cfd5f1d650c8f
> commons-pool2-2.6.0-bin-zip=42ed6eebeda1435ce7f82e952341aba7569b1213c4e0bd03108a50e602e1709d
> commons-pool2-2.6.0-sources-java-source=d729b9d229561ade56cec1ba412835ce86bcde10881848e2101810754bc4bdc0
> 
> (no need for .asc hashes!)
> 
> I have tested this with 'mvn clean install site' using:
> 
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
> 2018-06-17T12:33:14-06:00)
> Maven home: C:\Java\apache-maven-3.5.4\bin\..
> Java version: 1.8.0_172, vendor: Oracle Corporation, runtime: C:\Program
> Files\Java\jdk1.8.0_172\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> 
> Details of changes since 2.5.0 are in the release notes:
> 
> 

Re: [LAZY][VOTE] Release Apache Commons Parent 47 based on RC1

[Oliver Heger]

+1

Commons Configuration could be built successfully with CP 47.

Oliver

Am 28.06.2018 um 15:21 schrieb Rob Tompkins:
> We have fixed quite a few bugs and added some significant enhancements since 
> Apache Commons Parent 46 was released, so I would like to release Apache 
> Commons Parent 47.
> 
> Apache Commons Parent 47 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/47-RC1 (svn 
> revision 27786)
> 
> The Subversion tag for this RC is here:
> 
> http://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/commons-parent-47-RC1/
>  (svn revision XYZ2)
> N.B. the SVN revision is required because SVN tags are not immutable.
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1339/org/apache/commons/commons-parent/47/
> 
> These are the Maven artifacts and their hashes in Nexus:
> 
> #Release SHA-1s
> #Thu Jun 28 09:10:16 EDT 2018
> commons-parent-47-src-tar.gz=cee63ffe42ca49c9aac7ac5adb3b56224bb1e749
> commons-parent-47-pom.asc=18c842fcce89df74d7e57b7c1ae8160f9e894a2a
> commons-parent-47-site-xml.asc=02a3017720627e8f4efe8e155ef6b5f23f79ed9d
> commons-parent-47-src-zip=fe9b1f12e52b9d3446910943191dc0eba82bbfd0
> commons-parent-47-src-tar.gz.asc=8ed1fb05274158d1086fc1d98a525de664a83e02
> commons-parent-47-site-xml=02b3b54d26d97a72fd55b20d027040ca0daf52b7
> commons-parent-47-src-zip.asc=2d9aa20475a8635262a154462d713e66dc61ca42
> 
> #Release SHA-256s
> #Thu Jun 28 09:10:16 EDT 2018
> commons-parent-47-src-tar.gz=41403ab20f8ab6b570eb663303e083422a53f1ace8ebf707bb70e7025da6080f
> commons-parent-47-pom.asc=33758c0525edac2301970de6644f397195d6f87b6e7c58ce51ead70e8b56d680
> commons-parent-47-site-xml.asc=1431fb9c08f30e985885e2a149a33fb96c29a9181f15aa910892d2374134e581
> commons-parent-47-src-zip=0752e9b2e046c057d71edb3ea196e8f7d36aae511c1d135d5f9cfb0a879be8b1
> commons-parent-47-src-tar.gz.asc=fbee47f7e5d3689fcd888d16912106bd354028245f3d71ad9259027735be9dbf
> commons-parent-47-site-xml=29c8cdbab5859c506a8ce1b7a5d0fe63fabad15244ed79cde148eef0f9876246
> commons-parent-47-src-zip.asc=a29f4169a938557ab13669c2769876f0862b104effa4e5b26bb5d80fcbd6c412
> 
> 
> (no need for .asc hashes!)
> 
> I have tested this with 'mvn clean install site' using: 
> Maven home: /usr/local/Cellar/maven/3.5.4/libexec
> Java version: 1.8.0_162, vendor: Oracle Corporation, runtime: 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_162.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.13.5", arch: "x86_64", family: "mac"
> 
> Details of changes since 46 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/47-RC1/RELEASE-NOTES.txt
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/47-RC1/site/changes-report.html
> 
> Site:
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/47-RC1/site
> (note some *relative* links are broken and the 47 directories are not yet 
> created - these will be OK once the site is deployed.)
> 
> RAT Report:
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/47-RC1/site/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.
> 
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
> 
> Thank you,
> 
> Rob Tompkins, 
> Release Manager (using key B6E73D84EA4FCC47166087253FAAD2CD5ECBB314)
> -
> 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

[parent] Problem with japicmp when building site of [configuration]

[Oliver Heger]

Hi all,

I tried to update the pom of [configuration] to commons-parent 46. When
I build the site I get the error below.

[configuration] has a number of dependencies marked marked as
true. These are obviously not added to the
classpath. I tried to follow the suggestion in the error message to
ignore missing classes by setting the property
commons.japicmp.ignoreMissingClasses to true, but this does not have an
effect.

Any ideas how to fix this? Here is my Maven configuration:
$ mvn --version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T17:41:47+01:00)
Maven home: C:\data\dev\tools\apache-maven-3.3.9
Java version: 1.8.0_144, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_144\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos"


[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site) on
project commons-configuration2: Error generating
japicmp-maven-plugin:0.11.1:cmp-report report: Failed to generate
report: Could not load 'Class not found:
org.apache.commons.jxpath.ri.model.NodeIterator':
org.apache.commons.jxpath.ri.model.NodeIterator. Please make sure that
all libraries have been added to the classpath
(CLASSPATH=;C:\Users\hacker\.m2\repository\org\apache\commons\commons-lang3\3.7\commons-lang3-3.7.jar;C:\Users\hacker\.m2\repository\commons-logging\commons-logging\1.2\commons-logging-1.2.jar;C:\Users\hacker\.m2\repository\javax\servlet\servlet-api\2.4\servlet-api-2.4.jar;C:\Users\hacker\.m2\repository\xml-apis\xml-apis\1.0.b2\xml-apis-1.0.b2.jar;C:\Users\hacker\.m2\repository\commons-collections\commons-collections\3.2.2\commons-collections-3.2.2.jar;)
or try the option '--ignore-missing-classes'. -> [Help 1]

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

Re: [LANG] Java 9 problems because of dependencies to java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)

[Oliver Heger]

Hi Bruno,

Am 10.06.2018 um 00:52 schrieb Bruno P. Kinoshita:
> Hi all,
> 
> There is a patch [1] for LANG-1339 [2] that I would like to merge. The 
> discussion around this issue can be found in the rest of this e-mail thread.
> 
> The patch basically deprecates the existing classes that depend on 
> java.desktop, and provide alternative implementations. The previous classes 
> used java.desktop classes for the PropertyChangeListener. And the alternative 
> ones instead use Java 7's java.util.Observer.
> 
> 
> This will make it easier to provide [lang] as java 9, without requiring users 
> to include a dependency to java.desktop.
> Planning to merge it during the next week if there are no objections here.
> 
> Thanks,
> Bruno

agreed. This seems to be the best what we can do.

Oliver

> 
> 
> [1] https://github.com/apache/commons-lang/pull/275
> 
> [2] https://issues.apache.org/jira/browse/LANG-1339
> 
> 
> 
> From: Benedikt Ritter 
> To: Commons Developers List  
> Sent: Monday, 5 June 2017 10:49 PM
> Subject: [LANG] Java 9 problems because of dependencies to java.desktop (Was: 
> Re: [LANG] Thoughts about Lang 4.0)
> 
> 
> 
> 
>> Am 25.05.2017 um 18:23 schrieb Oliver Heger :
>>
>>
>>
>> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
>>> On 23 May 2017 at 17:17, sebb  wrote:
>>>>> Yes, the
>>>>> code compiles and both can be on the classpath, but it is a pain to
>>>>> use, just a different kind of hell.
>>>>
>>>> I don't see what the problem is here.
>>>
>>> Library A that depends on lang3 returns a Pair.
>>> Library B that depends on lang4 takes a Pair.
>>> Application cannot pass Pair from A to the B without conversion.
>>>
>>> My point is that it is possible to over-worry about jar hell.
>>> Joda-Time removed some methods when it went from v1.x to v2.x, but
>>> didn't change package name or maven co-ordinates. It was far more
>>> important that end-users didn't have two different LocalDate classes
>>> (a problem that couldn't be avoided when moving to Java 8). I've never
>>> seen any feedback about the incompatibility causing jar hell.
>>>
>>> The same is true here. It is vital to think properly about which is
>>> the worse choice, not just assume that jar hell must always be
>>> avoided.
>>>
>>> I remain completely unconvinced that removing these two problematic
>>> methods justifies the lang4 package name, forcing end-users to have
>>> three copies of the library on the classpath. It should need much,
>>> much more to justify lang4 package name. In fact I've yet to hear
>>> anything else much in this thread that justifies a major release.
>>
>> I also think that a new major release just to fix this problem would be
>> overkill and cause clients even more trouble.
>>
>> Would the following approach work as a compromise:
>>
>> - [lang] declares an optional dependency to the desktop module.
>> - All affected classes (AbstractCircuitBreaker and its two sub classes)
>> are marked as deprecated.
>> - Copies are created from the original classes with slightly changed
>> names or in a new package (tbd). These copies use a new change listener
>> mechanism.
>>
>> IIUC, the resulting [lang] module can now be used without the dependency
>> to desktop when the new classes are used. The dependency will only be
>> needed for the deprecated versions.
> 
> Let’s do it like this. Sounds like the right way to me.
> 
> Benedikt
> 
>>
>> Oliver
>>
>>>
>>> Stephen
>>>
>>> -
>>> 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
> 
> -
> 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 Compress 1.17 based on RC1

[Oliver Heger]

Build works fine on Windows 10 with Java 1.7 and 1.8. Artifacts and site
look good.

+1
Oliver

Am 31.05.2018 um 14:57 schrieb Stefan Bodewig:
> Hi all,
> 
> I would like to release Compress 1.17.
> 
> Compress 1.17 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/compress/ (svn revision 
> 27187)
> 
> The tag is here:
> tag 54e86f951 on commit d9993f8f
> 
> https://git-wip-us.apache.org/repos/asf?p=commons-compress.git;a=commit;h=d9993f8ff119d4a3eb1259b460c53401f619d655
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1328/org/apache/commons/commons-compress/1.17/
> 
> These are the Maven artifacts and their SHA256 hashes
> 
> 474c20609032e7f815ef534cd8174d2e400d9a8d  commons-compress-1.17.jar
> b9225416371a8cd195f344f081f68862cb7f69a3  commons-compress-1.17-javadoc.jar
> 9d064d7d42ee1d04ae07ad23025b4f9616652eed  commons-compress-1.17-sources.jar
> 3a2c468a8723aebc196ddf234dade6fed9405b50  commons-compress-1.17-tests.jar
> 45195f4e822582297aff2e9c6cb9e6cef4c52625  
> commons-compress-1.17-test-sources.jar
> 55c712b1d481d454b191f6aa66ce44e16cb876dd  commons-compress-1.17.pom
> 
> I have tested this with JDK 8 using Maven 3.5.0.
> 
> Details of changes since 1.16 are in the release notes:
> https://dist.apache.org/repos/dist/dev/commons/compress/RELEASE-NOTES.txt
> 
> https://stefan.samaflost.de/staging/commons-compress-1.17/changes-report.html
> 
> Site:
> https://stefan.samaflost.de/staging/commons-compress-1.17/
> 
> as usual this is not the site I'm going to publish after the
> release, I'll re-create the site when the release date is
> clear. The download link and 1.17 javadoc link won't work right
> now.
> 
> japicmp Report (compared to 1.16):
> https://stefan.samaflost.de/staging/commons-compress-1.17/japicmp.html
> 
> RAT Report:
> https://stefan.samaflost.de/staging/commons-compress-1.17/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. sometime after 14:00 UTC 03-June 2018
> 
>   [ ] +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-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: [DBCP] Drop Ant build?

[Oliver Heger]

Am 12.05.2018 um 20:36 schrieb Gary Gregory:
> Hi All:
> 
> Commons DBCP still has an Ant build. Should we drop it?

No objections from me. I think we already dropped support for Ant for
most of our components.

Oliver

> 
> Gary
> 

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

Re: [VOTE] Release Apache Commons DBCP 2.3.0 based on RC1

[Oliver Heger]

Am 12.05.2018 um 20:16 schrieb Gary Gregory:
> On Sat, May 12, 2018 at 10:37 AM, Oliver Heger <oliver.he...@oliver-heger.de
>> wrote:
> 
>> Build works fine with Java 1.7 and 1.8 - even the ant build seems to
>> work. Artifacts and site look good.
>>
>> The only problem I noticed is that the release notes refer to version
>> "2.3.0-SNAPSHOT", which is confusing.
>>
>> Do you think this requires a new RC or can we live with that?
>>
> 
> I can update that one file on the dist server after the fact. The src zip
> will still contain the snapshot reference.
> 
> I'm not sure this really is a blocker, at least not for me now.

Ok, so +1 from me.

Oliver

> 
> Gary
> 
> 
> Oliver
>>
>> Am 09.05.2018 um 02:08 schrieb Gary Gregory:
>>> We have fixed quite a few bugs and added some significant enhancements
>>> since Apache Commons DBCP 2.2.0 was released, so I would like to release
>>> Commons DBCP 2.3.0.
>>>
>>> Commons DBCP 2.3.0 RC1 is available for review here:
>>> https://dist.apache.org/repos/dist/dev/commons/dbcp/ (svn revision
>>> 26776)
>>>
>>> The tag is here:
>>>
>>> https://git1-us-west.apache.org/repos/asf?p=commons-dbcp.git;a=tag;h=
>> 830f0bf135ebc94cec7f2700171a2850430f76f7
>>>
>>> Maven artifacts are here:
>>>
>>> https://repository.apache.org/content/repositories/
>> orgapachecommons-1326/org/apache/commons/commons-dbcp2/2.3.0/
>>>
>>> These are the Maven artifacts and their hashes
>>>
>>> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.0.jar.asc
>>> (SHA1: 61a0593f9e79568a17cdf96a27f35a153661811e)
>>> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.0.jar
>>> (SHA1: bbb2876368ecb71f0108af1e09ceeb17b8688176)
>>> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.
>> 0-tests.jar.asc
>>> (SHA1: 9bd5ef92ff5716ca59afb64c0030d9cd1b08178b)
>>> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.0-tests.jar
>>> (SHA1: 92fc4af0d3348c715bd4d78be4fd800a84eca604)
>>> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.0.pom
>>> (SHA1: 8baf6f5f0083960ff08b91e173847bf7aaa6ac7c)
>>> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.
>> 0-test-sources.jar
>>> (SHA1: 74bb2457d0b523a8dd7efc2538c705ece5ac53e8)
>>> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.
>> 0-sources.jar.asc
>>> (SHA1: 6ccd175cbbbe583015db4ad3c62e9fed19b7135d)
>>> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.0-sources.jar
>>> (SHA1: fbe38b9ccf3e85b7ea712e56b2d31d9bbc775074)
>>> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.
>> 0-javadoc.jar.asc
>>> (SHA1: cc6606a256ec98028a8c357bab47dbacfdd154fe)
>>> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.
>> 0-test-sources.jar.asc
>>> (SHA1: 5b42b57b996266d2b7804d457af094cd00a93a88)
>>> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.0-javadoc.jar
>>> (SHA1: 0ea7fbe2914a272794befb9c98f831cc754b9e04)
>>> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.0.pom.asc
>>> (SHA1: e962ee933cfeb18e1b061e3dce5e62487df958d1)
>>>
>>> I have tested this with:
>>>
>>> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
>>> 2018-02-24T12:49:05-07:00)
>>> Maven home: C:\Java\apache-maven-3.5.3\bin\..
>>> Java version: 1.8.0_172, vendor: Oracle Corporation
>>> Java home: C:\Program Files\Java\jdk1.8.0_172\jre
>>> Default locale: en_US, platform encoding: Cp1252
>>> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>>>
>>> Details of changes since 2.2.0 are in the release notes:
>>> https://dist.apache.org/repos/dist/dev/commons/dbcp/RELEASE-
>> NOTES.txt
>>> changes-report.html in
>>> https://dist.apache.org/repos/dist/dev/commons/dbcp/site.zip
>>>
>>> Site:
>>> https://dist.apache.org/repos/dist/dev/commons/dbcp/site.zip
>>>   (note some *relative* links are broken and the 2.3.0 directories are
>>>   not yet created - these will be OK once the site is deployed)
>>>
>>>   The site contains a CLIRR report but not a JApiCmp report because I
>> could
>>> not get JApiCmp to work.
>>>
>>> Clirr Report (compared to 2.2.0):
>>> clirr-report.html in
>>> https://dist.apache.org/repos/dist/dev/commons/dbcp/site.zip
>>>
>

Re: [VOTE] Release Apache Commons DBCP 2.3.0 based on RC1

[Oliver Heger]

Build works fine with Java 1.7 and 1.8 - even the ant build seems to
work. Artifacts and site look good.

The only problem I noticed is that the release notes refer to version
"2.3.0-SNAPSHOT", which is confusing.

Do you think this requires a new RC or can we live with that?
Oliver

Am 09.05.2018 um 02:08 schrieb Gary Gregory:
> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons DBCP 2.2.0 was released, so I would like to release
> Commons DBCP 2.3.0.
> 
> Commons DBCP 2.3.0 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/dbcp/ (svn revision
> 26776)
> 
> The tag is here:
> 
> https://git1-us-west.apache.org/repos/asf?p=commons-dbcp.git;a=tag;h=830f0bf135ebc94cec7f2700171a2850430f76f7
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1326/org/apache/commons/commons-dbcp2/2.3.0/
> 
> These are the Maven artifacts and their hashes
> 
> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.0.jar.asc
> (SHA1: 61a0593f9e79568a17cdf96a27f35a153661811e)
> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.0.jar
> (SHA1: bbb2876368ecb71f0108af1e09ceeb17b8688176)
> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.0-tests.jar.asc
> (SHA1: 9bd5ef92ff5716ca59afb64c0030d9cd1b08178b)
> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.0-tests.jar
> (SHA1: 92fc4af0d3348c715bd4d78be4fd800a84eca604)
> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.0.pom
> (SHA1: 8baf6f5f0083960ff08b91e173847bf7aaa6ac7c)
> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.0-test-sources.jar
> (SHA1: 74bb2457d0b523a8dd7efc2538c705ece5ac53e8)
> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.0-sources.jar.asc
> (SHA1: 6ccd175cbbbe583015db4ad3c62e9fed19b7135d)
> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.0-sources.jar
> (SHA1: fbe38b9ccf3e85b7ea712e56b2d31d9bbc775074)
> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.0-javadoc.jar.asc
> (SHA1: cc6606a256ec98028a8c357bab47dbacfdd154fe)
> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.0-test-sources.jar.asc
> (SHA1: 5b42b57b996266d2b7804d457af094cd00a93a88)
> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.0-javadoc.jar
> (SHA1: 0ea7fbe2914a272794befb9c98f831cc754b9e04)
> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.0.pom.asc
> (SHA1: e962ee933cfeb18e1b061e3dce5e62487df958d1)
> 
> I have tested this with:
> 
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
> 2018-02-24T12:49:05-07:00)
> Maven home: C:\Java\apache-maven-3.5.3\bin\..
> Java version: 1.8.0_172, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_172\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> 
> Details of changes since 2.2.0 are in the release notes:
> https://dist.apache.org/repos/dist/dev/commons/dbcp/RELEASE-NOTES.txt
> changes-report.html in
> https://dist.apache.org/repos/dist/dev/commons/dbcp/site.zip
> 
> Site:
> https://dist.apache.org/repos/dist/dev/commons/dbcp/site.zip
>   (note some *relative* links are broken and the 2.3.0 directories are
>   not yet created - these will be OK once the site is deployed)
> 
>   The site contains a CLIRR report but not a JApiCmp report because I could
> not get JApiCmp to work.
> 
> Clirr Report (compared to 2.2.0):
> clirr-report.html in
> https://dist.apache.org/repos/dist/dev/commons/dbcp/site.zip
> 
> RAT Report:
> rat-report.html in
> https://dist.apache.org/repos/dist/dev/commons/dbcp/site.zip
> 
> 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. sometime after 04:00 UTC 31-March 2010
> 
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
> 
> Thanks!
> 
> Gary Gregory
> 

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

Re: [compress] High Level API for Archives

[Oliver Heger]

Hi Matt,

Am 29.04.2018 um 20:30 schrieb Matt Sicker:
> On 26 April 2018 at 14:38, Oliver Heger <oliver.he...@oliver-heger.de>
> wrote:
> 
>> Recently I had a closer look at streaming libraries like Akka Streams.
>> So I had the idea to model the problem in a similar way:
>>
> 
> I've used Akka Streams a bit in the past, and while it's pretty awesome, I
> feel as though taking this approach would at least require collaboration
> with an existing reactive streams library or a new Commons one. In that
> case, I wonder if it's worth competing with existing RS APIs like RxJava,
> Reactor, Vert.x, and Akka Streams. I'm not even sure if any RS people are
> active here at Commons as it is.

This is similar to my own line of thoughts. Developing an own streaming
lib is way too ambitious and also not needed as there are already some
really powerful libraries around. So there are the following options:
- Provide an API that resembles the core concepts of such libraries
without going too deep or providing similar flexibility. That would be
my first take and is probably also the route Stefan is following.
- Integrate with one of the existing libraries, e.g. by implementing
special transformers, sources, and/or sinks that handle compression or
extraction. Not sure whether this fits into commons as we currently do
not implement extensions for specific other libraries. It would probably
already be a longish discussion to choose one or more libraries to support.

> 
> 
>> An archive or deflate operation could be modeled by a flow from a source
>> via some filtering or modifying stages to a sink. The source and the
>> sink could both either refer to a directory or an archive file. In order
>> to create a new archive, the source would point to a directory and the
>> sink would represent the archive file to be created. To extract an
>> archive file, it would be the other way around. When both the source and
>> the sink point to an archive file, you have an update operation. So the
>> basic concepts can be combined in a natural way.
>>
> 
> This approach is interesting and could potentially be done without reactive
> streams. It would essentially be a similar looking API, but it just would
> be implemented differently.
Yes, my first option above.

> 
> 
>> There could be stages that filter for files or archive entries to select
>> the content of an archive file to be created or the files to be
>> extracted. Maybe it makes also sense to map on entries to manipulate
>> them somehow (rename?).
>>
> 
> Now you're really starting to describe a high level framework. While this
> sounds really neat, I feel like it might be beyond the scope of Commons and
> would warrant its own project at that point.
> 
> 
Perhaps. Maybe a stream-like API to move or copy files could fit into
[io]? Then [compress] could integrate with this. But I am aware that
this is also an ambitious project and goes beyond what [compress]
currently needs.

Oliver

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

Re: [compress] High Level API for Archives

[Oliver Heger]

Am 29.04.2018 um 19:08 schrieb Stefan Bodewig:
> Hi all
> 
> I've introduced a whole lot of infrastructure code with
> 
> https://github.com/apache/commons-compress/commit/f62c523154dfedcf49a87a865db545bb8c55e795
> 
> but the interface now looks nicer to me, in particual see
> 
> try (Sink sink = FileToArchiveSink.forFile(args[1], new 
> File(args[2]))) {
> Archive.directory(new File(args[0]))
> .to(sink);
> }
> 
> in ArchiveCli - all of this in a new examples package. No unit tests,
> but I've tried the new cli with all formats we support writing for. Only
> archive creation is there, yet, but the opposite direction will reuse a
> lot of the infrastructure.
> 
> If this is something that looks acceptable I'll add expansion and remove
> the other two classes. If not, we'll need to think about an acceptable
> example API a bit longer. :-)

Big +1! Looks very good to me.

Oliver

> 
> Cheers
> 
> Stefan
> 
> -
> 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: [compress] High Level API for Archives

[Oliver Heger]

Am 26.04.2018 um 17:37 schrieb Matt Sicker:
> If it helps in design, the most promising approach I found was to integrate
> with the java.nio.file API. However, that turns into a sort of hybrid
> library between VFS and Compress. However, they are rather strongly related
> (if the two libraries were modular, then it wouldn't be such a problem to
> combine them).
> 
> On 26 April 2018 at 10:04, Stefan Bodewig  wrote:
> 
>> On 2018-04-24, sebb wrote:
>>
>>> On 23 April 2018 at 20:48, Torsten Curdt  wrote:
 TBH I am not such super big fan of adding and maintaining a high level
 API at this stage.
 You will never find the right abstraction that everyone is happy with.
 If you would - well, then that should be the real API afterall.
>>
 Honestly - I would just add example code for now. Maybe that can turn
 into a helper class in the long run.
 But for now we would not introduce something we may no longer break.
>>
>>> I like the idea of introducing it as example code.
>>> That makes it obvious that it will change.
>>
>> As the only people who spoke up prefer to not provide the API as an
>> officially supported one, I'm fine with moving the stuff to an examples
>> package, add a warning and add unit tests so we now it keeps on working.
>>
>> Unless anybody yells and says "no we really need this high level API",
>> that is.
>>
>> I'd still like to spend some time and gather feedback on a nicer API
>> than many overloads - is fluent the way to go?

Recently I had a closer look at streaming libraries like Akka Streams.
So I had the idea to model the problem in a similar way:

An archive or deflate operation could be modeled by a flow from a source
via some filtering or modifying stages to a sink. The source and the
sink could both either refer to a directory or an archive file. In order
to create a new archive, the source would point to a directory and the
sink would represent the archive file to be created. To extract an
archive file, it would be the other way around. When both the source and
the sink point to an archive file, you have an update operation. So the
basic concepts can be combined in a natural way.

There could be stages that filter for files or archive entries to select
the content of an archive file to be created or the files to be
extracted. Maybe it makes also sense to map on entries to manipulate
them somehow (rename?).

The API could be extensible by allowing clients to create their own
implementations of sources, sinks, and flow stages.

Just some high-level thoughts without having thought that through.

Oliver

>>
>>> If not, maybe put the code in an experimental package.
>>
>> The changeset package is in this state and has been like this for years
>> now, I doubt we'd ever get anything out of the experimental phase :-)
>>
>> Stefan
>>
>> -
>> 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: [compress] Need Help With PAX Exam Tests

[Oliver Heger]

Hi,

Am 23.04.2018 um 22:21 schrieb Stefan Bodewig:
> Hi all
> 
> I'm trying to resolve COMPRESS-443 which talks about having a regression
> test that fails if we break the OSGi bundle again (has already happened
> three times duing the life of Compress so far). But unfortunately I'm
> getting stuck with my limited Maven and even more limited PAX Exam Fu.
> 
> You can see what I've tried in the COMPRESS-443 branch:
> https://github.com/apache/commons-compress/tree/COMPRESS-443
> 
> The OsgiITest I've added loads the SNAPSHOT version I've installed into
> my local repo last and doen't care about the current classes and POM,
> which is quite understandable as the bundle hasn't even been built when
> I try to run the test.
> 
> Do I have to create a separate maven project just for the tests? If so,
> I'll probably just drop the very idea as turning compress into a reactor
> build just for a single test case feels wrong.
> 
> I really hope I am missing something obvious. This has been true often
> enough that I'm optimisitic :-)

at work we used PaxExam to test OSGi-based applications consisting of
multiple modules. Here the (integration) tests have always been in a
separate module as they require a more complex setup.

To have only a single module, maybe it would work to run the test in the
verify phase and reference the artifact via PaxExam's streamBundle()
option directly from the file system?

We could also think about having a separate Commons-internal project
that contains OSGi-related tests. Such tests are useful for most of our
components, and we could even test whether they collaborate correctly in
their current versions. Well, this is certainly not trivial.

Oliver

> 
> Stefan
> 
> -
> 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] Migrate existing Git repos to GitBox

[Oliver Heger]

+1

Oliver

Am 22.04.2018 um 19:07 schrieb Matt Sicker:
> This is a vote to migrate existing Git repositories from the old git-wip-us
> infrastructure to the new gitbox infrastructure. New Apache projects are
> not allowed to use git-wip-us and are instead directed to use gitbox. As
> such, it makes sense for us to stay consistent with other projects.
> 
> The advantages to migrating to gitbox besides infra is much better GitHub
> integration. The gist of how GitBox works is that git repos are mirrored
> two-way between apache and github. The old git-wip-us github integration is
> read-only which makes merging pull requests a chore and also makes the
> github project pages a bit confusing as they aren't traditional github
> projects as it is.
> 
> This vote only applies to existing git repositories at Commons. Existing
> svn repositories will be covered in a different vote later on.
> 
> If you have a preference for Jira or GH Issues or something, please feel
> free to add that to your vote. All existing projects are already in Jira as
> it is.
> 
> References:
> https://issues.apache.org/jira/browse/INFRA-16413
> https://gitbox.apache.org/
> 

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

Re: Discuss [VOTE] Migrate Commons Weaver to Git

[Oliver Heger]

Am 21.04.2018 um 22:31 schrieb Matt Sicker:
> I opened an infra ticket [1] to find out our options here. My preferred
> option would be to migrate all of Commons over to gitbox for consistency.

Many thanks, Matt!

I would be +1 for a mass conversion, too. I think, nobody has objections
against Git any more. The reason why some components still use SVN is
just inertia.

Oliver

> 
> [1]: https://issues.apache.org/jira/browse/INFRA-16413
> 
> On 21 April 2018 at 12:23, Matt Benson <mben...@apache.org> wrote:
> 
>> On Sat, Apr 21, 2018, 11:20 AM Rob Tompkins <chtom...@gmail.com> wrote:
>>
>>>
>>>
>>>> On Apr 21, 2018, at 10:20 AM, Oliver Heger <
>> oliver.he...@oliver-heger.de>
>>> wrote:
>>>>
>>>>
>>>>
>>>> Am 20.04.2018 um 19:08 schrieb Matt Sicker:
>>>>> Wow, us "legacy" projects really need to keep up to date with these
>>>>> requirements. GitBox, no CMS (I think we're using svnpubsub
>> everywhere,
>>> but
>>>>> this could also use gitpubsub with an asf-site branch), etc.
>>>>
>>>> Would it reduce overhead if we converted multiple components at once?
>>>>
>>>> I would like to move with [configuration] to git, but have hesitated so
>>>> far because I do not know the process in detail and what the effort is.
>>>
>>> If we wanted to do a (mildly) mass effort, I would be on board with
>>> helping.
>>>
>>>
>> Noble as that is (no sarcasm intended), is there any reason that migrating
>> components *en masse* would be easier or otherwise preferable to doing so
>> "piecemeal"?
>>
>> Matt
>>
>>
>> -Rob
>>>
>>>>
>>>> Oliver
>>>>
>>>>>
>>>>> On 20 April 2018 at 10:13, Matt Benson <gudnabr...@gmail.com> wrote:
>>>>>
>>>>>> As Emmanuel suggested, Daniel Gruno confirmed for me that "git-wip is
>>>>>> slowly being deprecated." So the answer to the question initially
>>> posed by
>>>>>> Ralph would seem in fact to be gitbox.
>>>>>>
>>>>>> Thanks,
>>>>>> Matt
>>>>>>
>>>>>> On Thu, Apr 19, 2018 at 11:57 PM, Romain Manni-Bucau <
>>>>>> rmannibu...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Gitbox is easier to use with github which makes contribs easier.
>>>>>> Otherwise
>>>>>>> you dont see much difference as a git user.
>>>>>>>
>>>>>>> Le 20 avr. 2018 00:16, "Emmanuel Bourg" <ebo...@apache.org> a
>> écrit :
>>>>>>>
>>>>>>>> Le 20/04/2018 à 00:12, sebb a écrit :
>>>>>>>>> I suggest asking Infra whether they are both going to be supported
>>>>>>>> longer term.
>>>>>>>>
>>>>>>>> FWIW when I migrated JEXL I had no other choice than using Gitbox.
>>> I'm
>>>>>>>> not sure Infra still accepts new git-wip repositories.
>>>>>>>>
>>>>>>>> Emmanuel Bourg
>>>>>>>>
>>>>>>>> 
>> -
>>>>>>>> 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 >> dev-unsubscr...@commons.apache.org>
>>>> For additional commands, e-mail: dev-h...@commons.apache.org >> 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: Discuss [VOTE] Migrate Commons Weaver to Git

[Oliver Heger]

Am 20.04.2018 um 19:08 schrieb Matt Sicker:
> Wow, us "legacy" projects really need to keep up to date with these
> requirements. GitBox, no CMS (I think we're using svnpubsub everywhere, but
> this could also use gitpubsub with an asf-site branch), etc.

Would it reduce overhead if we converted multiple components at once?

I would like to move with [configuration] to git, but have hesitated so
far because I do not know the process in detail and what the effort is.

Oliver

> 
> On 20 April 2018 at 10:13, Matt Benson  wrote:
> 
>> As Emmanuel suggested, Daniel Gruno confirmed for me that "git-wip is
>> slowly being deprecated." So the answer to the question initially posed by
>> Ralph would seem in fact to be gitbox.
>>
>> Thanks,
>> Matt
>>
>> On Thu, Apr 19, 2018 at 11:57 PM, Romain Manni-Bucau <
>> rmannibu...@gmail.com>
>> wrote:
>>
>>> Gitbox is easier to use with github which makes contribs easier.
>> Otherwise
>>> you dont see much difference as a git user.
>>>
>>> Le 20 avr. 2018 00:16, "Emmanuel Bourg"  a écrit :
>>>
 Le 20/04/2018 à 00:12, sebb a écrit :
> I suggest asking Infra whether they are both going to be supported
 longer term.

 FWIW when I migrated JEXL I had no other choice than using Gitbox. I'm
 not sure Infra still accepts new git-wip repositories.

 Emmanuel Bourg

 -
 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: [configuration] RDF configuration serialization format

[Oliver Heger]

Hi Claude,

(Note that I have added the component name to the subject because this
is a shared list.)

Am 11.04.2018 um 10:49 schrieb Claude Warren:
> Greetings,
> 
> I have been using commons configuration2 for sometime with apache jena.
> The RDF format has many of the same properties of the XML format but maps
> to an RDF graph rather than the XML tree.
> 
> I would like to extend and contribute the code as a new serialization
> format.  What is the recommended strategy to achieve this?
> 

This for sure sounds interesting!

As implementation strategy I would recommend to take XMLConfiguration or
one of the other hierarchical configurations as an example and modify it
accordingly for parsing and writing RDF data. The base classes should
already support the management of hierarchical data structures.

Maybe it is also of interest to have a look at Commons RDF [1].

When you have some working code with unit tests, just create a Jira
ticket and attach it.

Many thanks for your interest!
Oliver

[1] https://commons.apache.org/proper/commons-rdf/

> Claude
> 

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

Re: snapshot packaging?

[Oliver Heger]

Hi,

Am 11.04.2018 um 10:42 schrieb Claude Warren:
> Greetings,
> 
> Is the snapshot packaging for commons configuration2 available for download
> / maven?

AFAIK, there are no nightly builds that are deployed automatically; but
it is possible to deploy snapshot builds manually to the Apache Maven
Snapshot repository.

> 
> If so what is the current snapshot number?
I have just deployed a snapshot after applying the latest patch of yours:
https://repository.apache.org/#nexus-search;gav~~commons-configuration2~~~


> 
> As follow-on questions:
> 
> What is the release cadence for commons configuration / when is the next
> scheduled release?
Commons components do not have a fix release schedule. After some work
on a component has been done and there is interest on the mailing list,
a release typically happens.

Currently some work is done related to our release infrastructure. There
seems to be interest in a new release of [configuration] because it has
been asked to use this component as an example and test for our new
release plugin.

> 
> What is the process for initiating a bug fix release (e.g. 2.2.2)?
Also no formal process; just ask on the mailing list.

Oliver

> 
> thx
> 
> Claude
> 

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

Re: [httpclient] Better user agent header?

[Oliver Heger]

Wrong mailing list, guys?

Http Client is not part of Apache Commons.

Oliver

Am 30.03.2018 um 18:44 schrieb Mark Thomas:
> On 30/03/18 12:22, ajs6f wrote:
>> For at least some cases, this wouldn't be good for security.
> 
> That is debatable.
> 
> Providing exact version information is highly unlikely (I almost wrote
> impossible but never say never) to create a vulnerability.
> 
> It might make a vulnerability more obvious but if the client is
> vulnerable, it is vulnerable whether or not the version information is
> provided.
> 
> Trying to hide the version information (it may be exposed indirectly
> elsewhere) is security by obscurity which is no security at all.
> 
> 
> The key question for me is does the client OS or Java version matter?
> Why might this information be useful to a sever?
> 
> 
> I do have a privacy concern. As a user I may not wish to expose my
> choice of JRE or OS to the server.
> 
> 
> My default position would be not to send it at all. Depending on the
> answer to "How is this info useful?", I could be persuaded to support
> making it optional, possibly even present by default.
> 
> Of course, all of this is from the peanut gallery as I haven't
> contributed to this component and am unlikely to do so any time soon.
> 
> Mark
> 
> 
>> I would prefer that this be configurable (via HttpClientBuilder and/or
> system props) and not the default.
>>
>> ajs6f
>>
>>> On Mar 29, 2018, at 6:20 PM, Gary Gregory  wrote:
>>>
>>> Hi All:
>>>
>>> Right now, the HttpClient is of the form:
>>>
>>> User-Agent: Apache-HttpClient/4.5.5 (Java/1.8.0_162)
>>>
>>> With the stack I am working with, it would be handy if the header reflected:
>>>
>>> - The Java vendor
>>> - Operating system name and version.
>>>
>>> For example:
>>>
>>> User-Agent: Apache-HttpClient/4.5.5 (Oracle Corporation/Java/1.8.0_162)
>>> Windows/10.0 (amd64)
>>>
>>> Any thoughts for or against adding this to the user agent string?
>>>
>>> Gary
>>
>>
>> -
>> 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: [configuration] Java 8 types

[Oliver Heger]

Am 29.03.2018 um 15:54 schrieb Gary Gregory:
> Done.
> 
> Gary
> 
> On Wed, Mar 28, 2018 at 2:21 PM, Jochen Wiedmann 
> wrote:
> 
>> +1
>>
>>
>> On Wed, Mar 28, 2018 at 9:06 PM, Gary Gregory 
>> wrote:
>>> Hi All:
>>>
>>> I say it is time to update Commons Configuration to Java 8 and support
>> the
>>> types in java.time.
>>>
>>> Thoughts?

Supporting these new types is certainly desirable.

As the conversion mechanism is designed to be extensible, maybe this can
be achieved without increasing the minimum Java requirement for the core
library: We could add a module (making [configuration] to a multi-module
project) that just contains a converter for new Java 8 types. This
module would then obviously require Java 8.

The API for installing this converter probably would need some tweaking
to make the extension of the conversion mechanism more convenient. But
this should be doable. The user guide [1] describes this mechanism and
how to add custom converters.

While I am not strictly against switching to Java 8, I fear that there
are still users who have to stick to version 1.7, for instance on Android.

Oliver

[1]
http://commons.apache.org/proper/commons-configuration/userguide/howto_basicfeatures.html#Data_type_conversions

>>>
>>> Gary
>>
>> -
>> 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 Text 1.3 based on RC1

[Oliver Heger]

Build works fine with Java 1.7 and 1.8. Artifacts and site look good.

So +1.

Minor nit: The site has a japicmp report which is just an empty page.

Oliver

Am 16.03.2018 um 16:35 schrieb Rob Tompkins:
> Hello all,
> 
> This is a [VOTE] for releasing Apache Commons Text 1.3 (from RC1).
> 
> Tag name:
>commons-text-1.3-RC1 (signature can be checked from git using 'git tag
> -v')
> 
> Tag URL:
>
> https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=tag;h=6e7a377e76bc7e34c286b5c5ee0433f00dc0d358
> 
> Commit ID the tag points at:
> 4ac48357180c9222f032dd8b055d90e1192e4a47
> 
> Site Zip:
>https://dist.apache.org/repos/dist/dev/commons/text/site.zip
> 
> Distribution files (committed at revision 25771):
>https://dist.apache.org/repos/dist/dev/commons/text/
> 
> Distribution files hashes (SHA1):
>commons-text-1.3-bin.tar.gz
>(SHA: 992637a7dcd53bdfc7831f3dfba171b998119e10)
>commons-text-1.3-bin.zip
>(SHA1: 6f4c8785d57f6af21fe08218e7d82ce5404c291c)
>commons-text-1.3-src.tar.gz
>(SHA1: 987bd384cb11bb5f52ddf5c866058faa6a00a298)
>commons-text-1.3-src.zip
>(SHA1: f234bbb3d0816800d4f7b997b65edbbc3c66c87c)
> 
> These are the Maven artifacts and their hashes:
>commons-text-1.3-javadoc.jar
>(SHA1: 8e170d7068f08823c0ad208214a48506f2950cbc)
>commons-text-1.3-sources.jar
>(SHA1: 9c51853f855aca4ea31785f30385e980a58eaf4b)
>commons-text-1.3-test-sources.jar
>(SHA1: d8f817cae41c3664ed89933e137f007a8e0f2c7b)
>commons-text-1.3-tests.jar
>(SHA1: 97d5a4ea56febf105f85cd6783a9dd8492d880c2)
>commons-text-1.3.jar
>(SHA1: 9abf61708a66ab5e55f6169a200dbfc584b546d9)
>commons-text-1.3.pom
>(SHA1: 319d278bae93adc3f5b5e8408a90fd2d98ce75f7)
> 
> KEYS file to check signatures:
>http://www.apache.org/dist/commons/KEYS
> 
> Maven artifacts:
>https://repository.apache.org/content/repositories/orgapachecommons-1319
> 
> 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 
> 2018-03-19T16: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: [DISCUSS] new component for timing?

[Oliver Heger]

Am 02.03.2018 um 15:45 schrieb Gary Gregory:
> On Fri, Mar 2, 2018 at 7:31 AM, Otto Fowler  wrote:
> 
>> I don’t understand the options that we are discussing here.  Can we
>> clarify?
>>
>> * create a new component from sirota, bringing it into commons ( resurrect
>> commons-monitoring ) and put StackWatch there?
>>
> 
> Something like that. For my money, I'd like this into a (probably new)
> component that is not [lang] since it feels out of scope. StopWatch would
> move to this new place (deprecate it in [lang] and copy it.)

IMHO StackWatch does not fit very well into [lang] and into the testing
project neither.

One other suggestion: It was stated in the past that the concurrent
classes are also a bit out of scope for [lang], especially the circuit
breaker implementations. Would it make sense to move those into a new
module, and could this be a home for the watch classes, too?

Oliver

> 
> Gary
> 
> 
>>
>> On March 2, 2018 at 08:49:03, Romain Manni-Bucau (rmannibu...@gmail.com)
>> wrote:
>>
>> This i right but it started as just a few utilities and interception
>> modules, then it grows as any performance related project. We also have
>> skywalking which is quite big but can host all that utility part @asf.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github > rmannibucau> |
>> LinkedIn  | Book
>> > ee-8-high-performance>
>>
>> 2018-03-02 14:45 GMT+01:00 Otto Fowler :
>>
>>> My understanding is that sirona was/is a complete system, as opposed to a
>>> collection of utilities.
>>> If StackWatch is too big for LANG it seems too small for sirona.  Along
>>> with sirona being retired etc.
>>>
>>>
>>>
>>> On February 28, 2018 at 15:06:52, Romain Manni-Bucau (
>>> rmannibu...@gmail.com) wrote:
>>>
>>> Le 28 févr. 2018 19:27, "Matt Sicker"  a écrit :
>>>
>>> This sounds almost like a sort of Commons Metrics type project. See <
>>> http://metrics.dropwizard.io/4.0.0/> for an example. There's a sandbox
>>> project called Commons Monitoring which may be similar.
>>>
>>>
>>> Sirona started from commons-monitoring ;)
>>>
>>>
>>>
>>> On 28 February 2018 at 10:56, Gilles 
>> wrote:
>>>
 On Wed, 28 Feb 2018 17:24:29 +0100, Romain Manni-Bucau wrote:

> 2018-02-28 17:11 GMT+01:00 Gilles :
>
> On Wed, 28 Feb 2018 16:59:08 +0100, Romain Manni-Bucau wrote:
>>
>> Hi guys,
>>>
>>> On that topic we can keep in mind we retired not a lot time ago
>> Apache
>>> Sirona which was a perf framework industrializing a stopwatch to
>>> summarize
>>> it.
>>> We can make it live again and would probably be a better fir than
>>> commons
>>> cause you quickly need more than just some time measurement when you
>>> start
>>> to work on these topics.
>>>
>>>
>> Why was the project terminated?
>>
>>
> Community didn't grow enough and activity was not that high - the
>>> project
> went stable pretty quickly. I forked it on github for now
> https://github.com/rmannibucau/sirona
>

 Does it contain a feature similar to the "StackWatch"
 proposed in
 https://issues.apache.org/jira/browse/LANG-1373
 ?

 If so, do you suggest that Otto's project should depend
 on Sirona?

 If not, do you suggest that Otto should submit the PR
 to Sirona (and then depend on it)?


 Gilles


>>
>> Just my 2 cts
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau  | Blog
>>>  | Old Blog
>>>  | Github
>>>  |
>>> LinkedIn  | Book
>>>
>>> >> high-performance>
>>>
>>>
>>> 2018-02-28 16:56 GMT+01:00 Gary Gregory :
>>>
>>> On Wed, Feb 28, 2018 at 6:35 AM, Gilles <
>> gil...@harfang.homelinux.org

>>>
 wrote:

> Hello.
>
> On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
>
>> Hi,
>>
>> In the course of working through my pull request for adding new
>>> LANG
>> functionality on top of the StopWatch class, the issue has been
 raise
 as
>> to
>> if this functionality is ‘common’ or should
>> be placed in a more specialized commons- component.
>>
>> We would like to take the discussion to the list for this, and
>> see
 what
>> everyone thinks.

Re: [compress] cut 1.16.1 very soon?

[Oliver Heger]

Am 10.02.2018 um 09:55 schrieb Stefan Bodewig:
> On 2018-02-10, Simon Spero wrote:
> 
>> Writing tests for osgi modules is painless... the second time :-P
> 
> I said I "was pointed into a direction for writing a test ..." that's
> been your and Bertrand's input. :-)
> 
>> The key to making tests easy is to use pax-exam, which handles most of the
>> tedious container setup and junit / test-NG test execution.
> 
>> https://ops4j1.jira.com/wiki/spaces/PAXEXAM4/pages/54263870/Documentation
> 
> Thanks again.
> 
>> I can implement this if OSGI related changes are wanted.
> 
> What *I*'d want to see is a regression test that prevents us from
> breaking the manifest or dropping imports that used to be there. Others
> may want additional OSGI related changes.
> 
> https://issues.apache.org/jira/browse/COMPRESS-443
> 

PaxExam is really a nice tool to write integration tests running inside
the OSGi container. For the purpose at hand it would be possible to
create a setup that starts an embedded OSGi container and deploys the
bundle created by the project. This is not fully trivial because it
requires that all (transitive) dependencies are also installed in the
container.

Such a test checks whether the manifest is more or less syntactically
correct. In order to prove that all packages are correctly exported,
some more tests would have to be written that access the public API.
(Ideally one would run the whole unit test suite in the container, but I
doubt that this would be feasible. Some tests are probably white-box
tests and access internals of a class that are not necessarily available
inside OSGi.)

It would be great to have some generic setup that could be reused by all
Commons components. Maybe another maven plugin? It would require some
functionality of the dependencies plugin to resolve all dependencies,
and of the surefire plugin to run tests.

Oliver

> Stefan
> 
> -
> 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 Compress 1.16.1 based on RC1

[Oliver Heger]

Build works fine with Java 1.7 and 1.8 on Windows 10. With the site
build on Java 8 I get the same error as for 1.16 (see below, not
blocking). Artifacts and site look good.

+1

Oliver

[warn] No new version specified and file
'C:\data\dev\projects\OpenSource\Apache\compress\commons-compress-1.16.1-src\target\classes'
of artifact could not be opened as jar archive:
C:\data\dev\projects\OpenSource\Apache\compress\commons-compress-1.16.1-src\target\classes
(Zugriff verweigert)

java.io.FileNotFoundException:
C:\data\dev\projects\OpenSource\Apache\compress\commons-compress-1.16.1-src\target\classes
(Zugriff verweigert)
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:225)
at java.util.zip.ZipFile.(ZipFile.java:155)
at java.util.jar.JarFile.(JarFile.java:166)
at java.util.jar.JarFile.(JarFile.java:130)
at
japicmp.maven.JApiCmpMojo.populateArchivesListsFromParameters(JApiCmpMojo.java:341)
at japicmp.maven.JApiCmpMojo.getOptions(JApiCmpMojo.java:704)
at
japicmp.maven.JApiCmpMojo.executeWithParameters(JApiCmpMojo.java:136)
at japicmp.maven.JApiCmpReport.executeReport(JApiCmpReport.java:71)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:255)
at
org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:230)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:349)
at
org.apache.maven.plugins.site.render.SiteMojo.renderLocale(SiteMojo.java:184)
at
org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:133)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)

[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 02:37 min
[INFO] Finished at: 2018-02-09T21:29:19+01:00
[INFO] Final Memory: 69M/858M
[INFO]

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site) on
project commons-compress: Error generating
japicmp-maven-plugin:0.11.0:cmp-report report: Failed to generate
report: Please provide at least one resolvable new version using one of
the configuration elements  or . -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the
-e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException


Am 07.02.2018 um 08:01 schrieb Stefan Bodewig:
> [now with fixed subject line, sorry]
> 
> I've again managed to mess up the OSGi manifest with Compress 1.16 so
> this is a quick bug fix release that doesn't contain any code changes.
> 
> Apart from the manifest fix I've updated zstd-jni to 

Re: [VOTE] Release Commons Compress 1.16 based on RC1

[Oliver Heger]

Hi,

build works fine with Java 1.7 and 1.8 on Windows 10. When building the
site I get the same error as mentioned by sebb. Artifacts and site look
good.

+1

Oliver

Am 02.02.2018 um 19:14 schrieb Stefan Bodewig:
> As indicated I think it is time to get Compress 1.16 out.
> 
> Compress 1.16 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/compress/ (svn revision 
> 24646)
> 
> The tag is here:
> 
> https://git-wip-us.apache.org/repos/asf?p=commons-compress.git;a=tag;h=ead7ce22ad9aae1d099bb920a5bd6968a62177ad
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1303/org/apache/commons/commons-compress/1.16/
> 
> These are the Maven artifacts and their sha256 hashes
> 
> 24aecd2a5223cf38fa438c789eb150bf87808dde225c9f199025af3a3bf5f2a8  
> commons-compress-1.16.jar
> a7e719e734e28c2b05ad97cde17491d76ed2f82bfdaa3445d2ab0a5108494fc5  
> commons-compress-1.16-javadoc.jar
> 2f6f535dbad8d3929204608d0c6bf81bd0f94782aa2df89129e3ca10d7f54943  
> commons-compress-1.16.pom
> 1472aca5ea66fe67c4dcde1a90667a3b0908b0f4ae56b55ef02f0b31f0709c82  
> commons-compress-1.16-sources.jar
> 6381b09dfff184da2454b5590b94807604e5d7ee72af6eea6573d3b8af518a78  
> commons-compress-1.16-tests.jar
> d963a9cc8e314de0aabc3d7adccf4bc8449223b50b97722a9c17c7bb34117677  
> commons-compress-1.16-test-sources.jar
> 
> I have tested this with JDK 8 ... using Maven 3
> 
> Details of changes since 1.15 are in the release notes:
> https://dist.apache.org/repos/dist/dev/commons/compress/RELEASE-NOTES.txt
> 
> https://stefan.samaflost.de/staging/commons-compress-1.16/changes-report.html
> 
> Site:
> https://stefan.samaflost.de/staging/commons-compress-1.16/
> 
> As usual when I cut a release this is not the site I'm going to
> publish. I'll publish a fresh site from master once the release date
> is known.
> 
> The download link and the link to the 1.16 javadocs are not expected
> to work.
> 
> japicmp Report (compared to 1.15):
> https://stefan.samaflost.de/staging/commons-compress-1.16/japicmp.html
> 
> Note that japicmp reports a source incompatible change to
> LZ77Compressor.Block that I consider OK as the class is only used
> internally and nobody is supposed to create subclasses outside of
> Commons Compress.
> 
> RAT Report:
> https://stefan.samaflost.de/staging/commons-compress-1.16/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. sometime after 19:00 UTC 05-March 2018
> 
>   [ ] +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-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] Create new component commons-signing

[Oliver Heger]

+1

Oliver

Am 02.02.2018 um 18:54 schrieb Mark Thomas:
> Hello all,
> 
> I propose that we create a new component [commons-signing].
> 
> The scope of the component is code signing utilities including, but not
> limited to, Ant and Maven plugins for the Symantec code signing service
> that a number of ASF projects use.
> 
> We'll work most things out as we go along but the rough plan at this
> stage is:
> 
> * git repo
> * start with the Symantec Ant task in Tomcat
> * add the Maven plugin from Sling
> * refactor out the duplicate code
> * first release
> 
> I'm leaning towards using GitHub issues rather than Jira.
> 
> Please review the proposal and vote. This vote will close no sooner that
> 72 hours from now.
> 
>   [ ] +1 Create the component
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this component because…
> 
> Cheers,
> 
> Mark
> 
> -
> 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: [RNG][All] Benign incompatibility (?)

[Oliver Heger]

Am 24.01.2018 um 14:29 schrieb Gilles:
> Ping?
> 
> More opinions, please (to avoid rehashing the issue at
> vote time).
> 
> Thanks,
> Gilles
> 
> On Mon, 15 Jan 2018 22:14:03 +0100, Gilles wrote:
>> On Mon, 15 Jan 2018 09:49:44 -0700, Gary Gregory wrote:
>>> Hi All,
>>>
>>> There are some many ways this can create jar hell now and in the future
>>> that I would not want to risk it. Binary compatibility is something we
>>> should strive for IMO. If this change is _that_ important, then it's 2.0
>>> time. Otherwise, don't break application stacks. Especially since
>>> Commons
>>> components tend to live at the bottom of such stacks. I see plenty of
>>> stacks out there for example, that include _both_ [lang] and [lang3],
>>> and
>>> that is _fine_.
>>
>> The point is that no correct application can be broken by this change.
>> Rather the contrary, with the prospective v1.1, failure will happen
>> at compile time (for incorrect application code that would have tried
>> to call base class methods), while v1.0 will happily compile (and then
>> raise a NPE).
>> Furthermore, in both cases, correct usage (i.e. calling the "sample"
>> method) will work the same, and as expected; no JAR hell whatsoever.
>>
>> The incompatible change is actually an improvement from a application
>> developer's POV.

A Clirr violation would be fine with me if it is addressed in the
release notes, and the probability of creating a jar hell scenario is
rather low.

Oliver


>>
>> Gilles
>>
>>>
>>> Gary
>>>
>>> On Mon, Jan 15, 2018 at 5:13 AM, Gilles 
>>> wrote:
>>>
 Hi.

 Please have a look at this issue on JIRA:
   https://issues.apache.org/jira/browse/RNG-46
 and confirm that a release won't be blocked by the
 current "clirr" report.

 Thanks,
 Gilles
> 
> 
> -
> 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: [configuration] Notifications from commons-configuration GitHub mirror

[Oliver Heger]

Am 15.01.2018 um 18:04 schrieb Oliver Heger:
> Hi,
> 
> Am 14.01.2018 um 00:33 schrieb Bindul Bhowmik:
>> Hello,
>>
>> It seems notifications from the commons-configuration GitHub mirror
>> are not setup to go to any commons mailing list.
>>
>> I opened a trivial pull request - #10 [1], but I don't see any emails
>> on any commons lists for this pull request [2] (well this thread will
>> show up on the search after it makes it to the archives :-))
>>
>> Similar searches for other commons components show emails, like [3] and [4].
> 
> thank you for the pull request - I will have a look.
> 
> Regarding missing mail notifications, I am not sure whether this could
> be caused by the fact that [configuration] still uses SVN and is not yet
> properly setup for a Github integration. Switching to Git is somewhere
> on my Todo list, but I have not yet found the time to do this.
> 
> Oliver

The patch has been applied in revision r1821751. I also republished the
web site, so that it shows now the correct version number.

Thanks again for the patch.

Oliver

> 
>>
>> Bindul
>>
>> [1] https://github.com/apache/commons-configuration/pull/10
>> [2] 
>> https://lists.apache.org/list.html?*@commons.apache.org:dfr=2018-1-11|dto=2018-1-13:apache/commons-configuration/pull/
>>
>> [3] 
>> https://lists.apache.org/list.html?*@commons.apache.org:dfr=2018-1-11|dto=2018-1-13:apache/commons-io/pull/
>> [4] 
>> https://lists.apache.org/list.html?*@commons.apache.org:dfr=2018-1-11|dto=2018-1-13:apache/commons-lang/pull/
>>
>> -
>> 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: [configuration] Notifications from commons-configuration GitHub mirror

[Oliver Heger]

Hi,

Am 14.01.2018 um 00:33 schrieb Bindul Bhowmik:
> Hello,
> 
> It seems notifications from the commons-configuration GitHub mirror
> are not setup to go to any commons mailing list.
> 
> I opened a trivial pull request - #10 [1], but I don't see any emails
> on any commons lists for this pull request [2] (well this thread will
> show up on the search after it makes it to the archives :-))
> 
> Similar searches for other commons components show emails, like [3] and [4].

thank you for the pull request - I will have a look.

Regarding missing mail notifications, I am not sure whether this could
be caused by the fact that [configuration] still uses SVN and is not yet
properly setup for a Github integration. Switching to Git is somewhere
on my Todo list, but I have not yet found the time to do this.

Oliver

> 
> Bindul
> 
> [1] https://github.com/apache/commons-configuration/pull/10
> [2] 
> https://lists.apache.org/list.html?*@commons.apache.org:dfr=2018-1-11|dto=2018-1-13:apache/commons-configuration/pull/
> 
> [3] 
> https://lists.apache.org/list.html?*@commons.apache.org:dfr=2018-1-11|dto=2018-1-13:apache/commons-io/pull/
> [4] 
> https://lists.apache.org/list.html?*@commons.apache.org:dfr=2018-1-11|dto=2018-1-13:apache/commons-lang/pull/
> 
> -
> 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: [release-plugin] release process (Was: Re: [VOTE] Release Commons Release Plugin 1.0 base on RC1)

[Oliver Heger]

Am 13.01.2018 um 15:36 schrieb Gilles:
> On Sat, 13 Jan 2018 08:48:19 -0500, Rob Tompkins wrote:
>> Given that right now we don’t have sufficient votes to release the
>> plugin, do folks want me to cancel this vote in leu of the lazy vote
>> process cleaning up the nits that folks have found? I’m curious since
>> folks don’t seem to have the appetite for this process.
> 
> ?
> 
> I don't think that anyone disagreed about "lazy" voting.
> So, you can do as you please.
> [IIUC, Gary is waiting for a release of the your new release
> plugin in order to attempt the release of a component.]

+1
Oliver

> 
> I surely am interested in the *idea* which I have about
> what you have been doing.  [I did not read a single line of
> the plugin code!  But I hope that it will solve the problem
> which I have exposed (about creating the distribution files
> for a modular project).

> 
> Regards,
> Gilles
> 
>>> On Jan 11, 2018, at 10:51 PM, Gary Gregory 
>>> wrote:
>>>
>>> Tangent: It just occurred to me that this could have helped in the
>>> process
>>> of developing this plugin:
>>> https://github.com/ok2c/httpcomponents-release-tools/wiki
>>>
>>> Gary
>>>
>>> On Thu, Jan 11, 2018 at 6:54 PM, Rob Tompkins 
>>> wrote:
>>>
 I had that quickly set up by adding

 ${dryRun}

 to the plugin configuration, but I admit  that’s a bit of a hack. I was
 just trying to be speedy in the first version of the plugin for folks’
 benefit.

> On Jan 11, 2018, at 7:25 PM, sebb  wrote:
>
>> On 11 January 2018 at 14:42, Rob Tompkins  wrote:
>> If you do try to run it locally make sure you add
>> true
>
> It would be useful to be able to define this on the command-line.
>
>> To the configuration section of the plugin.
>>
>>> On Jan 11, 2018, at 3:58 AM, Jörg Schaible <
 joerg.schai...@bpm-inspire.com> wrote:
>>>
>>> Am Wed, 10 Jan 2018 20:35:52 -0700 schrieb Gary Gregory:
>>>
 I wonder if:
 - This should be a LAZY VOTE since this is not an official
 component
 but
 rather a tool
>>>
>>> +1
>>>
 - We should release it as 1.0 anyway (unless obvious bugs
 are found) to avoid the chicken and egg problem: To really test
 this,
 I
 want to create an RC for Commons Collection (for example). But that
 means using a commons-release-plugin 1.0 version in my POM -
 which we
 cannot release as a repeatable build since 1.0 is not out yet. And
 cutting an RC with a 1.0-SNAPSHOT is not acceptable (not
 repeatable.)
>>>
>>> we might release 1.0-RC1 (or 0.1) as Sergio suggested.
>>>
>>> Cheers,
>>> Jörg
> 
> 
> -
> 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] Create new component commons-release-plugin

[Oliver Heger]

+1

Great work, Rob! Many thanks!

Oliver

Am 04.01.2018 um 17:56 schrieb Rob Tompkins:
> Hello all,
> 
> I propose that we create a new component [commons-release-plugin] to be 
> managed in the same fashion as the commons-build-plugin, and by that I mean:
> 
> * Use COMMONSSITE as the jira area
> * Create a git repo
> * Include it in the same portion of the site as the build-plugin (i.e. not a 
> formal component.
> 
> . Upon this vote completion (assuming it passes), I will create a git 
> repository and migrate the code that I have currently in 
> https://github.com/chtompki/commons-release-plugin 
>  into this repository.
> 
> Please review the release proposal and vote.
> This vote will close no sooner that 72 hours from now,
> i.e. sometime after 17:00 UTC 7-January 2018
> 
>   [ ] +1 Create the component
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this component because…
> 
> Cheers,
> -Rob
> 

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

Re: [VOTE] Release Apache Commons Pool 2.5.0 based on RC1

[Oliver Heger]

Build works fine with Java 1.7 and 1.8 on Windows 10. Artifacts and site
look good.

+1

Oliver

Am 16.12.2017 um 23:35 schrieb Gary Gregory:
> We have fixed quite a few bugs and added some  enhancements since Apache
> Commons Pool 2.4.3 was released, so I would like to release Apache Commons
> Pool 2.5.0.
> 
> Apache Commons Pool 2.5.0 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/pool/ (svn revision
> 23755)
> 
> The tag is here:
> 
> https://git-wip-us.apache.org/repos/asf?p=commons-pool.git;a=tag;h=dac29bd1ce13349fd989ca279df178ff73935d1d
> 
> Maven artifacts are here:
> https://repository.apache.org/content/repositories/orgapachecommons-1299
> 
> These are the Maven artifacts and their hashes
> 
> 
> /org/apache/commons/commons-pool2/2.5.0/commons-pool2-2.5.0.jar.asc
> (SHA1: 8c1f55975ebfef185209c12429f587bc1256636e)
> /org/apache/commons/commons-pool2/2.5.0/commons-pool2-2.5.0-javadoc.jar.asc
> (SHA1: 83d3316533c776413f2a0dd42526a6a31ac46e46)
> /org/apache/commons/commons-pool2/2.5.0/commons-pool2-2.5.0-sources.jar
> (SHA1: e2aae3697db27fd0de4d26c7d370e7d802eea3f6)
> /org/apache/commons/commons-pool2/2.5.0/commons-pool2-2.5.0.pom
> (SHA1: 2e13032776a6d3a641a58e1c1ea64bd605661130)
> /org/apache/commons/commons-pool2/2.5.0/commons-pool2-2.5.0-tests.jar
> (SHA1: af3d96706a0a45d143e5b479cfa8da8d3835ab47)
> /org/apache/commons/commons-pool2/2.5.0/commons-pool2-2.5.0-bin.zip.asc
> (SHA1: 3b54c00d08748dcbe7ab9a65d510bfa86f81f700)
> /org/apache/commons/commons-pool2/2.5.0/commons-pool2-2.5.0-tests.jar.asc
> (SHA1: 647578272eb02c850143965888f70d2e1d5e161e)
> /org/apache/commons/commons-pool2/2.5.0/commons-pool2-2.5.0-src.zip
> (SHA1: 6baf8c229e09252b3e158dcde61cfdbe21b31920)
> /org/apache/commons/commons-pool2/2.5.0/commons-pool2-2.5.0-sources.jar.asc
> (SHA1: 7671f1a41493442091a87bea06ded52efe149af8)
> /org/apache/commons/commons-pool2/2.5.0/commons-pool2-2.5.0.jar
> (SHA1: cb7d05e6308ad795decc4a12ede671113c11dd98)
> /org/apache/commons/commons-pool2/2.5.0/commons-pool2-2.5.0-javadoc.jar
> (SHA1: ca115b4c6777d03cd5e172c517e14010719dd9fd)
> /org/apache/commons/commons-pool2/2.5.0/commons-pool2-2.5.0-src.tar.gz
> (SHA1: bd4fbc00e7ce2d294ffeda9d12ebda5265ad2fe3)
> /org/apache/commons/commons-pool2/2.5.0/commons-pool2-2.5.0-src.zip.asc
> (SHA1: 9ec1d48c147e5646ff39b61d14c5abefac401edc)
> /org/apache/commons/commons-pool2/2.5.0/commons-pool2-2.5.0.pom.asc
> (SHA1: 39f587b18ec6df7dbf5341f1e7b9da6353400578)
> /org/apache/commons/commons-pool2/2.5.0/commons-pool2-2.5.0-bin.zip
> (SHA1: 43b1b0b5662696f701c2be63cfc2f42fbc8f238e)
> /org/apache/commons/commons-pool2/2.5.0/commons-pool2-2.5.0-test-sources.jar
> (SHA1: e7bfd87691e44a91c6ef19ba9076c1d7cc9f4147)
> /org/apache/commons/commons-pool2/2.5.0/commons-pool2-2.5.0-bin.tar.gz
> (SHA1: 00828dfb4830c2f69208d51e5db30737cbef44a3)
> /org/apache/commons/commons-pool2/2.5.0/commons-pool2-2.5.0-bin.tar.gz.asc
> (SHA1: 7b7e9ebfc54962aa5fd77b8847ac01caa527a644)
> /org/apache/commons/commons-pool2/2.5.0/commons-pool2-2.5.0-src.tar.gz.asc
> (SHA1: 09c73953f752cbe382ff862b15809e7c9be4ecd3)
> /org/apache/commons/commons-pool2/2.5.0/commons-pool2-2.5.0-test-sources.jar.asc
> (SHA1: 1a09c518ea54bc9e5792091fddcdccdc18b58b61)
> 
> I have tested 'mvn clean install' with:
> 
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T01:58:13-06:00)
> Maven home: C:\Java\apache-maven-3.5.2\bin\..
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_80\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"
> 
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T01:58:13-06:00)
> Maven home: C:\Java\apache-maven-3.5.2\bin\..
> Java version: 1.8.0_152, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_152\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> 
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T01:58:13-06:00)
> Maven home: C:\Java\apache-maven-3.5.2\bin\..
> Java version: 9.0.1, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-9.0.1
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> 
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T01:58:13-06:00)
> Maven home: C:\Java\apache-maven-3.5.2\bin\..
> Java version: 10-ea, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-10
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> Java(TM) SE Runtime Environment (build 10-ea+29)
> Java HotSpot(TM) 64-Bit Server VM (build 10-ea+29, mixed mode)
> 
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T01:58:13-06:00)
> Maven 

Re: [lang] Add a DaemonThreadFactory

[Oliver Heger]

Am 19.12.2017 um 17:27 schrieb Gary Gregory:
> I keep on copying this from project to project and it seems fitting for
> Commons Lang:

In the concurrent package, there is the BasicThreadFactory class. Could
this class satisfy your needs or can it be extended?

Oliver

> 
> import java.util.concurrent.ThreadFactory;
> import java.util.concurrent.atomic.AtomicLong;
> 
> public final class DaemonThreadFactory implements ThreadFactory {
> 
> private final static AtomicLong COUNT = new AtomicLong(1);
> 
> private final String name;
> 
> public DaemonThreadFactory(final String name) {
> super();
> this.name = name;
> }
> 
> @Override
> public Thread newThread(final Runnable r) {
> final Thread thread = new Thread(r, name + " " +
> COUNT.getAndIncrement());
> thread.setDaemon(true);
> return thread;
> }
> 
> }
> 
> Thoughts?
> 
> Gary
> 

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

Re: [VOTE] Release Commons JCS 2.2.1 based on RC3

[Oliver Heger]

Am 14.12.2017 um 01:38 schrieb Gary Gregory:
> On Wed, Dec 13, 2017 at 2:03 PM, Oliver Heger <oliver.he...@oliver-heger.de>
> wrote:
> 
>> Hi,
>>
>> thank you for your patience.
>>
>> Build works fine with Java 1.7 on Windows 10 (because of the Java 8
>> Javadoc errors I built the site with 1.7).
>>
>> I have some minor findings:
>> - As Bruno already noticed, the release notes contain this strange text.
>> - In README.md the current version for the dependency should be updated.
>> - The jars with the sources contain spurious folders.
>>
> 
> Can you be more specific please?

If you open for instance commons-jcs-core-2.2.1-sources.jar from the
binary distribution, the jar contains a folder with an empty name and
one empty folder named "commons-jcs-core-2.2.1-sources". The folder with
the empty name has a path of sub folders down to
commons-jcs-core-2.2.1-sources.jar\\tmp\commons-jcs-2.2.1-RC3\commons-jcs-core\target\classes\META-INF\

Oliver

> 
> Gary
> 
> 
>> - There are many Findbugs violations.
>>
>> The text in the release notes is really annoying, the other things are
>> not really blocking. But in total it prevents me from voting +1. So I am
>> rather +0.
>>
>> Oliver
>>
>> Am 13.12.2017 um 09:02 schrieb Romain Manni-Bucau:
>>> As discussed quite verbosely already I'd like to release JCS 2.2.1. I
>>> followed the commons procedure this time and hope it works for you.
>>>
>>> JCS 2.2.1 RC3 is available for review here:
>>> https://dist.apache.org/repos/dist/dev/commons/jcs/ (svn revision
>> 23702)
>>>
>>> The tag is here:
>>>
>>> http://svn.apache.org/repos/asf/commons/proper/jcs/tags/
>> commons-jcs-2.2.1-RC3/
>>> (svn revision 1817933)
>>>
>>> Maven artifacts are here:
>>> https://repository.apache.org/content/repositories/
>> orgapachecommons-1298
>>>
>>> I have tested this with JDK 7, 8 using Maven 3.5.0.
>>>
>>> Details of changes since 2.2 are in the release notes:
>>> https://dist.apache.org/repos/dist/dev/commons/jcs/RELEASE-NOTES.txt
>>>
>>> http://home.apache.org/~rmannibucau/commons-jcs-2.2.1-
>> RC3/changes-report.html
>>>
>>> Site:
>>> http://home.apache.org/~rmannibucau/commons-jcs-2.2.1-RC3/
>>>
>>> Clirr Report (compared to 2.2):
>>>
>>> http://home.apache.org/~rmannibucau/commons-jcs-2.2.1-
>> RC3/commons-jcs-core/clirr-report.html
>>>
>>> RAT Report:
>>>
>>> http://home.apache.org/~rmannibucau/commons-jcs-2.2.1-
>> RC3/rat-report.html
>>> (the zipcodes.txt file is intended to not have headers)
>>>
>>> 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. sometime after 08:15 UTC 16-December 2017
>>>
>>>   [ ] +1 Release these artifacts
>>>   [ ] +-0 Don't care
>>>   [ ] -1 I oppose this release ${because}
>>>
>>> Thanks!
>>> Romain
>>>
>>
>> -
>> 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 JCS 2.2.1 based on RC3

[Oliver Heger]

Hi,

thank you for your patience.

Build works fine with Java 1.7 on Windows 10 (because of the Java 8
Javadoc errors I built the site with 1.7).

I have some minor findings:
- As Bruno already noticed, the release notes contain this strange text.
- In README.md the current version for the dependency should be updated.
- The jars with the sources contain spurious folders.
- There are many Findbugs violations.

The text in the release notes is really annoying, the other things are
not really blocking. But in total it prevents me from voting +1. So I am
rather +0.

Oliver

Am 13.12.2017 um 09:02 schrieb Romain Manni-Bucau:
> As discussed quite verbosely already I'd like to release JCS 2.2.1. I
> followed the commons procedure this time and hope it works for you.
> 
> JCS 2.2.1 RC3 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/jcs/ (svn revision 23702)
> 
> The tag is here:
> 
> http://svn.apache.org/repos/asf/commons/proper/jcs/tags/commons-jcs-2.2.1-RC3/
> (svn revision 1817933)
> 
> Maven artifacts are here:
> https://repository.apache.org/content/repositories/orgapachecommons-1298
> 
> I have tested this with JDK 7, 8 using Maven 3.5.0.
> 
> Details of changes since 2.2 are in the release notes:
> https://dist.apache.org/repos/dist/dev/commons/jcs/RELEASE-NOTES.txt
> 
> http://home.apache.org/~rmannibucau/commons-jcs-2.2.1-RC3/changes-report.html
> 
> Site:
> http://home.apache.org/~rmannibucau/commons-jcs-2.2.1-RC3/
> 
> Clirr Report (compared to 2.2):
> 
> http://home.apache.org/~rmannibucau/commons-jcs-2.2.1-RC3/commons-jcs-core/clirr-report.html
> 
> RAT Report:
> 
> http://home.apache.org/~rmannibucau/commons-jcs-2.2.1-RC3/rat-report.html
> (the zipcodes.txt file is intended to not have headers)
> 
> 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. sometime after 08:15 UTC 16-December 2017
> 
>   [ ] +1 Release these artifacts
>   [ ] +-0 Don't care
>   [ ] -1 I oppose this release ${because}
> 
> Thanks!
> Romain
> 

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

Re: [VOTE] Release Apache Commons RDF 0.5.0 based on RC3

[Oliver Heger]

Hi,

build works fine with Java 8 on Windows 10. Artifacts look good.

I am still not able to build the site locally; I get the error below.
Can you somehow provide a zip with the site for inspection?

Thanks
Oliver

[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 47.759 s
[INFO] Finished at: 2017-12-09T21:20:00+01:00
[INFO] Final Memory: 63M/662M
[INFO]

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.6:site (default-site) on
project commons-rdf-parent: Error generating
maven-checkstyle-plugin:2.12.1:checkstyle-aggregate: Failed during
checkstyle configuration: cannot initialize module TreeWalker - Property
'ignoreAnnotationCanonicalNames' in module VisibilityModifier does not
exist, please check the documentation -> [Help 1]
[ERROR]

$ mvn --version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T17:41:47+01:00)
Maven home: C:\data\dev\tools\apache-maven-3.3.9
Java version: 1.8.0_144, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_144\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos"


Am 08.12.2017 um 05:51 schrieb Sergio Fernández:
> Hi,
> 
> once we addressed most of the issues from RC1 and RC2, I'd like to propose
> to release Apache Commons RDF 0.5.0 based on RC.
> 
> Apache Commons RDF aims to provide a common Java API for RDF 1.1 graphs and
> datasets. API bindings in Commons RDF 0.5.0 include Apache Jena, Eclipse
> RDF4J, JSON-LD Java as well as a standalone implementation (simple).
> 
> Apache Commons RDF 0.5.0 RC3 is available for review at (r23441):
> 
> https://dist.apache.org/repos/dist/dev/commons/rdf/apache-
> commons-rdf-0.5.0-RC3/
> 
> The source code for this RC is available from git tagged as 0.5.0-RC3
> (commit e82eaa0b7d67f5a1afdf4cdecc19589fbe1654d6):
> 
> https://git-wip-us.apache.org/repos/asf?p=commons-rdf.git;a=commit;h=
> e82eaa0b7d67f5a1afdf4cdecc19589fbe1654d6
> 
> Mirrored at https://github.com/apache/commons-rdf/commit/
> e82eaa0b7d67f5a1afdf4cdecc19589fbe1654d6
> 
> This source release produces the following binary artifacts:
> 
> commons-rdf-parent-0.5.0
> commons-rdf-api-0.5.0
> commons-rdf-simple-0.5.0
> commons-rdf-jena-0.5.0
> commons-rdf-rdf4j-0.5.0
> commons-rdf-jsonld-java-0.5.0
> commons-rdf-integration-tests-0.5.0
> 
> The Maven Staging repository can be found at:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1295
> 
> containing the following artifacts:
> 
> commons-rdf-rdf4j-0.5.0.pom (SHA1: 1cdc74b7205fa06531bd59e1ee24f1d15999ab1b)
> commons-rdf-rdf4j-0.5.0.jar (SHA1: 265549b98b423c075f4a186dec76efb815c03649)
> commons-rdf-rdf4j-0.5.0-tests.jar (SHA1:
> 9aab05dceefde27d79bc79f4b3c80daeeb01cb52)
> commons-rdf-rdf4j-0.5.0-javadoc.jar (SHA1:
> 4254ac42dd569a45ab3b95c3d16cb8f47508039a)
> commons-rdf-rdf4j-0.5.0-test-sources.jar (SHA1:
> 39eb4a6b10cafa4cfb87b4e48827006332ceaed3)
> commons-rdf-rdf4j-0.5.0-sources.jar (SHA1:
> f8a0ea29f31f501df05686abfd171f35fd39ed71)
> commons-rdf-api-0.5.0-sources.jar (SHA1:
> 02735a136e206408f75507fbf27af1230a99f61b)
> commons-rdf-api-0.5.0.jar (SHA1: df2d4451dee5b311cb4f51ced214dfaab5838291)
> commons-rdf-api-0.5.0-tests.jar (SHA1:
> 025730515d0e66043b6483710a9638e1f71ff917)
> commons-rdf-api-0.5.0-javadoc.jar (SHA1:
> 3e15be3c7d018225aa6bafd91861474780c3ad8e)
> commons-rdf-api-0.5.0-test-sources.jar (SHA1:
> 5f2554c926de52b5661f430b69c92dac2056a029)
> commons-rdf-api-0.5.0.pom (SHA1: cc3382c3a60d815a20bba1763933434f41d85598)
> commons-rdf-simple-0.5.0-tests.jar (SHA1:
> 472e43e582ddcf1a7f06f9184f4bf26fad3b65fc)
> commons-rdf-simple-0.5.0.pom (SHA1:
> b5aa51f49cbbdb9f39fa70d8cf183f63ae0c3a6a)
> commons-rdf-simple-0.5.0-javadoc.jar (SHA1:
> 87941fc168b6011fb003288eb392577fc4519be0)
> commons-rdf-simple-0.5.0-sources.jar (SHA1:
> 7232c14775db216efc85a1a7fabb90c6a456950c)
> commons-rdf-simple-0.5.0.jar (SHA1:
> c6b5038624d860129e273538d18dd52c5adcfd70)
> commons-rdf-simple-0.5.0-test-sources.jar (SHA1:
> 8028e8f20ebc465a6cd5a32fd9b8447eb4cf48dc)
> commons-rdf-parent-0.5.0-src.tar.gz (SHA1:
> 5b3788cb6b647f3663839fd0737a5a85a75d19fa)
> commons-rdf-parent-0.5.0-src.zip (SHA1:
> 519891322ed75f3ae4ef5cf7e8df60c65b797634)
> commons-rdf-parent-0.5.0.pom (SHA1:
> 4186153db162b4382f73be1ce2ff97a98ee5d442)
> commons-rdf-parent-0.5.0-site.xml (SHA1:
> 26fd1dc487f5f002d35841ba8dcc53704652d3b8)
> commons-rdf-integration-tests-0.5.0-test-sources.jar (SHA1:
> d7ad7ad0c09c3ae46d8da9c1ed989a9615369dcf)
> commons-rdf-integration-tests-0.5.0-tests.jar (SHA1:
> 0db5cb5a32afcad51decae42c6a7d4dc7e62f15a)
> commons-rdf-integration-tests-0.5.0.pom (SHA1:
> dc8b7754e2069b8c19c507a59a665ba12fd60007)
> commons-rdf-jena-0.5.0.pom (SHA1: 

Re: [VOTE] Release Apache Commons BCEL based on RC1

[Oliver Heger]

Am 06.12.2017 um 22:26 schrieb Gary Gregory:
> Oliver, how do you feel about installing Java 9 and trying again?
> 
> Gary
> 
> On Tue, Dec 5, 2017 at 1:48 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
> 
>> The test calls the registryGetKeys Windows API and that throws an
>> exception because Java 9 is not installed on that machine. This is a bug in
>> the test only. Fixed in trunk. Not a showstopper IMO.
>>
>> Gary

Agreed that this is not a blocker. Artifacts and site look good. You
will probably update the Release Information section on index.html.
There are some checkstyle and findbugs finding, but I assume nothing new
or critical.

So +1

Oliver

>>
>> On Sun, Dec 3, 2017 at 1:44 PM, Oliver Heger <oliver.he...@oliver-heger.de
>>> wrote:
>>
>>> Here is the stack trace:
>>>
>>> 
>>> ---
>>> Test set: org.apache.bcel.generic.JDKGenericDumpTestCase
>>> 
>>> ---
>>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.657
>>> sec <<< FAILURE! - in org.apache.bcel.generic.JDKGenericDumpTestCase
>>> initializationError(org.apache.bcel.generic.JDKGenericDumpTestCase)
>>> Time elapsed: 0 sec  <<< ERROR!
>>> com.sun.jna.platform.win32.Win32Exception: Das System kann die
>>> angegebene Datei nicht finden.
>>> at
>>> org.apache.bcel.generic.JDKGenericDumpTestCase.addAllJavaHom
>>> esOnWindows(JDKGenericDumpTestCase.java:65)
>>> at
>>> org.apache.bcel.generic.JDKGenericDumpTestCase.findJavaHomes
>>> OnWindows(JDKGenericDumpTestCase.java:97)
>>> at
>>> org.apache.bcel.generic.JDKGenericDumpTestCase.findJavaHomes
>>> (JDKGenericDumpTestCase.java:87)
>>> at
>>> org.apache.bcel.generic.JDKGenericDumpTestCase.data(JDKGener
>>> icDumpTestCase.java:82)
>>>
>>> Oliver
>>>
>>> Am 03.12.2017 um 16:58 schrieb Gary Gregory:
>>>> Do you have a full stack trace? It smells like the code that looks for
>>> JDK
>>>> and JRE locations is failing.
>>>>
>>>> Gary
>>>>
>>>> On Dec 3, 2017 08:33, "Oliver Heger" <oliver.he...@oliver-heger.de>
>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> when building on Windows 10 with both Java 1.7 and 1.8 I get the test
>>>>> failure below. Does anybody else see this?
>>>>>
>>>>> Oliver
>>>>>
>>>>> Results :
>>>>>
>>>>> Tests in error:
>>>>>
>>>>> JDKGenericDumpTestCase.data:82->findJavaHomes:87->
>>>>> findJavaHomesOnWindows:97->addAllJavaHomesOnWindows:65
>>>>> ▒ Win32
>>>>>
>>>>> Tests run: 107, Failures: 0, Errors: 1, Skipped: 0
>>>>>
>>>>> $ mvn --version
>>>>> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
>>>>> 2015-11-10T17:41:47+01:00)
>>>>> Maven home: C:\data\dev\tools\apache-maven-3.3.9
>>>>> Java version: 1.8.0_144, vendor: Oracle Corporation
>>>>> Java home: C:\Program Files\Java\jdk1.8.0_144\jre
>>>>> Default locale: de_DE, platform encoding: Cp1252
>>>>> OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos"
>>>>>
>>>>>
>>>>> Am 01.12.2017 um 05:17 schrieb Gary Gregory:
>>>>>> We fixed a few bugs and added some enhancements since we released
>>> Apache
>>>>>> Commons BCEL 6.1, so I would like to release Commons BCEL 6.2.
>>>>>>
>>>>>> Commons BCEL 6.2 RC1 is available for review here:
>>>>>> https://dist.apache.org/repos/dist/dev/commons/bcel at svn
>>> revision:
>>>>>> 23349
>>>>>>
>>>>>> The tag is here:
>>>>>> http://svn.apache.org/repos/asf/commons/proper/bcel/tags/
>>>>> BCEL_6_2_RC1/
>>>>>> (svn revision 1816763)
>>>>>> N.B. the SVN revision is required because SVN tags are not
>>> immutable.
>>>>>>
>>>>>> Maven artifacts are here:
>>>>>> https://repository.apache.org/content/repositories/
>>>>> orgapache

Re: [VOTE] Release Apache Commons BCEL based on RC1

[Oliver Heger]

Here is the stack trace:

---
Test set: org.apache.bcel.generic.JDKGenericDumpTestCase
---
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.657
sec <<< FAILURE! - in org.apache.bcel.generic.JDKGenericDumpTestCase
initializationError(org.apache.bcel.generic.JDKGenericDumpTestCase)
Time elapsed: 0 sec  <<< ERROR!
com.sun.jna.platform.win32.Win32Exception: Das System kann die
angegebene Datei nicht finden.
at
org.apache.bcel.generic.JDKGenericDumpTestCase.addAllJavaHomesOnWindows(JDKGenericDumpTestCase.java:65)
at
org.apache.bcel.generic.JDKGenericDumpTestCase.findJavaHomesOnWindows(JDKGenericDumpTestCase.java:97)
at
org.apache.bcel.generic.JDKGenericDumpTestCase.findJavaHomes(JDKGenericDumpTestCase.java:87)
at
org.apache.bcel.generic.JDKGenericDumpTestCase.data(JDKGenericDumpTestCase.java:82)

Oliver

Am 03.12.2017 um 16:58 schrieb Gary Gregory:
> Do you have a full stack trace? It smells like the code that looks for JDK
> and JRE locations is failing.
> 
> Gary
> 
> On Dec 3, 2017 08:33, "Oliver Heger" <oliver.he...@oliver-heger.de> wrote:
> 
>> Hi,
>>
>> when building on Windows 10 with both Java 1.7 and 1.8 I get the test
>> failure below. Does anybody else see this?
>>
>> Oliver
>>
>> Results :
>>
>> Tests in error:
>>
>> JDKGenericDumpTestCase.data:82->findJavaHomes:87->
>> findJavaHomesOnWindows:97->addAllJavaHomesOnWindows:65
>> ▒ Win32
>>
>> Tests run: 107, Failures: 0, Errors: 1, Skipped: 0
>>
>> $ mvn --version
>> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
>> 2015-11-10T17:41:47+01:00)
>> Maven home: C:\data\dev\tools\apache-maven-3.3.9
>> Java version: 1.8.0_144, vendor: Oracle Corporation
>> Java home: C:\Program Files\Java\jdk1.8.0_144\jre
>> Default locale: de_DE, platform encoding: Cp1252
>> OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos"
>>
>>
>> Am 01.12.2017 um 05:17 schrieb Gary Gregory:
>>> We fixed a few bugs and added some enhancements since we released Apache
>>> Commons BCEL 6.1, so I would like to release Commons BCEL 6.2.
>>>
>>> Commons BCEL 6.2 RC1 is available for review here:
>>> https://dist.apache.org/repos/dist/dev/commons/bcel at svn revision:
>>> 23349
>>>
>>> The tag is here:
>>> http://svn.apache.org/repos/asf/commons/proper/bcel/tags/
>> BCEL_6_2_RC1/
>>> (svn revision 1816763)
>>> N.B. the SVN revision is required because SVN tags are not immutable.
>>>
>>> Maven artifacts are here:
>>> https://repository.apache.org/content/repositories/
>> orgapachecommons-1294
>>>
>>> These are the Maven artifacts and their hashes
>>>
>>> /org/apache/bcel/bcel/6.2/bcel-6.2-test-sources.jar
>>> (SHA1: feef9dc39b67bf76d90a16abf3b5711d894bdafc)
>>> /org/apache/bcel/bcel/6.2/bcel-6.2.jar.asc
>>> (SHA1: 10911db34eabbf5ed77175147d890431815a66e9)
>>> /org/apache/bcel/bcel/6.2/bcel-6.2-tests.jar.asc
>>> (SHA1: dd32ec245d2d664ee69a70bde304df5f577c3e8b)
>>> /org/apache/bcel/bcel/6.2/bcel-6.2-src.tar.gz.asc
>>> (SHA1: 1b6562ffec86267c8d1935dc1fa33c0fd225a094)
>>> /org/apache/bcel/bcel/6.2/bcel-6.2-bin.tar.gz.asc
>>> (SHA1: b7c31d213469b4044361b780890732f67859ec7e)
>>> /org/apache/bcel/bcel/6.2/bcel-6.2-bin.zip.asc
>>> (SHA1: 7137b7dfbc135aed1b2f8c7c974289e5ad645e3b)
>>> /org/apache/bcel/bcel/6.2/bcel-6.2-tests.jar
>>> (SHA1: 9de7ca4bbce76f7a877700ffc88bc2e36ef065ea)
>>> /org/apache/bcel/bcel/6.2/bcel-6.2-javadoc.jar
>>> (SHA1: 6eba2e55001a6093c8a9aa72132385e93fbe09d3)
>>> /org/apache/bcel/bcel/6.2/bcel-6.2-sources.jar
>>> (SHA1: df05f2afa0f58aefe5c3344fc67295ffc2050d53)
>>> /org/apache/bcel/bcel/6.2/bcel-6.2-test-sources.jar.asc
>>> (SHA1: 4999bb9f6d5ad677f13f1e5e856f8a76fdf3c8fc)
>>> /org/apache/bcel/bcel/6.2/bcel-6.2.pom.asc
>>> (SHA1: 6fd1c5c4fbc96b83f06c421a99fc3ee7f975c310)
>>> /org/apache/bcel/bcel/6.2/bcel-6.2.jar
>>> (SHA1: 2c1499b28bf2638cbdb5fa94350d41a46d2bd4e0)
>>> /org/apache/bcel/bcel/6.2/bcel-6.2-bin.tar.gz
>>> (SHA1: 9116cfccfb5f55a5a9e46fb685c7aa344712d52e)
>>> /org/apache/bcel/bcel/6.2/bcel-6.2-src.zip.asc
>>> (SHA1: 4b86e83b5c0dcd0e3abe86fda7ff5a9aaa1ab67d)
>>> /org/apache/bcel/bcel/6.2/bcel-6.2-bin.zip
>>> (SHA1: 95e19

Re: [VOTE] Release Apache Commons BCEL based on RC1

[Oliver Heger]

Hi,

when building on Windows 10 with both Java 1.7 and 1.8 I get the test
failure below. Does anybody else see this?

Oliver

Results :

Tests in error:

JDKGenericDumpTestCase.data:82->findJavaHomes:87->findJavaHomesOnWindows:97->addAllJavaHomesOnWindows:65
▒ Win32

Tests run: 107, Failures: 0, Errors: 1, Skipped: 0

$ mvn --version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T17:41:47+01:00)
Maven home: C:\data\dev\tools\apache-maven-3.3.9
Java version: 1.8.0_144, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_144\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos"


Am 01.12.2017 um 05:17 schrieb Gary Gregory:
> We fixed a few bugs and added some enhancements since we released Apache
> Commons BCEL 6.1, so I would like to release Commons BCEL 6.2.
> 
> Commons BCEL 6.2 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/bcel at svn revision:
> 23349
> 
> The tag is here:
> http://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_2_RC1/
> (svn revision 1816763)
> N.B. the SVN revision is required because SVN tags are not immutable.
> 
> Maven artifacts are here:
> https://repository.apache.org/content/repositories/orgapachecommons-1294
> 
> These are the Maven artifacts and their hashes
> 
> /org/apache/bcel/bcel/6.2/bcel-6.2-test-sources.jar
> (SHA1: feef9dc39b67bf76d90a16abf3b5711d894bdafc)
> /org/apache/bcel/bcel/6.2/bcel-6.2.jar.asc
> (SHA1: 10911db34eabbf5ed77175147d890431815a66e9)
> /org/apache/bcel/bcel/6.2/bcel-6.2-tests.jar.asc
> (SHA1: dd32ec245d2d664ee69a70bde304df5f577c3e8b)
> /org/apache/bcel/bcel/6.2/bcel-6.2-src.tar.gz.asc
> (SHA1: 1b6562ffec86267c8d1935dc1fa33c0fd225a094)
> /org/apache/bcel/bcel/6.2/bcel-6.2-bin.tar.gz.asc
> (SHA1: b7c31d213469b4044361b780890732f67859ec7e)
> /org/apache/bcel/bcel/6.2/bcel-6.2-bin.zip.asc
> (SHA1: 7137b7dfbc135aed1b2f8c7c974289e5ad645e3b)
> /org/apache/bcel/bcel/6.2/bcel-6.2-tests.jar
> (SHA1: 9de7ca4bbce76f7a877700ffc88bc2e36ef065ea)
> /org/apache/bcel/bcel/6.2/bcel-6.2-javadoc.jar
> (SHA1: 6eba2e55001a6093c8a9aa72132385e93fbe09d3)
> /org/apache/bcel/bcel/6.2/bcel-6.2-sources.jar
> (SHA1: df05f2afa0f58aefe5c3344fc67295ffc2050d53)
> /org/apache/bcel/bcel/6.2/bcel-6.2-test-sources.jar.asc
> (SHA1: 4999bb9f6d5ad677f13f1e5e856f8a76fdf3c8fc)
> /org/apache/bcel/bcel/6.2/bcel-6.2.pom.asc
> (SHA1: 6fd1c5c4fbc96b83f06c421a99fc3ee7f975c310)
> /org/apache/bcel/bcel/6.2/bcel-6.2.jar
> (SHA1: 2c1499b28bf2638cbdb5fa94350d41a46d2bd4e0)
> /org/apache/bcel/bcel/6.2/bcel-6.2-bin.tar.gz
> (SHA1: 9116cfccfb5f55a5a9e46fb685c7aa344712d52e)
> /org/apache/bcel/bcel/6.2/bcel-6.2-src.zip.asc
> (SHA1: 4b86e83b5c0dcd0e3abe86fda7ff5a9aaa1ab67d)
> /org/apache/bcel/bcel/6.2/bcel-6.2-bin.zip
> (SHA1: 95e191ca708c0187292dbef4fe42fd60f52d1d1a)
> /org/apache/bcel/bcel/6.2/bcel-6.2-sources.jar.asc
> (SHA1: 7e36d6e1ba882adf877306940184732f49c0385b)
> /org/apache/bcel/bcel/6.2/bcel-6.2-javadoc.jar.asc
> (SHA1: bee5e89f33d3e29d0d2c2d6ab6c56e0c06f0d20c)
> /org/apache/bcel/bcel/6.2/bcel-6.2-src.tar.gz
> (SHA1: 496c6f58f74ae55f513ed14c7268833289649236)
> /org/apache/bcel/bcel/6.2/bcel-6.2.pom
> (SHA1: 3932199e50571760ae8acdd0f153a32891b5696c)
> /org/apache/bcel/bcel/6.2/bcel-6.2-src.zip
> (SHA1: 42c1b8e8ae6d3dafc56ae9c05c3f3ca0819c782c)
> 
> I have tested this with Oracle Java 7 using Maven 3.5.2 on Windows 10.
> 
> Details of changes since 6.1 are in the release notes:
> https://dist.apache.org/repos/dist/dev/commons/bcel/RELEASE-NOTES.txt
> 
> 
> Site:
> https://people.apache.org/~ggregory/commons-bcel-3.2-RC1-site.zip
>   (note some *relative* links are broken and the 1.2 directories are
>   not yet created - these will be OK once the site is deployed)
> 
> The Clirr and RAT Reports (compared to 6.1) are in the zipped site.
> 
> 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, sometime after 05:00 UTC 4-December 2017
> 
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
> 
> Thanks!
> 
> Gary Gregory,
> Apache Commons PMC Chair
> 

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

Re: [VOTE] Release Apache Commons RDF 0.5.0 based on RC2

[Oliver Heger]

Hi Sergio,

build works fine with Java 1.8 on Windows 10. However, the site build
fails for me with the following error:

[INFO]

[INFO] Reactor Summary:
[INFO]
[INFO] Commons RDF  FAILURE [
52.831 s]
[INFO] Commons RDF API  SKIPPED
[INFO] Commons RDF impl: Simple ... SKIPPED
[INFO] Commons RDF impl: RDF4j  SKIPPED
[INFO] Commons RDF impl: Jena . SKIPPED
[INFO] Commons RDF impl: JSON-LD Java . SKIPPED
[INFO] Commons RDF Integration tests .. SKIPPED
[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 55.134 s
[INFO] Finished at: 2017-11-22T22:19:47+01:00
[INFO] Final Memory: 65M/703M
[INFO]

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.6:site (default-cli) on
project commons-rdf-parent: Error generating
maven-checkstyle-plugin:2.12.1:checkstyle-aggregate: Failed during
checkstyle configuration: cannot initialize module TreeWalker - Property
'ignoreAnnotationCanonicalNames' in module VisibilityModifier does not
exist, please check the documentation -> [Help 1]

A problem with the version of the checkstyle plugin?

Some other notes:
* NOTICE has the wrong copyright year. I think this needs to be fixed.
* The project does not release binary artifacts. This is probably okay,
but unusual for Commons. It would be nice if you could add a binary
distribution - maybe for the 1.0 release.

Thanks
Oliver

Am 19.11.2017 um 23:08 schrieb Sergio Fernández:
> Hi,
> 
> once we addressed most of the issues from RC1, I'd like to propose to
> release Apache Commons RDF 0.5.0 based on RC2.
> 
> Apache Commons RDF aims to provide a common Java API for RDF 1.1 graphs and
> datasets. API bindings in Commons RDF 0.5.0 include Apache Jena, Eclipse
> RDF4J, JSON-LD Java as well as a standalone implementation (simple).
> 
> Apache Commons RDF 0.5.0 RC2 is available for review at (r23205):
> 
> https://dist.apache.org/repos/dist/dev/commons/rdf/apache-commons-rdf-0.5.0-RC2/
> 
> The source code for this RC is available from git tagged as 0.5.0-RC2
> (commit 186df0c36981a308338792f02d93fc59776b0b7c):
> 
> https://git-wip-us.apache.org/repos/asf?p=commons-rdf.git;a=commit;h=186df0c36981a308338792f02d93fc59776b0b7c
> 
> Mirrored at
> https://github.com/apache/commons-rdf/commit/186df0c36981a308338792f02d93fc59776b0b7c
> 
> This source release produces the following binary artifacts:
> 
> commons-rdf-parent-0.5.0
> commons-rdf-api-0.5.0
> commons-rdf-simple-0.5.0
> commons-rdf-jena-0.5.0
> commons-rdf-rdf4j-0.5.0
> commons-rdf-jsonld-java-0.5.0
> commons-rdf-integration-tests-0.5.0
> 
> The Maven Staging repository can be found at:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1293
> 
> Please vote on releasing this release candidate as:
> 
> Apache Commons RDF 0.5.0
> 
> The vote is open for at least 72 hours/
> 
> [ ] +1 Release this package
> [ ] 0 I don't feel strongly about it, but don't object
> [ ] -1 Do not release this package because...
> 
> Anyone can participate in testing and voting, not just committers,
> please feel free to try out the release candidate and provide your
> votes!
> 
> Thanks
> 

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

Re: Fwd: [jira] [Resolved] (CONFIGURATION-675) Add .gitignore file

[Oliver Heger]

Am 11.11.2017 um 21:22 schrieb Gary Gregory:
> I do not think we need a JIRA for this kind of housekeeping...

Agreed. However, in this case, the ticket has been created externally,
and I just followed the normal workflow to resolve it.

Oliver

> 
> Gary
> -- Forwarded message ------
> From: Oliver Heger (JIRA) <j...@apache.org>
> Date: Sat, Nov 11, 2017 at 8:24 AM
> Subject: [jira] [Resolved] (CONFIGURATION-675) Add .gitignore file
> To: iss...@commons.apache.org
> 
> 
> 
>  [ https://issues.apache.org/jira/browse/CONFIGURATION-675?
> page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
> 
> Oliver Heger resolved CONFIGURATION-675.
> 
>Resolution: Fixed
> Fix Version/s: 2.3
> 
> Copied the .gitignore file from Commons Lang. Fixed in SVN in revision
> 1814959.
> 
>> Add .gitignore file
>> ---
>>
>> Key: CONFIGURATION-675
>> URL: https://issues.apache.org/
> jira/browse/CONFIGURATION-675
>> Project: Commons Configuration
>>  Issue Type: Improvement
>>  Components: Build
>>Reporter: mingleizhang
>>Priority: Blocker
>> Fix For: 2.3
>>
>>
>> Add .gitignore to this project
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v6.4.14#64029)
> 

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

Re: Which is the best common project to put this code ? Configuration or Collections ?

[Oliver Heger]

Hi,

thanks for your contribution. See below...

Am 06.11.2017 um 12:48 schrieb mingleizhang:
> Hello experts
> 
> 
> I implemented a tool that can directly read a file name by its current 
> classloader read an Inputstream and returns a java.util.Properties and 
> created two JIRA for this issue as I am not sure which components are the 
> best. The code and the conversions are here: 
> https://github.com/apache/commons-collections/pull/33/files 
> 
> 
> Why did I do this ?
> Before contributing this,  I searched for a long time for this functionality 
> in Commons Configuration. I could not find it though. I don't want to write 
> it in my way, instead, I want there is an existing lib that implements it. 
> So, that is why I did this contribution.
> 
> 
> If I should put it in Commons Configuration. Which package should I put it 
> to? 

Commons Configuration does not work with Properties. The project defines
its own configuration interface and provides means to read
configurations in various formats from different sources. The very
specific functionality to load a Properties object does not really fit
here IMHO.

In general, I am not sure whether this code belongs in a low-level and
general-purpose library. It implements a very special use case, to read
a properties file from the class path. It may also be possible to
interpret the passed in string as a path to a file and load the data
from there.

My $0.02
Oliver

> 
> 
> Two jira
> https://issues.apache.org/jira/browse/CONFIGURATION-674
> https://issues.apache.org/jira/browse/COLLECTIONS-664
> 
> 
> Thanks
> Minglei
> 

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

Re: [VOTE] Release Apache Commons Lang 3.7 based on RC1

[Oliver Heger]

Build works fine with Java 1.7 and 1.8 on Windows 10. Artifacts and site
look good.

+1

Oliver

Am 04.11.2017 um 19:50 schrieb Gary Gregory:
> We have fixed a few bugs since Apache Commons Lang 3.6 was released, so I
> would like to release Apache Commons Lang 3.7.
> 
> Apache Commons Lang 3.7 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/lang at revision: 22853
> Get it like this: svn co
> https://dist.apache.org/repos/dist/dev/commons/lang
> 
> The tag is here:
> 
> https://git-wip-us.apache.org/repos/asf?p=commons-lang.git;a=tag;h=refs/tags/LANG_3_7_RC1
> object 425d8085cfcaab5a78bf0632f9ae77b7e9127cf8
> 
> Maven artifacts are here:
> https://repository.apache.org/content/repositories/orgapachecommons-1288
> 
> These are the artifacts and their SHA1 hashes:
> 
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-test-sources.jar.asc
> (SHA1: b9d6588eba0ee1cef9edf51283bf2004fcb71238)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-tests.jar.asc
> (SHA1: e300353ba37288f4308534c38488792a57e52e3b)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-src.zip
> (SHA1: 6316036a39e10dc61f7996672af13be0cddd03d5)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-sources.jar
> (SHA1: e7e36219edde1c66c93495a75490d8f526c377cb)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-javadoc.jar.asc
> (SHA1: deba56c5874a5c023ad209f0d7b9f7690830a6fd)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-src.zip.asc
> (SHA1: 31f67cddf7f5bb5a933dcd2667da8af3a86c40ef)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-bin.zip.asc
> (SHA1: dcee70c101432b6a61ec03f3282cf3512c61645d)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-tests.jar
> (SHA1: e2b2ef23bf522cbfa9c49a905fb278ba1fd4eadb)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-bin.tar.gz.asc
> (SHA1: ee9f3adcbe2b7bb93f1300ec843c9d3f25d215db)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-test-sources.jar
> (SHA1: f51e03bffa2fd21efa309e562213803b38d3b5b2)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-src.tar.gz.asc
> (SHA1: 7019c1310c9dcba3375ef03ea509b9caa2de8f6c)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-sources.jar.asc
> (SHA1: 2bb88579e6ced65c30a9f5615f4a83584edba0ce)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-bin.tar.gz
> (SHA1: b7ff9054614d9a3c58798fe93cab468b241b8496)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7.pom
> (SHA1: c445be3b6442b41cbea539d4218be3aea9428a55)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7.jar
> (SHA1: 557edd918fd41f9260963583ebf5a61a43a6b423)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-src.tar.gz
> (SHA1: 1027d100c5099634a244a9c517e304518507c466)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-javadoc.jar
> (SHA1: 08d6fb4d39bedef08da171550c73b5d84e8c1125)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7.pom.asc
> (SHA1: 43481d694125cced7ebba307634d716c96229c69)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-bin.zip
> (SHA1: 18f12e2e26b820ec1680889c3afa0c6a9f65b68a)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7.jar.asc
> (SHA1: cdcce5ca9a5df3ee087148c815266ba8567ea7aa)
> 
> I tested this RC using 'mvn clean verify' on Microsoft Windows [Version
> 10.0.16299.19] with:
> 
> - Oracle Java 7
> - Oracle Java 8
> - Oracle Java 9
> - Oracle Java 10 EA b29
> - IBM Java 8
> 
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T01:58:13-06:00)
> Maven home: C:\Java\apache-maven-3.5.2\bin\..
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_80\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"
> 
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T01:58:13-06:00)
> Maven home: C:\Java\apache-maven-3.5.2\bin\..
> Java version: 1.8.0_152, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_152\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> 
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T01:58:13-06:00)
> Maven home: C:\Java\apache-maven-3.5.2\bin\..
> Java version: 9.0.1, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-9.0.1
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> 
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T01:58:13-06:00)
> Maven home: C:\Java\apache-maven-3.5.2\bin\..
> Java version: 10-ea, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-10
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> 
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 

Re: [jelly] Site build and Jellydoc plugin

[Oliver Heger]

Am 02.11.2017 um 00:33 schrieb Bruno P. Kinoshita:
> I think it may be worth to try to get in touch with Kohsuke. He became the 
> CTO of CloudBees some time ago, but is still involved in the project (not 
> writing as much code as before) mainly with decisions, and eventual pull 
> request review.
> You can find him sometimes on IRC / FreeNode, in the jenkins channel. But 
> given how busy he might be, probably dropping him an e-mail and waiting a bit 
> more might be a better idea.
> 
> Hope that helpsBruno

The PR is about 1.5 weeks old, so we should still give him some more time.

Do you know him in person, Bruno? Or did you have contact with him in
the past?

Thanks
Oliver

> 
>   From: Oliver Heger <oliver.he...@oliver-heger.de>
>  To: Commons Developers List <dev@commons.apache.org> 
>  Sent: Thursday, 2 November 2017 9:34 AM
>  Subject: [jelly] Site build and Jellydoc plugin
>
> Hi,
> 
> recently I did some work to get the Jelly site build with Maven running.
> As this is experimental, I created my own fork of the project for this
> purpose [1].
> 
> An important part of the documentation is the Jellydoc, an automatically
> generated documentation for the standard tag libs shipped with Jelly.
> This documentation is generated by the maven-jellydoc-plugin [2].
> Unfortunately, the plugin has a few bugs which cause the site build to fail.
> 
> I therefore created a pull request [3] that fixes these problems. With
> the patched version the build is now successful.
> 
> However, there has not yet been a reaction on this PR. Given the fact
> that the plugin code had not been touched for more than 6 years, it may
> well be possible that Kohsuke Kawaguchi, the author of the plugin, is no
> longer interested in this code base.
> 
> Any thoughts how we could proceed here?
> 
> Oliver
> 
> [1] https://github.com/oheger/commons-jelly/tree/siteBuild
> [2] https://github.com/kohsuke/maven-jellydoc-plugin
> [3] https://github.com/kohsuke/maven-jellydoc-plugin/pull/1
> 
> -
> 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: [PROPOSAL] Apache Commons JUnit

[Oliver Heger]

On 04.11.2017 17:58, Bernd Eckenfels wrote:
> I like the idea (and prefer Commons Testing), for example a method to list 
> all non-daemon threads after a test run (to see there is no resource leak) 
> can be used independent of the Unit Test Framework.

We already had a Commons Test project. It has been moved to dormant, but
is not explicitly listed: http://svn.apache.org/viewvc/commons/dormant/test/

I also like the idea and would prefer a broader scope with
general-purpose utilities for unit tests.

Oliver

> 
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> From: Hasan Diwan 
> Sent: Saturday, November 4, 2017 5:42:39 PM
> To: Commons Developers List
> Subject: Re: [PROPOSAL] Apache Commons JUnit
> 
> How about "Apache Commons Testing"? -- H
> 
> On 4 November 2017 at 09:10, Gary Gregory  wrote:
> 
>> On Sat, Nov 4, 2017 at 9:32 AM, Pascal Schumacher <
>> pascalschumac...@gmx.net>
>> wrote:
>>
>>> JUnit 5 is not backwards compatible (Package/Annotation-Names have
>>> changed, Rules were replaced by a new extension model), but it can run
>>> JUnit 3 and JUnit 4 Tests if you add an additional dependency. See
>>> http://junit.org/junit5/docs/current/user-guide/#migrating-from-junit4
>>> for details.
>>
>>
>> OK, so "Apache Commons Extras for Junit 4"
>>
>> Gary
>>
>>
>>>
>>>
>>> Am 04.11.2017 um 15:53 schrieb Gary Gregory:
>>>
 I am assuming that JUnit 5 will be backward compatible with JUnit 4, I
 might be wrong. I'd like to focus on a single dependency for now (JUnit)
 and not do a multi-module project. If someone want to do the same for
 TestNG, then have at it. KISS and small for 1.0.

 Gary

 On Fri, Nov 3, 2017 at 10:41 PM, Bruno P. Kinoshita <
 brunodepau...@yahoo.com.br.invalid> wrote:

 +1 for the idea and for looking at JUnit 5.x and maybe AssertJ.
> CheersBruno
>
>From: Matt Sicker 
>   To: Commons Developers List 
>   Sent: Saturday, 4 November 2017 1:44 PM
>   Subject: Re: [PROPOSAL] Apache Commons JUnit
>
> I certainly like the idea, especially if the docs are good about
>> pulling
> in
> other related dependencies to complement the whole thing. General
> resource
> management rules would be great, though, like the ones we have in
>> Log4j.
>
> Also, I haven't looked closely at it yet, but supporting JUnit 5.x as
> well
> would be nice.
>
> On 3 November 2017 at 18:11, Gary Gregory 
> wrote:
>
> Hi All,
>>
>> I'd propose we start a new component called "Apache Commons JUnit".
>>
>> The goal would be to gather useful and reusable code like JUnit rules.
>>
>> This component would be focused on JUnit 4.x only.
>>
>> For example: org.apache.commons.collections4.junit.
>> SetDefaultLocaleTestRule
>>
>> I have other rules stashed here and there as well, for example a Set
>> Default Charset Rule.
>>
>> Thoughts?
>>
>> Gary
>>
>>
>
> --
> Matt Sicker 
>
>
>
>
>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>
> 
> 
> 
> --
> OpenPGP:
> https://sks-keyservers.net/pks/lookup?op=get=0xFEBAD7FFD041BBA1
> If you wish to request my time, please do so using
> http://bit.ly/hd1ScheduleRequest.
> Si vous voudrais faire connnaisance, allez a
> http://bit.ly/hd1ScheduleRequest.
> 
> Sent
> from my mobile device
> Envoye de mon portable
> 

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

[jelly] Site build and Jellydoc plugin

[Oliver Heger]

Hi,

recently I did some work to get the Jelly site build with Maven running.
As this is experimental, I created my own fork of the project for this
purpose [1].

An important part of the documentation is the Jellydoc, an automatically
generated documentation for the standard tag libs shipped with Jelly.
This documentation is generated by the maven-jellydoc-plugin [2].
Unfortunately, the plugin has a few bugs which cause the site build to fail.

I therefore created a pull request [3] that fixes these problems. With
the patched version the build is now successful.

However, there has not yet been a reaction on this PR. Given the fact
that the plugin code had not been touched for more than 6 years, it may
well be possible that Kohsuke Kawaguchi, the author of the plugin, is no
longer interested in this code base.

Any thoughts how we could proceed here?

Oliver

[1] https://github.com/oheger/commons-jelly/tree/siteBuild
[2] https://github.com/kohsuke/maven-jellydoc-plugin
[3] https://github.com/kohsuke/maven-jellydoc-plugin/pull/1

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

Re: [VOTE] Release Apache Commons Codec 1.11 from RC1

[Oliver Heger]

Build works fine with Java 1.6 and 1.8 on Windows 10, artifacts and site
look good.

One problem I found in the release notes: they refer to "the
commons-codec-1.11-SNAPSHOT release". This is confusing, but probably
not a blocker.

So +1
Oliver

Am 17.10.2017 um 20:30 schrieb Gary Gregory:
> Hi All,
> 
> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons Codec 1.10 was released, so I would like to release
> Apache Commons Codec 1.11.
> 
> Apache Commons Codec 1.11 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/codec at revision 22530
> Get it like this: svn co
> https://dist.apache.org/repos/dist/dev/commons/codec
> 
> The tag is here:
> 
> https://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec-1.11-RC1
> svn revision 1812411.
> The SVN revision is noted because SVN tags are not immutable.
> Get it like this: svn co
> https://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec-1.11-RC1
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/service/local/repositories/orgapachecommons-1280
> 
> These are the artifacts and their SHA1 hashes:
> 
> /commons-codec/commons-codec/1.11/commons-codec-1.11-javadoc.jar
> (SHA1: 978245f8bd06d70703fa3180554c62891500f97a)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-src.zip.asc
> (SHA1: e7ae399382030672890331dbf2a5e5014e1febec)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-tests.jar.asc
> (SHA1: 15c48130bfc257b9e668910a344168da97a535ed)
> /commons-codec/commons-codec/1.11/commons-codec-1.11.pom.asc
> (SHA1: 5c7c9df6b11c0a9efae0890ba9a3e4f6f85d74b0)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-sources.jar.asc
> (SHA1: c80656e5dd8e46341db814bcef89c03f821db6f8)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-bin.tar.gz
> (SHA1: 59cf4653ec88c4a9fb3b95ecd065ba5229788a5c)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-src.tar.gz
> (SHA1: 6ba24a55e5f8a8d7c9fdf28e8cb4edcc0fe44626)
> /commons-codec/commons-codec/1.11/commons-codec-1.11.pom
> (SHA1: 093ee1760aba62d6896d578bd7d247d0fa52f0e7)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-sources.jar
> (SHA1: bce4ba84fd527950e35040b20a991c63e90e2850)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-tests.jar
> (SHA1: 8a0430c3138ce4a23b0b6c7b7409df54bb76feb9)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-bin.zip
> (SHA1: 63e6cc02e648b7d46f50bf0c4d6ffcafeddf8d04)
> /commons-codec/commons-codec/1.11/commons-codec-1.11.jar
> (SHA1: 3acb4705652e16236558f0f4f2192cc33c3bd189)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-src.zip
> (SHA1: b45a09ea3711a9346c71d062e5f06935685db9fb)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-javadoc.jar.asc
> (SHA1: 5e7eb8e6e1e51017d6fc52eaec5ad67dcc2c9dce)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-test-sources.jar.asc
> (SHA1: 5f8c723bbcf08c8c4434a6731fe52d5e5cd9df9b)
> /commons-codec/commons-codec/1.11/commons-codec-1.11.jar.asc
> (SHA1: 42f6f623c1448aea511f4ee77d62d4b962f68450)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-test-sources.jar
> (SHA1: 67f923eb8f532cc8de6e30e7baad3de872ea49f8)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-bin.zip.asc
> (SHA1: fae75e01aa6492e4659d2140fadff2878984b5c0)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-bin.tar.gz.asc
> (SHA1: 3eac777bbd8527dd62ad53349a0eaa1d5a4cc830)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-src.tar.gz.asc
> (SHA1: d96909338df98272e81d9c4ea2b49f849e095ee8)
> 
> I tested this RC using 'mvn clean verify' on Windows 10 (Version
> 10.0.15063) with Oracle Java 7, Oracle Java 8, Oracle Java 9 and IBM Java 8
> using Maven 3.5.0:
> 
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
> 2017-04-03T13:39:06-06:00)
> Maven home: C:\Java\apache-maven-3.5.0\bin\..
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_80\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"
> => BUILD SUCCESS
> 
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
> 2017-04-03T13:39:06-06:00)
> Maven home: C:\Java\apache-maven-3.5.0\bin\..
> Java version: 1.8.0_144, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_144\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> => BUILD SUCCESS
> 
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
> 2017-04-03T13:39:06-06:00)
> Maven home: C:\Java\apache-maven-3.5.0\bin\..
> Java version: 1.8.0, vendor: IBM Corporation
> Java home: C:\eclipse\IBM-6.4.5\ibm_sdk80\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "x86", family: "windows"
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pwi3280sr4fp5-20170421_01(SR4 FP5))
> IBM J9 VM (build 2.8, JRE 

Re: [VOTE] Release Apache Commons IO 2.6 based on RC3

[Oliver Heger]

Build works fine with Java 1.7 and 1.8 on Windows 10. Artifacts and site
look good.

There is something strange in the OSGi meta data: The Export-Package
header obviously lists wrong version numbers for some of the packages.
For about half of the packages the version is set to "1.4.", for the
others it is the correct version "2.6". This will probably render the
artifact useless as an OSGi bundle.

Any idea what could cause such a strange versioning? I haven't seen this
before.

I just checked with version 2.5, and here the same version numbers show
up in the manifest.

So +1
Oliver

Am 15.10.2017 um 12:22 schrieb Benedikt Ritter:
> Hello,
> 
> we have fixed quite a few bugs and added some nice new features since Apache 
> Commons IO 2.5 was released, so I would like to release Apache Commons IO 2.6 
> based on RC3.
> 
> The changes between RC1 and RC2 are:
> - Worked on the design of the ByteOrderParser class
> - Fixed IO-546
> - Fixed IO-553
> 
> The changes between RC2 and RC3 are:
> - RC2 contained cobertura instrumented class files (thanks to Oliver Heger to 
> catching this one!)
> 
> Commons IO 2.6 RC3 is available for review here: 
> https://dist.apache.org/repos/dist/dev/commons/io/commons-io-2.6-RC3 (svn 
> revision 22482)
> 
> The tag is here: 
> https://git-wip-us.apache.org/repos/asf?p=commons-io.git;a=tag;h=027aebfbfcebad7dfa8603201d4b0ec4859904e8
> 
> Commit ID the tag points at: 2ae025fe5c4a7d2046c53072b0898e37a079fe62
> 
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecommons-1278
> 
> These are the Maven artifacts and their hashes:
> 
> /commons-io/commons-io/2.6/commons-io-2.6-test-sources.jar.asc
> (SHA1: 2a6e16c3f135851b5a907bd50655db9f9bff73a2)
> /commons-io/commons-io/2.6/commons-io-2.6.pom.asc
> (SHA1: 177e5b7e423cb9747f5b3cb982af326d24698c64)
> /commons-io/commons-io/2.6/commons-io-2.6-tests.jar.asc
> (SHA1: 38ccc2062ed998df95910eda9982e5c9623eb8cc)
> /commons-io/commons-io/2.6/commons-io-2.6.pom
> (SHA1: 5060835593e5b6ed18c82fc2e782f0a3c30a00b1)
> /commons-io/commons-io/2.6/commons-io-2.6.jar.asc
> (SHA1: 7a389502e94871e30f3330634925dff61e4e098a)
> /commons-io/commons-io/2.6/commons-io-2.6-test-sources.jar
> (SHA1: 75c8aa60dc4623dca0311b38f317ba56596a70ec)
> /commons-io/commons-io/2.6/commons-io-2.6-javadoc.jar
> (SHA1: 2d1132e48d5d2b698cc27290758dca7905031cfa)
> /commons-io/commons-io/2.6/commons-io-2.6-sources.jar
> (SHA1: db473f690e219b0566e7f1a8a991bf0e6f08a3c6)
> /commons-io/commons-io/2.6/commons-io-2.6-tests.jar
> (SHA1: 02a08a358025f15d44b5f04410d89b413b97)
> /commons-io/commons-io/2.6/commons-io-2.6.jar
> (SHA1: adac173d974250643940c7836caf2726f11a0dc0)
> /commons-io/commons-io/2.6/commons-io-2.6-javadoc.jar.asc
> (SHA1: 7d78d02ce0d96c511de696b518f1c12133662417)
> /commons-io/commons-io/2.6/commons-io-2.6-sources.jar.asc
> (SHA1: 8debf732bc0e5187432f723c01503d75145dbd19)
> 
> I have tested this with JDK 8 using Maven 3.5.0.
> 
> Details of changes since 2.5 are in the release notes:
> https://dist.apache.org/repos/dist/dev/commons/io/commons-io-2.6-RC3/RELEASE-NOTES.txt
> http://home.apache.org/~britter/commons/commons-io-2.6-RC3/changes-report.html
> 
> Site:
> http://home.apache.org/~britter/commons/commons-io-2.6-RC3/ 
> (note some *relative* links are broken and the 2.6 directories are not yet 
> created - these will be OK once the site is deployed)
> 
> Clirr Report (compared to 2.5):
> http://home.apache.org/~britter/commons/commons-io-2.6-RC3/clirr-report.html
> 
> RAT Report:
> http://home.apache.org/~britter/commons/commons-io-2.6-RC3/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. sometime after 12:30 CEST (UTC+2) 18-October 2017
> 
> [ ] +1 Release these artifacts
> [ ] +0 OK, but…
> [ ] -0 OK, but really should fix…
> [ ] -1 I oppose this release because...
> 
> Thanks!
> 
> Benedikt  
> -
> 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 Compress 1.15 based on RC1

[Oliver Heger]

Build works fine with Java 1.7 and 1.8 on Windows 10. Artifacts and site
look good.

+1

Oliver

Am 14.10.2017 um 15:45 schrieb Stefan Bodewig:
> Hi all
> 
> this is mostly a bugfix release but it was about time for a new release.
> 
> Compress 1.15 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/compress/ (svn revision 
> 22476)
> 
> The tag is here:
> 
> https://git-wip-us.apache.org/repos/asf?p=commons-compress.git;a=tag;h=ae82f93454d4dcd57ac1ed7d53114bda2f82c8f3
> on commit
> 
> https://git-wip-us.apache.org/repos/asf?p=commons-compress.git;a=commit;h=01b06d5ef5c5ac3bd651bedcfec7433231cea371
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1277/org/apache/commons/commons-compress/1.15/
> 
> These are the Maven artifacts and their sha1 hashes
> 
> b686cd04abaef1ea7bc5e143c080563668eec17e  commons-compress-1.15.jar
> 3f5c9429da7cc2ca4b73a415928fac5f9949c798  commons-compress-1.15.jar.asc
> 9a165c3cc83158820bfa0691dcd15379fa3c8ab9  commons-compress-1.15-javadoc.jar
> 05b6759fa95e7981c7ca0982c37880bd784e6642  
> commons-compress-1.15-javadoc.jar.asc
> 670c082e6fc3a99950ee385edc4d9352fb0a99d7  commons-compress-1.15.pom
> d68decca16fa849cf432fd8e29510f1a21100518  commons-compress-1.15.pom.asc
> a82a61e0bbce4e06281c675af7422553bf20ca8f  commons-compress-1.15-sources.jar
> 73da7e4ccac26460b301edd7ece1ac3546e2842e  
> commons-compress-1.15-sources.jar.asc
> 0e23a1617451c69488e57141c1ca99929d25ed5e  commons-compress-1.15-tests.jar
> 8d7535a2d7efa4c870f93946289669efc74a7f78  commons-compress-1.15-tests.jar.asc
> 9149c762ebf2248c0f20b62b59d827535f6604a4  
> commons-compress-1.15-test-sources.jar
> e545455b5fd7ec12b8ddfa8cec92af2df056aa9a  
> commons-compress-1.15-test-sources.jar.asc
> 
> I have tested this with JDK 8 using Maven 3.3.9.
> 
> Details of changes since 1.14 are in the release notes:
> https://dist.apache.org/repos/dist/dev/commons/compress/RELEASE-NOTES.txt
> 
> https://stefan.samaflost.de/staging/commons-compress-1.15/changes-report.html
> 
> Site:
> https://stefan.samaflost.de/staging/commons-compress-1.15/
>   (as usual I'll re-create the site once the release date is known,
> download links and the links for thr 1.15 javadocs don't work)
> 
> japicmp Report (compared to 1.14):
> https://stefan.samaflost.de/staging/commons-compress-1.15/japicmp.html
> 
> RAT Report:
> https://stefan.samaflost.de/staging/commons-compress-1.15/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. sometime after 14:00 UTC 17-October 2017
> 
>   [ ] +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-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 Apache Commons IO 2.6 based on RC3

[Oliver Heger]

Am 15.10.2017 um 17:28 schrieb Gary Gregory:
> How do you verify that the class files are not Cobertura tweaked? Can we
> add that as a step to the wiki and commons build plugin?

As long as there is no cobertura.properties file in the root of the jar,
we should be on the safe side.

However, it would be cool to have some automatic checking. This problem
is easy to overlook.

Oliver

> 
> Gary
> 
> On Oct 15, 2017 04:22, "Benedikt Ritter" <brit...@apache.org> wrote:
> 
>> Hello,
>>
>> we have fixed quite a few bugs and added some nice new features since
>> Apache Commons IO 2.5 was released, so I would like to release Apache
>> Commons IO 2.6 based on RC3.
>>
>> The changes between RC1 and RC2 are:
>> - Worked on the design of the ByteOrderParser class
>> - Fixed IO-546
>> - Fixed IO-553
>>
>> The changes between RC2 and RC3 are:
>> - RC2 contained cobertura instrumented class files (thanks to Oliver Heger
>> to catching this one!)
>>
>> Commons IO 2.6 RC3 is available for review here:
>> https://dist.apache.org/repos/dist/dev/commons/io/commons-io-2.6-RC3 (svn
>> revision 22482)
>>
>> The tag is here: https://git-wip-us.apache.org/
>> repos/asf?p=commons-io.git;a=tag;h=027aebfbfcebad7dfa8603201d4b0e
>> c4859904e8
>>
>> Commit ID the tag points at: 2ae025fe5c4a7d2046c53072b0898e37a079fe62
>>
>> Maven Artifacts: https://repository.apache.org/content/repositories/
>> orgapachecommons-1278
>>
>> These are the Maven artifacts and their hashes:
>>
>> /commons-io/commons-io/2.6/commons-io-2.6-test-sources.jar.asc
>> (SHA1: 2a6e16c3f135851b5a907bd50655db9f9bff73a2)
>> /commons-io/commons-io/2.6/commons-io-2.6.pom.asc
>> (SHA1: 177e5b7e423cb9747f5b3cb982af326d24698c64)
>> /commons-io/commons-io/2.6/commons-io-2.6-tests.jar.asc
>> (SHA1: 38ccc2062ed998df95910eda9982e5c9623eb8cc)
>> /commons-io/commons-io/2.6/commons-io-2.6.pom
>> (SHA1: 5060835593e5b6ed18c82fc2e782f0a3c30a00b1)
>> /commons-io/commons-io/2.6/commons-io-2.6.jar.asc
>> (SHA1: 7a389502e94871e30f3330634925dff61e4e098a)
>> /commons-io/commons-io/2.6/commons-io-2.6-test-sources.jar
>> (SHA1: 75c8aa60dc4623dca0311b38f317ba56596a70ec)
>> /commons-io/commons-io/2.6/commons-io-2.6-javadoc.jar
>> (SHA1: 2d1132e48d5d2b698cc27290758dca7905031cfa)
>> /commons-io/commons-io/2.6/commons-io-2.6-sources.jar
>> (SHA1: db473f690e219b0566e7f1a8a991bf0e6f08a3c6)
>> /commons-io/commons-io/2.6/commons-io-2.6-tests.jar
>> (SHA1: 02a08a358025f15d44b5f04410d89b413b97)
>> /commons-io/commons-io/2.6/commons-io-2.6.jar
>> (SHA1: adac173d974250643940c7836caf2726f11a0dc0)
>> /commons-io/commons-io/2.6/commons-io-2.6-javadoc.jar.asc
>> (SHA1: 7d78d02ce0d96c511de696b518f1c12133662417)
>> /commons-io/commons-io/2.6/commons-io-2.6-sources.jar.asc
>> (SHA1: 8debf732bc0e5187432f723c01503d75145dbd19)
>>
>> I have tested this with JDK 8 using Maven 3.5.0.
>>
>> Details of changes since 2.5 are in the release notes:
>> https://dist.apache.org/repos/dist/dev/commons/io/commons-
>> io-2.6-RC3/RELEASE-NOTES.txt
>> http://home.apache.org/~britter/commons/commons-io-2.
>> 6-RC3/changes-report.html
>>
>> Site:
>> http://home.apache.org/~britter/commons/commons-io-2.6-RC3/
>> (note some *relative* links are broken and the 2.6 directories are not yet
>> created - these will be OK once the site is deployed)
>>
>> Clirr Report (compared to 2.5):
>> http://home.apache.org/~britter/commons/commons-io-2.
>> 6-RC3/clirr-report.html
>>
>> RAT Report:
>> http://home.apache.org/~britter/commons/commons-io-2.6-RC3/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. sometime after 12:30 CEST (UTC+2)
>> 18-October 2017
>>
>> [ ] +1 Release these artifacts
>> [ ] +0 OK, but…
>> [ ] -0 OK, but really should fix…
>> [ ] -1 I oppose this release because...
>>
>> Thanks!
>>
>> Benedikt
>> -
>> 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 Apache Commons IO 2.6 based on RC2

[Oliver Heger]

Hi Benedikt,

it seems that the binary artifact does not contain the real classes, but
classes manipulated by Cobertura. commons-io-2.6.jar contains a
cobertura.properties file, and opening a class in a decompiler shows
some Cobertura-specific initialization code.

Can you please double-check?

Oliver

Am 14.10.2017 um 14:35 schrieb Benedikt Ritter:
> Hello,
> 
> we have fixed quite a few bugs and added some nice new features since Apache 
> Commons IO 2.5 was released, so I would like to release Apache Commons IO 2.6 
> based on RC2.
> 
> The changes since RC1 are:
> - Worked on the design of the ByteOrderParser class
> - Fixed IO-546
> - Fixed IO-553
> 
> Commons IO 2.6 RC1 is available for review here: 
> https://dist.apache.org/repos/dist/dev/commons/io/commons-io-2.6-RC2 (svn 
> revision 22474)
> 
> The tag is here: 
> https://git-wip-us.apache.org/repos/asf?p=commons-io.git;a=tag;h=dbd097debffe1b8c91d232a2311c08ff3e70e7a1
> 
> Commit ID the tag points at: a219081780bb1714876ef3e1109283b96f3b007b
> 
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecommons-1276
> 
> These are the Maven artifacts and their hashes:
> 
> /commons-io/commons-io/2.6/commons-io-2.6-test-sources.jar.asc
> (SHA1: 2a6e16c3f135851b5a907bd50655db9f9bff73a2)
> /commons-io/commons-io/2.6/commons-io-2.6.pom.asc
> (SHA1: 177e5b7e423cb9747f5b3cb982af326d24698c64)
> /commons-io/commons-io/2.6/commons-io-2.6-tests.jar.asc
> (SHA1: 38ccc2062ed998df95910eda9982e5c9623eb8cc)
> /commons-io/commons-io/2.6/commons-io-2.6.pom
> (SHA1: 5060835593e5b6ed18c82fc2e782f0a3c30a00b1)
> /commons-io/commons-io/2.6/commons-io-2.6.jar.asc
> (SHA1: 7a389502e94871e30f3330634925dff61e4e098a)
> /commons-io/commons-io/2.6/commons-io-2.6-test-sources.jar
> (SHA1: 75c8aa60dc4623dca0311b38f317ba56596a70ec)
> /commons-io/commons-io/2.6/commons-io-2.6-javadoc.jar
> (SHA1: 2d1132e48d5d2b698cc27290758dca7905031cfa)
> /commons-io/commons-io/2.6/commons-io-2.6-sources.jar
> (SHA1: db473f690e219b0566e7f1a8a991bf0e6f08a3c6)
> /commons-io/commons-io/2.6/commons-io-2.6-tests.jar
> (SHA1: 02a08a358025f15d44b5f04410d89b413b97)
> /commons-io/commons-io/2.6/commons-io-2.6.jar
> (SHA1: adac173d974250643940c7836caf2726f11a0dc0)
> /commons-io/commons-io/2.6/commons-io-2.6-javadoc.jar.asc
> (SHA1: 7d78d02ce0d96c511de696b518f1c12133662417)
> /commons-io/commons-io/2.6/commons-io-2.6-sources.jar.asc
> (SHA1: 8debf732bc0e5187432f723c01503d75145dbd19)
> 
> I have tested this with JDK 8 using Maven 3.5.0.
> 
> Details of changes since 2.5 are in the release notes:
>  
> https://dist.apache.org/repos/dist/dev/commons/io/commons-io-2.6-RC2/RELEASE-NOTES.txt
>  
> http://home.apache.org/~britter/commons/commons-io-2.6-RC2/changes-report.html
> 
> I’ve already realized that I messed up the changes.xml: It has the wrong 
> release date. I think we can fix this after the release since it is used to 
> generate the website.
> 
> Site:
>  http://home.apache.org/~britter/commons/commons-io-2.6-RC2/ 
> (note some *relative* links are broken and the 2.6 directories are not yet 
> created - these will be OK once the site is deployed)
> 
> Clirr Report (compared to 2.5):
>  http://home.apache.org/~britter/commons/commons-io-2.6-RC2//clirr-report.html
> 
> RAT Report:
>  http://home.apache.org/~britter/commons/commons-io-2.6-RC2/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. sometime after 15:00 CEST (UTC+2) 17-October 2017
> 
> [ ] +1 Release these artifacts
> [ ] +0 OK, but…
> [ ] -0 OK, but really should fix…
> [ ] -1 I oppose this release because...
> 
> Thanks!
> 
> Benedikt  
> -
> 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

[ANNOUNCEMENT] Commons Configuration 2.2 Released

[Oliver Heger]

The Apache Commons Team is pleased to announce the availability of
Apache Commons Configuration 2.2.

The Apache Commons Configuration software library provides a generic
configuration interface which enables an application to read
configuration data from a variety of sources.

Version 2.2 is another maintenance release for the Configuration 2.x
series. It contains a number of bug fixes and also some new features.
Among the highlights is the new support for JSON and YAML
configurations. The release is fully source and binary compatible with
version 2.1.1.

A full list of all changes can be found in the release notes at
  http://www.apache.org/dist/commons/configuration/RELEASE-NOTES.txt

A user's guide describing all the features of Configuration 2.x can be
found at
  http://commons.apache.org/configuration/userguide/user_guide.html

Source and binary distributions are available for download from the
Apache Commons download site:

http://commons.apache.org/proper/commons-configuration/download_configuration.cgi

Please verify signatures using the KEYS file available at the above
location when downloading the release.

For complete information on Commons Configuration, including
instructions on how to submit bug reports, patches, or suggestions for
improvement, see the Apache Commons Configuration website:

http://commons.apache.org/proper/commons-configuration/

Oliver Heger, on behalf of the Apache Commons community

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

Re: [RESULT][VOTE] Release Commons Configuration 2.2 based on RC1

[Oliver Heger]

Am 11.10.2017 um 23:04 schrieb Gary Gregory:
> Can you release from Nexus ASAP SVP?
Done.

Oliver

> 
> Gary
> 
> On Oct 11, 2017 14:24, "Oliver Heger" <oliver.he...@oliver-heger.de> wrote:
> 
>> The vote to release Commons Configuration 2.2 based on RC1 passed with
>> the following binding votes:
>>
>> Bruno P. Kinoshita: +1
>> Gary Gregory:   +1
>> Rob Tompkins:   +1
>> Oliver Heger:   +1
>>
>> No other votes were cast.
>>
>> Thanks to all who took the time to review the RC. I will start the
>> release procedure in the next days.
>>
>> Oliver
>>
>> Am 08.10.2017 um 22:24 schrieb Oliver Heger:
>>> Hi all,
>>>
>>> there was a request for a new release on the ML, so here we go.
>>>
>>> Configuration 2.2 RC1 is available for review here:
>>> https://dist.apache.org/repos/dist/dev/commons/configuration/ (rev.
>> 22170)
>>>
>>> The tag is here:
>>>
>>> http://svn.apache.org/repos/asf/commons/proper/configuration/tags/
>> CONFIGURATION_2_2_RC1/
>>> (rev. 1811500)
>>>
>>> Maven artifacts are here:
>>>
>>> https://repository.apache.org/content/repositories/
>> orgapachecommons-1273/org/apache/commons/commons-configuration2/2.2/
>>>
>>> Details of changes since 1.1 are in the release notes:
>>>
>>> https://dist.apache.org/repos/dist/dev/commons/
>> configuration/RELEASE-NOTES.txt
>>> http://home.apache.org/~oheger/configuration-2.2-rc1/
>> changes-report.html
>>>
>>> Site:
>>> http://home.apache.org/~oheger/configuration-2.2-rc1/
>>>   (note some *relative* links are broken and the 1.2 directories are
>>>   not yet created - these will be OK once the site is deployed)
>>>
>>> Clirr Report (compared to 2.1.1):
>>> http://home.apache.org/~oheger/configuration-2.2-rc1/
>> clirr-report.html
>>>
>>> RAT Report:
>>> http://home.apache.org/~oheger/configuration-2.2-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. sometime after 22:00 UTC 11-October 2017
>>>
>>>   [ ] +1 Release these artifacts
>>>   [ ] +0 OK, but...
>>>   [ ] -0 OK, but really should fix...
>>>   [ ] -1 I oppose this release because...
>>>
>>> Thanks!
>>> Oliver
>>>
>>>
>>> -
>>> 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

[RESULT][VOTE] Release Commons Configuration 2.2 based on RC1

[Oliver Heger]

The vote to release Commons Configuration 2.2 based on RC1 passed with
the following binding votes:

Bruno P. Kinoshita: +1
Gary Gregory:   +1
Rob Tompkins:   +1
Oliver Heger:   +1

No other votes were cast.

Thanks to all who took the time to review the RC. I will start the
release procedure in the next days.

Oliver

Am 08.10.2017 um 22:24 schrieb Oliver Heger:
> Hi all,
> 
> there was a request for a new release on the ML, so here we go.
> 
> Configuration 2.2 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/configuration/ (rev. 22170)
> 
> The tag is here:
> 
> http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_2_2_RC1/
> (rev. 1811500)
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1273/org/apache/commons/commons-configuration2/2.2/
> 
> Details of changes since 1.1 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/configuration/RELEASE-NOTES.txt
> http://home.apache.org/~oheger/configuration-2.2-rc1/changes-report.html
> 
> Site:
> http://home.apache.org/~oheger/configuration-2.2-rc1/
>   (note some *relative* links are broken and the 1.2 directories are
>   not yet created - these will be OK once the site is deployed)
> 
> Clirr Report (compared to 2.1.1):
> http://home.apache.org/~oheger/configuration-2.2-rc1/clirr-report.html
> 
> RAT Report:
> http://home.apache.org/~oheger/configuration-2.2-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. sometime after 22:00 UTC 11-October 2017
> 
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
> 
> Thanks!
> Oliver
> 
> 
> -
> 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 Configuration 2.2 based on RC1

[Oliver Heger]

My own +1

Oliver

Am 08.10.2017 um 22:24 schrieb Oliver Heger:
> Hi all,
> 
> there was a request for a new release on the ML, so here we go.
> 
> Configuration 2.2 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/configuration/ (rev. 22170)
> 
> The tag is here:
> 
> http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_2_2_RC1/
> (rev. 1811500)
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1273/org/apache/commons/commons-configuration2/2.2/
> 
> Details of changes since 1.1 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/configuration/RELEASE-NOTES.txt
> http://home.apache.org/~oheger/configuration-2.2-rc1/changes-report.html
> 
> Site:
> http://home.apache.org/~oheger/configuration-2.2-rc1/
>   (note some *relative* links are broken and the 1.2 directories are
>   not yet created - these will be OK once the site is deployed)
> 
> Clirr Report (compared to 2.1.1):
> http://home.apache.org/~oheger/configuration-2.2-rc1/clirr-report.html
> 
> RAT Report:
> http://home.apache.org/~oheger/configuration-2.2-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. sometime after 22:00 UTC 11-October 2017
> 
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
> 
> Thanks!
> Oliver
> 
> 
> -
> 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

[VOTE] Release Commons Configuration 2.2 based on RC1

[Oliver Heger]

Hi all,

there was a request for a new release on the ML, so here we go.

Configuration 2.2 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/configuration/ (rev. 22170)

The tag is here:

http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_2_2_RC1/
(rev. 1811500)

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1273/org/apache/commons/commons-configuration2/2.2/

Details of changes since 1.1 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/configuration/RELEASE-NOTES.txt
http://home.apache.org/~oheger/configuration-2.2-rc1/changes-report.html

Site:
http://home.apache.org/~oheger/configuration-2.2-rc1/
  (note some *relative* links are broken and the 1.2 directories are
  not yet created - these will be OK once the site is deployed)

Clirr Report (compared to 2.1.1):
http://home.apache.org/~oheger/configuration-2.2-rc1/clirr-report.html

RAT Report:
http://home.apache.org/~oheger/configuration-2.2-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. sometime after 22:00 UTC 11-October 2017

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thanks!
Oliver


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

Re: [VOTE] Release Apache Commons VFS 2.2 from RC2.

[Oliver Heger]

Hi,

same comments as for the last time:

Build works fine with Java 1.7 and 1.8 on Windows 10 (I don't get any
test failures). Artifacts and site look good.

Some findings:
- Both source and binary distribution use the same top-level folder.
- The site has two checkstyle reports. One is empty, the other one
contains some warnings which are probably not too difficult to fix.

No blockers, so +1

Oliver

Am 03.10.2017 um 20:30 schrieb Gary Gregory:
> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons VFS 2.1 was released, so I would like to release
> Apache Commons VFS 2.2.
> 
> Apache Commons VFS 2.2 RC2 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/vfs/ (svn revision 22084)
> Get it: svn co https://dist.apache.org/repos/dist/dev/commons/vfs/
> 
> * The difference from RC1 is the inclusion of unit test fixes for
> non-Windows platforms.
> 
> The tag is here:
> 
> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.2-rc2/
> (svn revision 1810617)
> N.B. the SVN revision is required because SVN tags are not immutable.
> Get it: svn co
> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.2-rc2/
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/service/local/repositories/orgapachecommons-1271/content/org/apache/commons/commons-vfs2-distribution/2.2/
> 
> These are the artifacts and their SHA1 hashes:
> 
> /org/apache/commons/commons-vfs2-distribution/2.2/commons-vfs2-distribution-2.2-src.tar.gz
> (SHA1: b83f15b695519353dbb0da310f256e8c776ab6c6)
> /org/apache/commons/commons-vfs2-distribution/2.2/commons-vfs2-distribution-2.2-bin.zip.asc
> (SHA1: f8e2274ef4df95b91ccb9ca7ee58dce18a3f6fe4)
> /org/apache/commons/commons-vfs2-distribution/2.2/commons-vfs2-distribution-2.2.pom
> (SHA1: d8053a146c0d7e4b9cf649e8d6a0aff680dc3946)
> /org/apache/commons/commons-vfs2-distribution/2.2/commons-vfs2-distribution-2.2-src.zip.asc
> (SHA1: 057fbf7b942bf6368e70ee9fcfd6dae00ef2840e)
> /org/apache/commons/commons-vfs2-distribution/2.2/commons-vfs2-distribution-2.2-bin.zip
> (SHA1: 2d6071e1cbb0e466031a83679d6d0aaa1d37e66a)
> /org/apache/commons/commons-vfs2-distribution/2.2/commons-vfs2-distribution-2.2-bin.tar.gz
> (SHA1: f967aa889ecb3b333917c9dd4585045ff5cd27e6)
> /org/apache/commons/commons-vfs2-distribution/2.2/commons-vfs2-distribution-2.2.pom.asc
> (SHA1: 43f17f82292d899024788414e188d929f0934495)
> /org/apache/commons/commons-vfs2-distribution/2.2/commons-vfs2-distribution-2.2-src.tar.gz.asc
> (SHA1: 4b0dd55cbbd6085c07675f8aea50db903a283ca0)
> /org/apache/commons/commons-vfs2-distribution/2.2/commons-vfs2-distribution-2.2-src.zip
> (SHA1: 7691a17b0f574004106698fb49bc1540a80d9ead)
> /org/apache/commons/commons-vfs2-distribution/2.2/commons-vfs2-distribution-2.2-bin.tar.gz.asc
> (SHA1: dfd06635746cd215426a28668a389d22ed7dc106)
> /org/apache/commons/commons-vfs2/2.2/commons-vfs2-2.2.jar.asc
> (SHA1: 5422743248bc2773c1fe1e1e37cc7d5805eb6a0f)
> /org/apache/commons/commons-vfs2/2.2/commons-vfs2-2.2-test-sources.jar
> (SHA1: 321a0150f53cdac36be59a4795a1b72ba5d29422)
> /org/apache/commons/commons-vfs2/2.2/commons-vfs2-2.2-tests.jar.asc
> (SHA1: 3212e2e92d013d72d9d98690c997842c8fbc11ac)
> /org/apache/commons/commons-vfs2/2.2/commons-vfs2-2.2-javadoc.jar.asc
> (SHA1: f7b3781d229074a31268443ce5865fab5b6eabb8)
> /org/apache/commons/commons-vfs2/2.2/commons-vfs2-2.2.pom.asc
> (SHA1: 0302debd93d09721a06b58de6f217c56a6d72adf)
> /org/apache/commons/commons-vfs2/2.2/commons-vfs2-2.2.pom
> (SHA1: 8ddc26fc8729a7f3a6a1c642e4069b58d3a5ec04)
> /org/apache/commons/commons-vfs2/2.2/commons-vfs2-2.2-test-sources.jar.asc
> (SHA1: 6fe14c321f2713cc1ec110ffbde1c223ae022f3c)
> /org/apache/commons/commons-vfs2/2.2/commons-vfs2-2.2-sources.jar.asc
> (SHA1: e996b4b375ada6e0135c3b7a01555da75b666c5b)
> /org/apache/commons/commons-vfs2/2.2/commons-vfs2-2.2.jar
> (SHA1: 98a98f365a07256ec33c32a653c14255b12859e0)
> /org/apache/commons/commons-vfs2/2.2/commons-vfs2-2.2-sources.jar
> (SHA1: 94eddc684b50ce2b8a5e4f3f475ddc2909b96d1a)
> /org/apache/commons/commons-vfs2/2.2/commons-vfs2-2.2-javadoc.jar
> (SHA1: 39d0a5417a22992da665f77f296344f5a6bed168)
> /org/apache/commons/commons-vfs2/2.2/commons-vfs2-2.2-tests.jar
> (SHA1: cfa95dded1ef13410d08b9debe31fb1989a94a4f)
> /org/apache/commons/commons-vfs2-project/2.2/commons-vfs2-project-2.2-site.xml
> (SHA1: 45db714de819ec12adc528479bf9a4a2e15ba323)
> /org/apache/commons/commons-vfs2-project/2.2/commons-vfs2-project-2.2.pom
> (SHA1: dece2db6026f36f9dbbad8668cfb1fca867fbb64)
> /org/apache/commons/commons-vfs2-project/2.2/commons-vfs2-project-2.2.pom.asc
> (SHA1: f2cacc97d1a03f7738c58a521a85e99f5ee50c3c)
> /org/apache/commons/commons-vfs2-project/2.2/commons-vfs2-project-2.2-site.xml.asc
> (SHA1: 87947f4de3ec06f208c9b97057c0467c5c61551d)
> /org/apache/commons/commons-vfs2-examples/2.2/commons-vfs2-examples-2.2-sources.jar.asc
> (SHA1: