[LANG] Commons Lang dependency coordinates on GitHub wrong

[Benedikt Ritter]

Hi,

GitHub recently introduced a feature where it tries to figure out how many
other projects depend on you project. This is shown in the UI with a "Used
By" drop down button. When clicking that button one can copy the dependency
declaration. In case of Commons Lang this will generate [1]:


  commons-lang
  commons-lang
  [VERSION]


This is incorrect since the coordinates for the 3.x line are
org.apache.commons:commons-lang3:3.x
I think we should find out how we can fix this. Maybe infra can fix it?
Furthermore we should check all our GitHub mirrors whether they have the
correct coordinates for our components.

Regards,
Benedikt

[1] https://github.com/apache/commons-lang

Re: [VFS] Deleting the git branch 'trunk'

[Benedikt Ritter]

Am Di., 30. Apr. 2019 um 14:43 Uhr schrieb Gary Gregory <
garydgreg...@gmail.com>:

> Should we take a broader stroke and remove ALL trunk branches from all
> Commons git repos?
>

I think we should remove all trunk branches from git repos.


>
> Gary
>
> On Mon, Apr 29, 2019 at 11:25 AM Otto Fowler 
> wrote:
>
> > Probably need INFRA
> >
> >
> > On April 29, 2019 at 11:23:38, Gary Gregory (garydgreg...@gmail.com)
> > wrote:
> >
> > On Mon, Apr 29, 2019 at 11:22 AM Gary Gregory 
> > wrote:
> >
> > > Well, crud, neither these works:
> > >
> > > C:\git\commons-vfs>git push origin --delete trunk
> > > remote: Rewinding refs/heads/trunk is forbidden.
> > > remote:
> > > To https://gitbox.apache.org/repos/asf/commons-vfs
> > > ! [remote rejected] trunk (pre-receive hook declined)
> > > error: failed to push some refs to '
> > > https://gitbox.apache.org/repos/asf/commons-vfs'
> > >
> > > C:\git\commons-vfs> git push origin :trunk
> > > remote: Rewinding refs/heads/trunk is forbidden.
> > > remote:
> > > To https://gitbox.apache.org/repos/asf/commons-vfs
> > > ! [remote rejected] trunk (pre-receive hook declined)
> > > error: failed to push some refs to '
> > > https://gitbox.apache.org/repos/asf/commons-vfs'
> > >
> > > Thoughts?
> > >
> >
> > BTW, I had deleted the branch locally OK with 'git branch -d trunk'
> >
> > Gary
> >
> >
> > >
> > > Gary
> > >
> > > On Mon, Apr 29, 2019 at 11:11 AM Rob Tompkins 
> > wrote:
> > >
> > >> +1
> > >>
> > >> > On Apr 29, 2019, at 10:58 AM, Otto Fowler 
> > >> wrote:
> > >> >
> > >> > +1
> > >> >
> > >> >
> > >> > On April 29, 2019 at 08:01:43, Gary Gregory (garydgreg...@gmail.com
> )
> > >> wrote:
> > >> >
> > >> > I am going to delete the branch 'trunk'.
> > >> >
> > >> > It's too confusing.
> > >> >
> > >> > Gary
> > >>
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > >> For additional commands, e-mail: dev-h...@commons.apache.org
> > >>
> > >>
> >
>

Re: [VFS] Green builds on Travis CI

[Benedikt Ritter]

Am Di., 30. Apr. 2019 um 15:04 Uhr schrieb Gary Gregory <
garydgreg...@gmail.com>:

> Hi All:
>
> For the first time in a while, we have a green build suite on Travis:
>
> https://travis-ci.org/apache/commons-vfs/


Awesome!


>
>
> Gary
>

Re: [VOTE] Release Apache Commons Imaging 1.0-alpha1 based on RC3

[Benedikt Ritter]

Hello Bruno,

awesome to see this happening. Thank you for all the work you put into this!

Am Sa., 27. Apr. 2019 um 14:22 Uhr schrieb Bruno P. Kinoshita <
ki...@apache.org>:

> I would like to release Apache Commons Imaging 1.0-alpha1.
>
> Apache Commons Imaging 1.0-alpha1 RC3 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/imaging/1.0-alpha1-RC3
> (svn revision 33801)
>
> The Git tag commons-imaging-1.0-alpha1-RC3 commit for this RC is
> 6f04ccc2cf8c867298579c355c6d88fd74da3e7b which you can browse here:
>
> https://git-wip-us.apache.org/repos/asf?p=commons-imaging.git;a=tag;h=refs/tags/commons-imaging-1.0-alpha1-RC3
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1438/org/apache/commons/commons-imaging/1.0-alpha1/
>
> These are the Maven artifacts and their hashes in Nexus:
>
> ${commons.sha256list}
> #Release SHA-512s
> #Sat Apr 27 23:40:11 NZST 2019
>
> commons-imaging-1.0-alpha1-sources-java-source=320ed4dae9045e38f4956558b38497593de35197051e6370cc5d959782e191ec40cbdf651cc0e5dfe62afd25d9fbad0dc73ff3db4a914757a058f1b88570a649
>
> commons-imaging-1.0-alpha1-bin-zip=699124772e2ad47be85230fa6529eb710a26567c416e5d950445a637b426f86c3ad1c9577f41f7e2f6bd94016b14192077ba3305a85ff36601ca36703a935eb7
>
> commons-imaging-1.0-alpha1-sources-jar.asc=2e8445b62c1a4afbbae0f7ccdd97d18f2ba2db57c5be649c089a70bce70e816c55422241ee44040ee3122bae45f05c664bf07764446a72b623272dc540cb255b
>
> commons-imaging-1.0-alpha1-src-zip.asc=21acf6132380c42c6823f599ff6c31900868ac5131837ed17c9c40c7e99d3b88410a2d5331b922da605f54a9cf68ff70d705d3ca94cd6db7a4f9b5d0a9e1c3ee
>
> commons-imaging-1.0-alpha1-pom.asc=38d13c75c3f134b39b31a8e6ad563e921bd9a7ad8008dd78854999841463a45ca98c52547b84657cb7700725bf683c22bf925be898107a4ce7c6d0f35ee83c61
>
> commons-imaging-1.0-alpha1-tests-jar.asc=6f800eaaf02550e3b13d459b2e8885f5bf5b3bed02611997cf6c35fb782ef5a634eb21c907d046167778df6a3cfbd948c9cb464a34da88813ce08ccd5ebba386
>
> commons-imaging-1.0-alpha1-javadoc-jar.asc=7c562516e9f88b7490b7123fc529d5dc33303453c5990bcf23ecfc9ca46fc6df5324c3cdc5bf49bfa4e7d3de49d80591d97721df6890369cdbf95aba700d577f
>
> commons-imaging-1.0-alpha1-tests-test-jar=58a9ac4861a70a87d3490d09e2d90e6ef0293711a9edf3f7fab10776e9d37484c421f4be283531aa6985abbac474604e0f633442b509e0b1ccef1a95a788c754
>
> commons-imaging-1.0-alpha1-jar.asc=18a007c1185de84b3395b1d8b2e1e1c466939020646c015fca29be4fc1d9647ec4d8afcc20bf562bfdae01d740b0117bd3b904fd022b7d6e944569c78517adc5
>
> commons-imaging-1.0-alpha1-bin-tar.gz.asc=31995c5e035a753d86294f90850de1d73fef478a6bb234cebab6272b9c5521dcb1e5ec3a180508929e765f18af4202dbbe616b0264f7ab50c40be793cca1
>
> commons-imaging-1.0-alpha1-test-sources-jar.asc=6f3265c73f2f3b4d67b4d084f2e309032591fdbd25b40b93cb854d8f9c61a719bc27b3de37ed5faf36caed295a944f1e48399e1120b55f307d9bb842b965d5b7
>
> commons-imaging-1.0-alpha1-src-tar.gz=3c06195e75161e5bf2364f358169a2cd9231c8c30c526c060efa7d8972394ddcdb2bc2a9caa64073700e2c7eabf0830ccd33a84defafc72a444889a579e86073
>
> commons-imaging-1.0-alpha1-bin-zip.asc=69dbfbb5f2aa2a85ae87c4510777643706214dec171c87b1ee992b5f5caab9401ef32ad54dcaf2e590a8cf694a9bb89d0e335c13fff0a95dc402454b287b99a6
>
> commons-imaging-1.0-alpha1-javadoc-javadoc=7cde692d47ce4f2936803b9c8d54ad7c71a070507d6c8fd4533421d43fc019908e24ade7264b01080e1c614d26c71454237a000fb81a464e83907d35b6450730
>
> commons-imaging-1.0-alpha1-src-zip=8eea523c614561b7da7c1e3203a0c48f1d3fdcaaf178e843c7834ff6b546ee7f09270385558adc16583bd1cd6e6d953a3b67ffcf117727bb7ad1b45d9b546a4a
>
> commons-imaging-1.0-alpha1-bin-tar.gz=f7ac881d8439007d1b4f0ba83df3da75ebdc2b2b0e7632762cb0ad9e5ec57f6553ae72223a1d91c30cc7035dfd28009d778653f18fc5476cf27fc040f1df717f
>
> commons-imaging-1.0-alpha1-test-sources-java-source=16cea0d32ae8a9da68d8bafa52a1519c5a9f20dd3097acb5826ddcc6364747af01d81b76b12c3ce9e40da049f3a2aaa78259ac7ea57ea8334c3f79c42cb75aae
>
> commons-imaging-1.0-alpha1-src-tar.gz.asc=cdb66c75cdf944756ff857422c3f1172832abc0889ef501f0ee7f925643470beea1304c9f7782beb089e77c1ea65f2dc23bb2dc37f756dec5f8d5d52c83d9e01
>
>
> (no need for .asc hashes!)
>
> I have tested this with ***'mvn clean install site'*** using:
>
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
> 2018-06-18T06:33:14+12:00)
> Maven home: /opt/apache-maven-3.5.4
> Java version: 1.8.0_191, vendor: Oracle Corporation, runtime:
> /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en_NZ, platform encoding: UTF-8
> OS name: "linux", version: "4.15.0-47-generic", arch: "amd64", family:
> "unix"
>
> Details of changes are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/imaging/1.0-alpha1-RC3/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/imaging/1.0-alpha1-RC3/site/changes-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/imaging/1.0-alpha1-RC3/site
> (note some *relative* links are broken and the 1.0-alpha1 directories
> are not yet created - these will be O

Re: [lang] Remove final modifier behaviour in java 12+ (was: Re: [VOTE] Release Apache Commons Lang 3.9 based on RC1)

[Benedikt Ritter]

An alternative would be to use SystemUtils.isJavaVersionAtMost the have
behavior depending on the current Java versions. This would preserve the
behavior for users on Java < 12.

Benedikt

Am Mi., 10. Apr. 2019 um 16:32 Uhr schrieb Rob Tompkins :

> I like that. I’ll get that sorted out.
>
> -Rob
>
> > On Apr 10, 2019, at 10:28 AM, Gary Gregory 
> wrote:
> >
> > I think UnsupportedOperationException with a Java 12 comment, but we
> should
> > also add @Deprecated with a comment about it not working at all on Java
> 12.
> >
> > Gary
> >
> > On Wed, Apr 10, 2019 at 8:55 AM Rob Tompkins  wrote:
> >
> >> Looks like we get an exception because the final modifier isn’t
> removable
> >> in java 12+ and for good reason [1]. So, we probably should throw an
> >> exception, but both of the exceptions that arise out of the jvm here
> >>
> https://github.com/apache/commons-lang/blob/master/src/main/java/org/apache/commons/lang3/reflect/FieldUtils.java#L736
> >> <
> >>
> https://github.com/apache/commons-lang/blob/master/src/main/java/org/apache/commons/lang3/reflect/FieldUtils.java#L736
> >
> >> are checked exceptions. Specifically we get a “NoSuchFieldException”
> when
> >> we attempt to retrieve “modifiers” from the “Field.” For the sake of
> >> retaining BC, I would think that we would in turn convert that
> Exception to
> >> an “UnsupportedOperationException”  or a “TypeNotPresentException”
> (maybe
> >> ??) for the sake of getting to an unchecked exception.
> >>
> >> Open to thoughts here,
> >>
> >> -Rob
> >>
> >>
> >> [1]
> >>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056486.html
> >>
> >>
> >>> On Apr 10, 2019, at 5:09 AM, Benedikt Ritter 
> wrote:
> >>>
> >>> Damn it, I had it on my list to fix those. Sorry, Rob!
> >>>
> >>> Am Mi., 10. Apr. 2019 um 03:33 Uhr schrieb Rob Tompkins <
> >> chtom...@gmail.com
> >>>> :
> >>>
> >>>>
> >>>>
> >>>>> On Apr 9, 2019, at 9:15 PM, Gary Gregory 
> >> wrote:
> >>>>>
> >>>>> +0... see Java 12 testing below.
> >>>>
> >>>> That +0 is almost worth cancelling for in my opinion. I’ll wait until
> >>>> tomorrow to see if anyone else wants to have an opinion here, and then
> >> I’ll
> >>>> have another go at it.
> >>>>
> >>>> -Rob
> >>>>
> >>>>>
> >>>>> Nit in the release notes: Replace "Java 8.0" with Java 8".
> >>>>>
> >>>>> From the git tag, ran 'mvn -V clean package' OK for:
> >>>>>
> >>>>> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> >>>>> 2018-10-24T14:41:47-04:00)
> >>>>> Maven home: C:\Java\apache-maven-3.6.0\bin\..
> >>>>> Java version: 1.8.0_202, vendor: Oracle Corporation, runtime:
> >> C:\Program
> >>>>> Files\Java\jdk1.8.0_202\jre
> >>>>> Default locale: en_US, platform encoding: Cp1252
> >>>>> OS name: "windows 10", version: "10.0", arch: "amd64", family:
> >> "windows"
> >>>>>
> >>>>> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> >>>>> 2018-10-24T14:41:47-04:00)
> >>>>> Maven home: C:\Java\apache-maven-3.6.0\bin\..
> >>>>> Java version: 11.0.2, vendor: Oracle Corporation, runtime: C:\Program
> >>>>> Files\Java\openjdk\jdk-11.0.2
> >>>>> Default locale: en_US, platform encoding: Cp1252
> >>>>> OS name: "windows 10", version: "10.0", arch: "amd64", family:
> >> "windows"
> >>>>>
> >>>>> BUT on Java 12:
> >>>>>
> >>>>> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> >>>>> 2018-10-24T14:41:47-04:00)
> >>>>> Maven home: C:\Java\apache-maven-3.6.0\bin\..
> >>>>> Java version: 12, vendor: Oracle Corporation, runtime: C:\Program
> >>>>> Files\Java\openjdk\jdk-12
> >>>>> Default locale: en_US, platform encoding: Cp1252
> >>>>> OS name: "windows 10", version: "10.0", arch: "amd64", family:
> >> "

Re: [lang] 3.9, switch from cobertura to jacoco?

[Benedikt Ritter]

Am Di., 9. Apr. 2019 um 15:24 Uhr schrieb Rob Tompkins :

> We want a jira for this?
>

I usually only create jira for things that impact users of the lib. So
changes to the API or the behavior. But that's just my personal
convention... :)

Benedikt


>
> -Rob
>
> > On Apr 9, 2019, at 9:14 AM, Gary Gregory  wrote:
> >
> > +1
> >
> > Gary
> >
> > On Tue, Apr 9, 2019 at 8:39 AM Rob Tompkins  wrote:
> >
> >> Thoughts on doing this switch? I’m heavily leaning towards it because I
> >> can’t get code coverage to work on java 11 with the current build.
> >>
> >> -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] Release Apache Commons Lang 3.9 based on RC1

[Benedikt Ritter]

Damn it, I had it on my list to fix those. Sorry, Rob!

Am Mi., 10. Apr. 2019 um 03:33 Uhr schrieb Rob Tompkins :

>
>
> > On Apr 9, 2019, at 9:15 PM, Gary Gregory  wrote:
> >
> > +0... see Java 12 testing below.
>
> That +0 is almost worth cancelling for in my opinion. I’ll wait until
> tomorrow to see if anyone else wants to have an opinion here, and then I’ll
> have another go at it.
>
> -Rob
>
> >
> > Nit in the release notes: Replace "Java 8.0" with Java 8".
> >
> > From the git tag, ran 'mvn -V clean package' OK for:
> >
> > Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> > 2018-10-24T14:41:47-04:00)
> > Maven home: C:\Java\apache-maven-3.6.0\bin\..
> > Java version: 1.8.0_202, vendor: Oracle Corporation, runtime: C:\Program
> > Files\Java\jdk1.8.0_202\jre
> > Default locale: en_US, platform encoding: Cp1252
> > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> >
> > Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> > 2018-10-24T14:41:47-04:00)
> > Maven home: C:\Java\apache-maven-3.6.0\bin\..
> > Java version: 11.0.2, vendor: Oracle Corporation, runtime: C:\Program
> > Files\Java\openjdk\jdk-11.0.2
> > Default locale: en_US, platform encoding: Cp1252
> > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> >
> > BUT on Java 12:
> >
> > Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> > 2018-10-24T14:41:47-04:00)
> > Maven home: C:\Java\apache-maven-3.6.0\bin\..
> > Java version: 12, vendor: Oracle Corporation, runtime: C:\Program
> > Files\Java\openjdk\jdk-12
> > Default locale: en_US, platform encoding: Cp1252
> > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> >
> > I get:
> >
> > [ERROR] Failures:
> > [ERROR]   FieldUtilsTest.testRemoveFinalModifier:998 expected: 
> but
> > was: 
> > [ERROR]   FieldUtilsTest.testRemoveFinalModifierWithAccess:1009 expected:
> >  but was: 
> > [INFO]
> > [ERROR] Tests run: 5774, Failures: 2, Errors: 0, Skipped: 4
> >
> > On Java 13-EA:
> >
> > Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> > 2018-10-24T14:41:47-04:00)
> > Maven home: C:\Java\apache-maven-3.6.0\bin\..
> > Java version: 13-ea, vendor: Oracle Corporation, runtime: C:\Program
> > Files\Java\openjdk\jdk-13
> > Default locale: en_US, platform encoding: Cp1252
> > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> >
> > I get:
> >
> > [INFO] ---
> > [INFO]  T E S T S
> > [INFO] ---
> > [WARNING] Corrupted STDOUT by directly writing to native stream in forked
> > JVM 1. See FAQ web page and the dump file
> >
> C:\temp\rc\commons-lang\target\surefire-reports\2019-04-09T21-13-37_709-jvmRun1.dumpstream
> > [INFO]
> > [INFO] Results:
> > [INFO]
> > [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> > [INFO]
> > [INFO]
> > 
> > [INFO] BUILD FAILURE
> > [INFO]
> > 
> > [INFO] Total time:  27.315 s
> > [INFO] Finished at: 2019-04-09T21:13:38-04:00
> > [INFO]
> > 
> > [ERROR] Failed to execute goal
> > org.apache.maven.plugins:maven-surefire-plugin:2.22.1:test (default-test)
> > on project commons-lang3: There are test failures.
> > [ERROR]
> > [ERROR] Please refer to C:\temp\rc\commons-lang\target\surefire-reports
> for
> > the individual test results.
> > [ERROR] Please refer to dump files (if any exist) [date].dump,
> > [date]-jvmRun[N].dump and [date].dumpstream.
> > [ERROR] The forked VM terminated without properly saying goodbye. VM
> crash
> > or System.exit called?
> > [ERROR] Command was cmd.exe /X /C ""C:\Program
> > Files\Java\openjdk\jdk-13\bin\java"
> >
> -javaagent:C:\\Users\\ggregory\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.2\\org.jacoco.agent-0.8.2-runtime.jar=destfile=C:\\temp\\rc\\commons-lang\\target\\jacoco.exec
> > -Xmx512m --add-opens java.base/java.lang.reflect=ALL-UNNAMED --add-opens
> > java.base/java.lang=ALL-UNNAMED -jar
> >
> C:\Users\ggregory\AppData\Local\Temp\surefire5519858828807362694\surefirebooter988663828837655366.jar
> > C:\Users\ggregory\AppData\Local\Temp\surefire5519858828807362694
> > 2019-04-09T21-13-37_709-jvmRun1 surefire11717302241379819897tmp
> > surefire_07095889889312770815tmp"
> > [ERROR] Error occurred in starting fork, check output in log
> > [ERROR] Process Exit Code: 1
> > [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: The
> > forked VM terminated without properly saying goodbye. VM crash or
> > System.exit called?
> > [ERROR] Command was cmd.exe /X /C ""C:\Program
> > Files\Java\openjdk\jdk-13\bin\java"
> >
> -javaagent:C:\\Users\\ggregory\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.2\\org.jacoco.agent-0.8.2-runtime.jar=destfile=C:\\temp\\r

Re: [lang] LANG-1442

[Benedikt Ritter]

LGTM

Am Sa., 6. Apr. 2019 um 16:59 Uhr schrieb Rob Tompkins :

> @Gilles - thoughts on this wording:
> https://github.com/apache/commons-lang/commit/3f43706192b1b75c5023f165534a12b192c31442
> <
> https://github.com/apache/commons-lang/commit/3f43706192b1b75c5023f165534a12b192c31442>
> ?
>
> -Rob

Re: [lang] Towards 3.9

[Benedikt Ritter]

Am Do., 4. Apr. 2019 um 12:40 Uhr schrieb Rob Tompkins :

> Any thoughts on doing a 3.9 release of [lang]. I think Benedikt want’s us
> to go up with what we have. Any thoughts for or against doing a release?
>

I would like to have https://github.com/apache/commons-lang/pull/415
 included.
Furthermore there are two entires in changes.xml that don't have a Jira. I
think we should create one just for the documentary.

Benedikt


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

Re: [codec] Java 8

[Benedikt Ritter]

Am Fr., 22. März 2019 um 16:13 Uhr schrieb Gary Gregory <
garydgreg...@gmail.com>:

> Hi All,
>
> Now that Codec 1.12 is out, I plan on updating from Java 7 to Java 8.
>

+1


>
> Gary
>

Re: GitHub Pull Requests (and Confluence)

[Benedikt Ritter]

Hello Jochen,

Am Mo., 25. März 2019 um 16:32 Uhr schrieb Jochen Wiedmann <
jochen.wiedm...@gmail.com>:

> Hi,
>
> just FIY: Today I tried to accept a pull request from Github,
> following the procedure, as outlined on
>
>
> https://cwiki.apache.org/confluence/display/ROLLER/How+to+accept+a+GitHub+Pull+Request


Since we're using gitbox now, you can simply merge PRs via the GitHub UI.
So we should update/remove our documentation in the wiki.

Regards,
Benedikt


>
>
> (Of course, the Git URL has to be adjusted to your subproject, in my case
>
>https://gitbox.apache.org/repos/asf/commons-fileupload.git
>
> Which reminds me: Do we have a Confluence space? If not: Would anyone
> mind, if I asked for one on Jira?
>
> Thanks,
>
> Jochen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [LANG] Jenkins Pipeline DSL

[Benedikt Ritter]

Hi!

the PR has been merged and I've created a multi branch pipeline [1]. I've
used the configuration from the PLC4X project because I know they were
among the first to use pipeline files. I recommend that we let this build
for a while to get a feeling whether this works the way we want. If it does
we can then drop the old manually configured pipeline.

Regards,
Benedikt

[1]
https://builds.apache.org/view/A-D/view/Commons/job/commons-lang-pipeline/

Re: [Parent] RAT check

[Benedikt Ritter]

+1 to anything that makes releasing easier.

Am Sa., 9. März 2019 um 23:45 Uhr schrieb Gary Gregory <
garydgreg...@gmail.com>:

> Hi all:
>
> How about making apache-rat:check run automatically in commons-parent? In
> the Maven validate phase?
>
> That would mean one less thing to check when integrating a patch and
> validating an RC.
>
> Gary
>

Re: [ALL] Avoiding duplication of work between GitHub PRs and JIRA

[Benedikt Ritter]

I think for all non cosmetic changes there should be jira issue for the PR.
Source code platforms can come and go (think of SourceForge) so we should
not rely on the GitHub PR as documentation.

Benedikt

Am Mi., 6. März 2019 um 15:14 Uhr schrieb Gary Gregory <
garydgreg...@gmail.com>:

> On Wed, Mar 6, 2019 at 9:06 AM sebb  wrote:
>
> > On Wed, 6 Mar 2019 at 13:54, Gary Gregory 
> wrote:
> > >
> > > Hi All:
> > >
> > > I'll start with this example from Commons VFS and its changes.xml:
> > >
> > >   
> > > Update Apache Commons Collections from 4.2 to 4.3.
> > >   
> > >
> > >due-to="Boris
> > > Petrov, Gary Gregory">
> > > Add support for customizing FTP transfer aborted status codes.
> > > GitHub PR #51.
> > >   
> > >
> > > The first entry uses a JIRA reference as usual.
> > >
> > > In the second entry, I applied a PR from GitHub but I did not create a
> > > matching JIRA issue. The fact that we have a change is still tracked in
> > > changes.xml. The site report will not have a URL to JIRA.
> > >
> > > Question: Can we make the changes plugin generate a link to GitHub for
> a
> > PR?
> >
> >
> >
> http://maven.apache.org/plugins/maven-changes-plugin/changes-report-mojo.html#issueLinkTemplatePerSystem
> >
> > I don't think the plugin can support more that one type of URL
> > generation per pom.
> > It would need some way to distinguish different types of issues.
> > e.g. a different attribute name (gitpr) or an extra attribute to
> > qualify the issue type.
> >
> > This is really a question for the Maven user list.
> >
>
> Good idea. I just did. Thanks Sebb!
>
> Gary
>
>
> >
> > > 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 Imaging 1.0-alpha1 based on RC2

[Benedikt Ritter]

Bruno, it's so great to see a release finally happening. Very much
appreciated!

Am Mi., 6. März 2019 um 09:03 Uhr schrieb Bruno P. Kinoshita <
ki...@apache.org>:

>  Just a heads up I'm planning to work on RC3 in the next days.
> Have re-read the issues with RC2, and using JDK 8
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
> 2018-06-18T06:33:14+12:00)
> Maven home: /opt/apache-maven-3.5.4
> Java version: 1.8.0_191, vendor: Oracle Corporation, runtime:
> /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en_NZ, platform encoding: UTF-8
> OS name: "linux", version: "4.15.0-45-generic", arch: "amd64", family:
> "unix"
>
> Successfully built the project with `mvn clean site install`, `mvn
> apache-rat:check`, and `mvn site -Pjdk8-javadoc`.
> Also updated the site text, to say 1.0-alpha instead of 1.0 in some parts.
> The changes.xml has also been updated to match the version 1.0-alpha. Will
> rename the release version in JIRA (I think that's OK too?
> CheersBruno
>
> On Monday, 5 November 2018, 4:07:02 am NZDT, Gary Gregory <
> garydgreg...@gmail.com> wrote:
>
>  IMO, let's stick with 1.0-alpha1. There is no need to rush the new API and
> this will make the code available to all through Maven repos. Hopefully
> once the code is more easy to use from builds, we will get more feedback.
>
> Gary
>
> On Sun, Nov 4, 2018 at 12:17 AM Bruno P. Kinoshita
>  wrote:
>
> > >The release notes says that version 1.0 was released 24 November 2013.
> > >Should be updated?
> > Oh, mea culpa. That slipped me.
> > Not sure whether we also need 1.0-alpha1 or simply 1.0 is OK (if the
> > former, then I think we would have to double-check the rest of the docs
> for
> > other entries like that).
> > CheersBruno
> >
> >
> >  From: "thc...@gmail.com" 
> >  To: dev@commons.apache.org
> >  Sent: Tuesday, 30 October 2018 10:34 PM
> >  Subject: Re: [VOTE] Release Apache Commons Imaging 1.0-alpha1 based on
> RC2
> >
> > Hi.
> >
> > On 30/10/2018 09:09, Bruno P. Kinoshita wrote:
> > > We have fixed quite a few bugs and added some significant enhancements
> > since Apache Sanselan Incubating 0.97-incubator was released, so I would
> > like to release Apache Commons Imaging 1.0-alpha1.
> > >
> > > Apache Commons Imaging 1.0-alpha1 RC2 is available for review here:
> > > https://dist.apache.org/repos/dist/dev/commons/imaging/1.0-alpha1-RC2
> > (svn revision 30516)
> > >
> > > The Git tag commons-imaging-1.0-alpha1-RC2 commit for this RC is
> > e4e1b4dd0da6d4c90205674a730738576f2bee8e which you can browse here:
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=commons-imaging.git;a=tag;h=refs/tags/commons-imaging-1.0-alpha1-RC2
> > >
> > > Maven artifacts are here:
> > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1395/org/apache/commons/commons-imaging/1.0-alpha1/
> > >
> > > These are the Maven artifacts and their hashes in Nexus:
> > >
> > > #Release SHA-256s
> > > #Tue Oct 30 21:27:02 NZDT 2018
> > >
> >
> commons-imaging-1.0-alpha1-sources-java-source=c5a359c19f7768860a520b4e37aecd0bf9e7b95665d45c3bddedac10ea83aca1
> > >
> >
> commons-imaging-1.0-alpha1-bin-zip=3eeb5894c91975524e6e858b8d9318ef69faf2b7c1c37157783897ececf9339f
> > >
> >
> commons-imaging-1.0-alpha1-sources-jar.asc=0c1c298db3ead3069e221b9bbb153702819d1be0c90982bd7bc31384d4dadf7a
> > >
> >
> commons-imaging-1.0-alpha1-src-zip.asc=3c2aa29c8ac1d0cc036821cf2d2c7647a3d08aadad7f156c67df92c1336ad14a
> > >
> >
> commons-imaging-1.0-alpha1-pom.asc=aa33dacce18d8bcd2f90827f78907615c5f1ea0f56af9a77df9dfb29f4a10542
> > >
> >
> commons-imaging-1.0-alpha1-tests-jar.asc=4a7fe21a8c85e00b53eae6de8ccc138c7d0d7655af5d34d866196f3992a44b2f
> > >
> >
> commons-imaging-1.0-alpha1-javadoc-jar.asc=ff15ecc262d47fb8551f99adcb2a7f259180c5c54763bf7b2f51c16470ff0034
> > >
> >
> commons-imaging-1.0-alpha1-tests-test-jar=520eb1223a59bcc9c14c553acc58e1e4258574f9caaf0797093698a4fa2130c0
> > >
> >
> commons-imaging-1.0-alpha1-jar.asc=28957df1acd3c3a6fb7326f03b8115a3b2d760de07d3f9b8cc6722d7af98508a
> > >
> >
> commons-imaging-1.0-alpha1-bin-tar.gz.asc=415d3753f9be590f0e0be829f3499d14e2c42c2bd39deddb9a8ab538b3d2327f
> > >
> >
> commons-imaging-1.0-alpha1-test-sources-jar.asc=cc085db20953597090b40084362e523cd52faa2fc535ef83b083fde08559762d
> > >
> >
> commons-imaging-1.0-alpha1-src-tar.gz=486c71ef3d7ca3760dcece77c5c8979dc544270d60f21d0994725cb1aa3a04fd
> > >
> >
> commons-imaging-1.0-alpha1-bin-zip.asc=ef67c0c3795ebecc6567c7e7b75cf4797f5b7d5c7387b87ac6703157c88029a9
> > >
> >
> commons-imaging-1.0-alpha1-javadoc-javadoc=37feb9395af4d17ad7407b3deb95e8c4001acb6b42d790eb20acf3ddb8b4851b
> > >
> >
> commons-imaging-1.0-alpha1-src-zip=180a29bd5ff95b5c32ec62a0a0949d68ff9907e18740c793266de0bd6dc2f8b7
> > >
> >
> commons-imaging-1.0-alpha1-bin-tar.gz=73c5324e87e81f9c837c3403f133f6dc112d07f0b3ee6bbb758b3701aa8b23a4
> > >
> >
> commons-imaging-1.0-alpha1-test-sources-java-source=91d26c80147a539652cd1acb3aae2f550ee848f9f0cecf640e3916075778df2f
> > >
> 

Re: [LANG] Jenkins Pipeline DSL

[Benedikt Ritter]

Am Mo., 4. März 2019 um 10:50 Uhr schrieb sebb :

> On Mon, 4 Mar 2019 at 09:47, Benedikt Ritter  wrote:
> >
> > Am So., 3. März 2019 um 14:57 Uhr schrieb sebb :
> >
> > > On Sun, 3 Mar 2019 at 13:28, Benedikt Ritter 
> wrote:
> > > >
> > > > Hi all,
> > > >
> > > > here is my proposal for a Jenkins Pipeline file for Commons Lang:
> > > > https://github.com/apache/commons-lang/pull/410
> > > > Please review and comment.
> > >
> > > It looks OK to me, but I think we need to see it in action.
> > >
> > > For example, what about notifications for failed builds - is that
> > > maintained in Jenkins or in the pipeline file?
> > >
> >
> > I will add notification. The PLC4X Project has a good example for that:
> > https://github.com/apache/incubator-plc4x/blob/develop/Jenkinsfile
>
> Thanks.
>
> Sending emails looks really long-winded compared with the Jenkins UI.
> Easy to get things wrong; harder to maintain.
>

It's jetzt the groovy representations of what you would otherwise configure
in the UI.
I've pushed email notifications to the PR on GitHub.


>
> >
> > >
> > > > Benedikt
> > > >
> > > > Am Mi., 20. Feb. 2019 um 11:40 Uhr schrieb Benedikt Ritter <
> > > > brit...@apache.org>:
> > > >
> > > > > I'm happy about the positive feedback. I'm currently a little bit
> busy
> > > at
> > > > > work. I hope to be able to spike something at the end of next week.
> > > > >
> > > > > Benedikt
> > > > >
> > > > > Am Mo., 18. Feb. 2019 um 20:25 Uhr schrieb Matt Sicker <
> > > boa...@gmail.com>:
> > > > >
> > > > >> The DSL allows you to break out into parallel stages or sequential
> > > > >> ones (or both). The log4net Jenkinsfile has an example of building
> > > > >> across multiple agents:
> > > > >>
> > > > >>
> > > > >>
> > >
> https://github.com/apache/logging-log4net/blob/feature/cd-pipeline/Jenkinsfile
> > > > >>
> > > > >> On Mon, 18 Feb 2019 at 12:44, sebb  wrote:
> > > > >> >
> > > > >> > Seems worth trying.
> > > > >> >
> > > > >> > I suggest start with one project (i.e. Lang) and see how well it
> > > works.
> > > > >> >
> > > > >> > I assume there will need to be a once-off change to Jenkins to
> > > switch
> > > > >> > to using the DSL.
> > > > >> >
> > > > >> > Note that some components have multiple jobs, e.g. for different
> > > OSes
> > > > >> and JVMs.
> > > > >> > Does the DSL support such jobs? Or is that still done through
> the
> > > GUI?
> > > > >> >
> > > > >> > S.
> > > > >> >
> > > > >> > On Mon, 18 Feb 2019 at 18:05, Matt Sicker 
> wrote:
> > > > >> > >
> > > > >> > > +1. You could also make a shared library for reuse in commons
> > > > >> projects.
> > > > >> > >
> > > > >> > > On Sun, 17 Feb 2019 at 14:41, Pascal Schumacher
> > > > >> > >  wrote:
> > > > >> > > >
> > > > >> > > > +1 to using a pipeline
> > > > >> > > >
> > > > >> > > > Am 17.02.2019 um 18:35 schrieb Benedikt Ritter:
> > > > >> > > > > Hi all,
> > > > >> > > > >
> > > > >> > > > > I feel like maintaining separate build descriptions on
> > > Jenkins is
> > > > >> a PITA.
> > > > >> > > > > Any objections against adopting Jenkins Pipeline DSL for
> Lang?
> > > > >> > > > >
> > > > >> > > > > Regards,
> > > > >> > > > > Benedikt
> > > > >> > > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > > >
> > > > >>
> -
> > > > >> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > >> > > > For additional commands, e-mail:
> dev-h...@commons.apache.org
> > > > >> > > >
> > > > >> > >
> > > > >> > >
> > > > >> > > --
> > > > >> > > Matt Sicker 
> > > > >> > >
> > > > >> > >
> > > -
> > > > >> > > 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
> > > > >> >
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Matt Sicker 
> > > > >>
> > > > >>
> -
> > > > >> 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] Jenkins Pipeline DSL

[Benedikt Ritter]

Am So., 3. März 2019 um 14:57 Uhr schrieb sebb :

> On Sun, 3 Mar 2019 at 13:28, Benedikt Ritter  wrote:
> >
> > Hi all,
> >
> > here is my proposal for a Jenkins Pipeline file for Commons Lang:
> > https://github.com/apache/commons-lang/pull/410
> > Please review and comment.
>
> It looks OK to me, but I think we need to see it in action.
>
> For example, what about notifications for failed builds - is that
> maintained in Jenkins or in the pipeline file?
>

I will add notification. The PLC4X Project has a good example for that:
https://github.com/apache/incubator-plc4x/blob/develop/Jenkinsfile


>
> > Benedikt
> >
> > Am Mi., 20. Feb. 2019 um 11:40 Uhr schrieb Benedikt Ritter <
> > brit...@apache.org>:
> >
> > > I'm happy about the positive feedback. I'm currently a little bit busy
> at
> > > work. I hope to be able to spike something at the end of next week.
> > >
> > > Benedikt
> > >
> > > Am Mo., 18. Feb. 2019 um 20:25 Uhr schrieb Matt Sicker <
> boa...@gmail.com>:
> > >
> > >> The DSL allows you to break out into parallel stages or sequential
> > >> ones (or both). The log4net Jenkinsfile has an example of building
> > >> across multiple agents:
> > >>
> > >>
> > >>
> https://github.com/apache/logging-log4net/blob/feature/cd-pipeline/Jenkinsfile
> > >>
> > >> On Mon, 18 Feb 2019 at 12:44, sebb  wrote:
> > >> >
> > >> > Seems worth trying.
> > >> >
> > >> > I suggest start with one project (i.e. Lang) and see how well it
> works.
> > >> >
> > >> > I assume there will need to be a once-off change to Jenkins to
> switch
> > >> > to using the DSL.
> > >> >
> > >> > Note that some components have multiple jobs, e.g. for different
> OSes
> > >> and JVMs.
> > >> > Does the DSL support such jobs? Or is that still done through the
> GUI?
> > >> >
> > >> > S.
> > >> >
> > >> > On Mon, 18 Feb 2019 at 18:05, Matt Sicker  wrote:
> > >> > >
> > >> > > +1. You could also make a shared library for reuse in commons
> > >> projects.
> > >> > >
> > >> > > On Sun, 17 Feb 2019 at 14:41, Pascal Schumacher
> > >> > >  wrote:
> > >> > > >
> > >> > > > +1 to using a pipeline
> > >> > > >
> > >> > > > Am 17.02.2019 um 18:35 schrieb Benedikt Ritter:
> > >> > > > > Hi all,
> > >> > > > >
> > >> > > > > I feel like maintaining separate build descriptions on
> Jenkins is
> > >> a PITA.
> > >> > > > > Any objections against adopting Jenkins Pipeline DSL for Lang?
> > >> > > > >
> > >> > > > > Regards,
> > >> > > > > Benedikt
> > >> > > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> -
> > >> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > >> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >> > > >
> > >> > >
> > >> > >
> > >> > > --
> > >> > > Matt Sicker 
> > >> > >
> > >> > >
> -
> > >> > > 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
> > >> >
> > >>
> > >>
> > >> --
> > >> Matt Sicker 
> > >>
> > >> -
> > >> 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] Jenkins Pipeline DSL

[Benedikt Ritter]

Am Mo., 4. März 2019 um 00:17 Uhr schrieb Matt Sicker :

> I think you can combine the analysis steps into one mvn command.
>

Makes sense. What I really want to have is all the analyze steps running in
parallel. Is that passible?


>
> On Sun, 3 Mar 2019 at 14:15, Pascal Schumacher 
> wrote:
> >
> > Am 03.03.2019 um 14:56 schrieb sebb:
> > > For example, what about notifications for failed builds - is that
> > > maintained in Jenkins or in the pipeline file?
> >
> > Notification can be defined in the pipeline.
> >
> > Pretty much everything can be defined in a jenkins file nowadays (some
> > plugins do not have pipeline support (yet)).
> >
> > https://jenkins.io/doc/book/pipeline/ has a lot of useful information.
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
>
> --
> Matt Sicker 
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [LANG] Jenkins Pipeline DSL

[Benedikt Ritter]

Hi all,

here is my proposal for a Jenkins Pipeline file for Commons Lang:
https://github.com/apache/commons-lang/pull/410
Please review and comment.

Benedikt

Am Mi., 20. Feb. 2019 um 11:40 Uhr schrieb Benedikt Ritter <
brit...@apache.org>:

> I'm happy about the positive feedback. I'm currently a little bit busy at
> work. I hope to be able to spike something at the end of next week.
>
> Benedikt
>
> Am Mo., 18. Feb. 2019 um 20:25 Uhr schrieb Matt Sicker :
>
>> The DSL allows you to break out into parallel stages or sequential
>> ones (or both). The log4net Jenkinsfile has an example of building
>> across multiple agents:
>>
>>
>> https://github.com/apache/logging-log4net/blob/feature/cd-pipeline/Jenkinsfile
>>
>> On Mon, 18 Feb 2019 at 12:44, sebb  wrote:
>> >
>> > Seems worth trying.
>> >
>> > I suggest start with one project (i.e. Lang) and see how well it works.
>> >
>> > I assume there will need to be a once-off change to Jenkins to switch
>> > to using the DSL.
>> >
>> > Note that some components have multiple jobs, e.g. for different OSes
>> and JVMs.
>> > Does the DSL support such jobs? Or is that still done through the GUI?
>> >
>> > S.
>> >
>> > On Mon, 18 Feb 2019 at 18:05, Matt Sicker  wrote:
>> > >
>> > > +1. You could also make a shared library for reuse in commons
>> projects.
>> > >
>> > > On Sun, 17 Feb 2019 at 14:41, Pascal Schumacher
>> > >  wrote:
>> > > >
>> > > > +1 to using a pipeline
>> > > >
>> > > > Am 17.02.2019 um 18:35 schrieb Benedikt Ritter:
>> > > > > Hi all,
>> > > > >
>> > > > > I feel like maintaining separate build descriptions on Jenkins is
>> a PITA.
>> > > > > Any objections against adopting Jenkins Pipeline DSL for Lang?
>> > > > >
>> > > > > Regards,
>> > > > > Benedikt
>> > > > >
>> > > >
>> > > >
>> > > >
>> -
>> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > > > For additional commands, e-mail: dev-h...@commons.apache.org
>> > > >
>> > >
>> > >
>> > > --
>> > > Matt Sicker 
>> > >
>> > > -
>> > > 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
>> >
>>
>>
>> --
>> Matt Sicker 
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>

Re: [CSV] Update from Java 7 to 8

[Benedikt Ritter]

+1

Am Sa., 23. Feb. 2019 um 14:16 Uhr schrieb Gary Gregory <
garydgreg...@gmail.com>:

> Hi All:
>
> I plan on updating Commons CSV from Java 7 to 8.
>
> Gary
>

Re: [crypto] Implementing HMAC and CMAC

[Benedikt Ritter]

Hi,

Am So., 24. Feb. 2019 um 00:31 Uhr schrieb Alex Remily <
alex.rem...@gmail.com>:

> 
>
> That's an open question.  I think we could use the same approach we used to
> support 1.0 and 1.1 for cipher and random.  Of course, as you noted, the
> workload would increase to support additional versions, but I don't think
> implementing MAC would otherwise hamstring the overall effort.
>
>  new piece of code requires maintenance, so ideally only the minimal extra
> code should be added.  If in doubt, leave it out. It can be added later if
> it turns out to be needed, but once added, is much harder to drop.>
>
> Fair point, which I think ties into the earlier comment about whether the
> benefit of native performance applies equally to a MAC as it does to a
> cipher.  I suppose I could do a minimal implementation and run a bake-off
> to help determine whether the juice is worth the squeeze.  I know that I'd
> like to see if it makes a difference in my own project, but beyond that
> I've no idea what the demand is for MAC as a feature.
>

Let's give this a shot. I like simple solutions that work für 80% of the
use cases instead of complex ones that cover 99%. Why don't you create a PR
so we can discuss in more details how the final solution should look like?

Thank you!
Benedikt


>
> On Sat, Feb 23, 2019 at 6:01 AM sebb  wrote:
>
> > On Sat, 23 Feb 2019 at 02:33, Alex Remily  wrote:
> > >
> > >  > provide a
> > > more performant implementation to Java developers? If so I think it can
> > we
> > > added to crypto.>
> > >
> > > Yes.  My current thinking is that I'd simply expose the existing
> relevant
> > > OpenSSL functions via JNI and JNA by mapping them to the JCE API for
> the
> > > Mac class to the extent possible.  Essentially, I'd follow the
> > established
> > > pattern for the cipher and random functionality currently exposed.
> >
> > Seems like a good approach.
> >
> > Would this affect the attempt to support multiple OpenSSL versions?
> >
> > I'm not saying this applies here, but is something to be aware of:
> > Every new piece of code requires maintenance, so ideally only the
> > minimal extra code should be added.
> > If in doubt, leave it out. It can be added later if it turns out to be
> > needed, but once added, is much harder to drop.
> >
> > > On Fri, Feb 22, 2019 at 6:52 AM Benedikt Ritter 
> > wrote:
> > >
> > > > Hello Alex,
> > > >
> > > > welcome to the Apache Commons Developers list!
> > > >
> > > > Am Fr., 22. Feb. 2019 um 03:01 Uhr schrieb Alex Remily <
> > > > alex.rem...@gmail.com>:
> > > >
> > > > > Team,
> > > > >
> > > > > What do you think about adding HMAC and CMAC functionality to
> commons
> > > > > crypto?  I have a project I'd like to use it for, so I don't mind
> > working
> > > > > on the implementation, but I don't want to make the effort if
> > there's no
> > > > > support for the idea.
> > > > >
> > > >
> > > > I haven't done a lot of work on crypto and I'm not a crypto expert.
> So
> > I
> > > > can not say if your proposal fits into the scope of Commons Crypto.
> > However
> > > > the components description provides some guidance here:
> > > >
> > > > > Apache Commons Crypto is a cryptographic library optimized with
> > AES-NI
> > > > (Advanced Encryption Standard New Instructions). It provides Java API
> > for
> > > > both cipher level and Java stream level. Developers can use it to
> > implement
> > > > high performance AES encryption/decryption with the minimum code and
> > > > effort. Please note that Apache Commons Crypto doesn't implement the
> > > > cryptographic algorithm such as AES directly. It wraps to Openssl or
> > JCE
> > > > which implement the algorithms.
> > > >
> > > > Would your implementation be based on wrapping low level APIs to
> > provide a
> > > > more performant implementation to Java developers? If so I think it
> > can we
> > > > added to crypto.
> > > >
> > > > Regards,
> > > > Benedikt
> > > >
> > > >
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > Alex
> > > > >
> > > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: [crypto] Implementing HMAC and CMAC

[Benedikt Ritter]

Hello Alex,

welcome to the Apache Commons Developers list!

Am Fr., 22. Feb. 2019 um 03:01 Uhr schrieb Alex Remily <
alex.rem...@gmail.com>:

> Team,
>
> What do you think about adding HMAC and CMAC functionality to commons
> crypto?  I have a project I'd like to use it for, so I don't mind working
> on the implementation, but I don't want to make the effort if there's no
> support for the idea.
>

I haven't done a lot of work on crypto and I'm not a crypto expert. So I
can not say if your proposal fits into the scope of Commons Crypto. However
the components description provides some guidance here:

> Apache Commons Crypto is a cryptographic library optimized with AES-NI
(Advanced Encryption Standard New Instructions). It provides Java API for
both cipher level and Java stream level. Developers can use it to implement
high performance AES encryption/decryption with the minimum code and
effort. Please note that Apache Commons Crypto doesn't implement the
cryptographic algorithm such as AES directly. It wraps to Openssl or JCE
which implement the algorithms.

Would your implementation be based on wrapping low level APIs to provide a
more performant implementation to Java developers? If so I think it can we
added to crypto.

Regards,
Benedikt


>
> Thoughts?
>
> Alex
>

Re: [text] TEXT-104 clirr errors, prepare 2.0 or revert change

[Benedikt Ritter]

Am Mi., 20. Feb. 2019 um 08:58 Uhr schrieb Bruno P. Kinoshita <
ki...@apache.org>:

> Hi all,
> Just finished merging a pull request to TEXT-104, where the JaroWinkler
> distance was updated. The class was actually computing a text similarity
> score, not an edit distance. The user that contributed did a great job
> moving the logic into a separate class, then updating the method to return
> a distance instead.
> Later I realized this would break both behaviour and binary compatibility.
> So just wondering what others think. Is it time to gather a few more
> issues in text, maybe even consider updating libraries/java/etc, drop
> @Deprecated stuff, and prepare a 2.0? Or is it too soon, and instead revert
> moving the code to a branch, and update TEXT-104 with a note about the
> branch?
>

This would be a bad signal to the contributor. Do you think it's possible
to have both solutions side by side? So we keep the old class with the name
an interface, deprecate it and put the new solution in the same package
with a different class name?

Benedikt


> CheersBruno
>

Re: [LANG] Jenkins Pipeline DSL

[Benedikt Ritter]

I'm happy about the positive feedback. I'm currently a little bit busy at
work. I hope to be able to spike something at the end of next week.

Benedikt

Am Mo., 18. Feb. 2019 um 20:25 Uhr schrieb Matt Sicker :

> The DSL allows you to break out into parallel stages or sequential
> ones (or both). The log4net Jenkinsfile has an example of building
> across multiple agents:
>
>
> https://github.com/apache/logging-log4net/blob/feature/cd-pipeline/Jenkinsfile
>
> On Mon, 18 Feb 2019 at 12:44, sebb  wrote:
> >
> > Seems worth trying.
> >
> > I suggest start with one project (i.e. Lang) and see how well it works.
> >
> > I assume there will need to be a once-off change to Jenkins to switch
> > to using the DSL.
> >
> > Note that some components have multiple jobs, e.g. for different OSes
> and JVMs.
> > Does the DSL support such jobs? Or is that still done through the GUI?
> >
> > S.
> >
> > On Mon, 18 Feb 2019 at 18:05, Matt Sicker  wrote:
> > >
> > > +1. You could also make a shared library for reuse in commons projects.
> > >
> > > On Sun, 17 Feb 2019 at 14:41, Pascal Schumacher
> > >  wrote:
> > > >
> > > > +1 to using a pipeline
> > > >
> > > > Am 17.02.2019 um 18:35 schrieb Benedikt Ritter:
> > > > > Hi all,
> > > > >
> > > > > I feel like maintaining separate build descriptions on Jenkins is
> a PITA.
> > > > > Any objections against adopting Jenkins Pipeline DSL for Lang?
> > > > >
> > > > > Regards,
> > > > > Benedikt
> > > > >
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >
> > >
> > >
> > > --
> > > Matt Sicker 
> > >
> > > -
> > > 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
> >
>
>
> --
> Matt Sicker 
>
> -
> 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@

[Benedikt Ritter]

+1

Am Di., 19. Feb. 2019 um 22:35 Uhr 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.
>
> --
> Marcelo
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Jakarta EE TCKs and compatibility logo

[Benedikt Ritter]

Hi,

Which of our components implement Java EE APIs? I see:

- BSF: not sure anybody is actively working on this
- JCS: I've seen some activity

Anything else?

Benedikt

Am So., 17. Feb. 2019 um 20:01 Uhr schrieb Mark Thomas :

> Ping.
>
> Just a gentle reminder as I haven't seen any emails to jcp-open@ as yet.
>
> Mark
>
> PS If you don't want to build from source, there are nightly TCK builds
> available here:
> https://download.eclipse.org/ee4j/jakartaee-tck/8.0.1/nightly/
>
>
> On 21/01/2019 10:46, Mark Thomas wrote:
> > Apologies for the noise.
> >
> > The correct link for [3] is:
> >
> > https://jakarta.ee/legal/trademark_guidelines/
> >
> > I've also corrected a handful of the project BCCs.
> >
> > Mark
> >
> >
> > On 18/01/2019 22:53, Mark Thomas wrote:
> >> Hi all,
> >>
> >> I am writing to your dev@ lists (on BCC) as your project has, in the
> >> past, requested access to the Java EE TCKs while they were controlled by
> >> Sun and then Oracle.
> >>
> >> As I am sure you are aware, Java EE has moved to Eclipse and is now
> >> Jakarta EE. The good news is that the TCKs have been open sourced.
> >>
> >> https://github.com/eclipse-ee4j/jakartaee-tck
> >>
> >> (I haven't tried to build the latest TCK from source yet but it is on my
> >> TODO list.)
> >>
> >> Shipping compatible implementations of the Jakarta EE specs (and being
> >> able to make public statements to that effect) will be subject only to
> >> the spec [1] and TCK [2] licenses. There will no longer be a TCK
> >> agreement or NDA to sign. However...
> >>
> >> The question has arisen whether or not any ASF projects will want to use
> >> the Jakarta EE compatible logo [3]. If a project wants to be able to do
> >> this, there are some organisational hoops to jump through. Before the
> >> ASF starts down that path the board has asked me to see if there are any
> >> projects that want to use the Jakarta EE compatible logo. After all,
> >> there is no point jumping through the hoops if no-one wants to use the
> logo.
> >>
> >> With the above in mind can you please discuss this amongst your project
> >> community and reply back to jcp-o...@apache.org whether or not your
> >> project is interested in being able to use the Jakarta EE compatible
> >> logo. I ask that you complete this no later than the next board meeting
> >> (20th February 2019).
> >>
> >> If you have any questions about any of the above, please also use
> >> jcp-o...@apache.org to ask them.
> >>
> >> Thanks,
> >>
> >> Mark
> >>
> >>
> >> [1] https://www.eclipse.org/legal/efsl.php
> >> [2] https://www.eclipse.org/legal/tck.php
> >> [3] https://www.eclipse.org/legal/tck.php
> >>
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [LANG] Jenkins Pipeline DSL

[Benedikt Ritter]

Am So., 17. Feb. 2019 um 19:48 Uhr schrieb Gary Gregory <
garydgreg...@gmail.com>:

> This will be versioned in the repo just like we do for Travis?
>

Yes. It's a description of a jenkins job in a groovy DSL, see
https://jenkins.io/solutions/pipeline/


>
> Gary
>
> On Sun, Feb 17, 2019, 12:36 Benedikt Ritter 
> > Hi all,
> >
> > I feel like maintaining separate build descriptions on Jenkins is a PITA.
> > Any objections against adopting Jenkins Pipeline DSL for Lang?
> >
> > Regards,
> > Benedikt
> >
>

[LANG] Jenkins Pipeline DSL

[Benedikt Ritter]

Hi all,

I feel like maintaining separate build descriptions on Jenkins is a PITA.
Any objections against adopting Jenkins Pipeline DSL for Lang?

Regards,
Benedikt

Re: [CLI] Update from Java 5 to 7

[Benedikt Ritter]

+1

Am So., 10. Feb. 2019 um 13:47 Uhr schrieb Gary Gregory <
garydgreg...@gmail.com>:

> I propose we update Commons CLI from Java 5 to 7.
>
> Gary
>

Re: [CLI] Update Java version requirement

[Benedikt Ritter]

Gary was fast. Please respond to his thread :-)

Am So., 10. Feb. 2019 um 13:47 Uhr schrieb Benedikt Ritter <
brit...@apache.org>:

> Hi,
>
> CLI is currently build against Java 5. Should wo update the Java version
> requirement? What version should we require? Java 7? Java 8?
>
> Regards,
> Benedikt
>

[CLI] Update Java version requirement

[Benedikt Ritter]

Hi,

CLI is currently build against Java 5. Should wo update the Java version
requirement? What version should we require? Java 7? Java 8?

Regards,
Benedikt

[ALL] Broken builds

[Benedikt Ritter]

Hi,

several component have are broken builds on the master branch. Should be
change our policy for pushing to master to a pull request based model,
where each change has to pass the CI pipeline first? I think this would be
better as pushing stuff to master and then fixing it afterwards.

Benedikt

Re: [COLLECTIONS] japicmp:cmp is always skipped

[Benedikt Ritter]

Am Do., 20. Sep. 2018 um 12:13 Uhr schrieb Gilles <
gil...@harfang.homelinux.org>:

> On Thu, 20 Sep 2018 09:34:34 +0200, Benedikt Ritter wrote:
> > Hi,
> >
> > I'm currently working on getting the collections build to pass again.
> > We
> > can't use clirr anymore because it can't handle Java 8 default
> > methods.
> > I've replaced clirr with japicmp [1]. Problem is, that the
> > japicmp:cmp goal
> > is always skipped although I've added the profile.japicmp file to the
> > repository. Any idea?
>
> "japicmp" has been broken for months. [Rob may have more
> up-to-date information.]
> Problem (for [RNG]) was the opposite: It would run even when
>profile.japicmp
> was not present and would simply fail the build when there
> was not "older" version to compare against. :-/
>

I still haven't found a way to activate japicmp :-( Maybe I just have to
wait for the next release?

Benedikt


>
> Gilles
>
> > Regards,
> > Benedikt
> >
> > [1] https://github.com/apache/commons-collections/pull/54
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [ALL] Multiple things broken in commons build infrastructure

[Benedikt Ritter]

Am Do., 20. Sep. 2018 um 11:57 Uhr schrieb Gilles <
gil...@harfang.homelinux.org>:

> Hi.
>
> On Thu, 20 Sep 2018 09:01:34 +0200, Benedikt Ritter wrote:
> > Am Mi., 19. Sep. 2018 um 12:23 Uhr schrieb Gilles <
> > gil...@harfang.homelinux.org>:
> >
> >> Hi.
> >>
> >> On Wed, 19 Sep 2018 11:41:53 +0200, Benedikt Ritter wrote:
> >> > Hello,
> >> >
> >> > I'm trying to release commons-csv and there are multiple things
> >> > broken at
> >> > the moment:
> >> >
> >> > - the site build does not work because of COMMONSSITE-124
> >> > - the OSGi bundle symbolic name is generated incorrectly because
> >> fo
> >> > COMMONSSITE-125
> >> > - the commons-build-plugin goal prefix has been changed to from
> >> > commons to
> >> > commons-build, but no documentation has been updated. Neither our
> >> > release
> >> > documentation nor the plugin documentation. I had to dig into the
> >> git
> >> > history to find the commit that introduced the change. But there
> >> is
> >> > no
> >> > explanation why we need this change. I'm currently updating our
> >> > documentation to reflect the new plugin goal prefix.
> >> >
> >> > I'm asking everybody who works on commons-parent or the
> >> > commons-build-plugin to take special care because our release
> >> process
> >> > is
> >> > painful enough even without this detective work...
> >>
> >> +1
> >> But it is clearly not enough: things that used to work should not
> >> unexpectedly break, or if it does for a good reason, components
> >> should be updated in a timely manner, i.e. when the change occurred,
> >> not weeks, months or years later when nobody has a clue about the
> >> problem.
> >>
> >
> > Maybe we need to do more rigorous code reviews when these components
> > are
> > changed...
>
> Sure, but we can observe that code reviews are not a high
> priority in "Commons".
> For good or bad, checks rely almost solely on the output of
> automated tools.[1]
>

I don't see how automated build process help here. The build for
commons-collections has been broken for months... :-)

Benedikt


>
> >>
> >> Is it possible to set up Jenkins jobs (for all components) that
> >> would automatically pick up the current CP snapshot to detect most
> >> of the undesired changes?
> >>
> >
> > I think that would be possible but it would be a lot of work.
>
> Actually I'm asking whether it's possible to automate the creation
> of these jobs (i.e. "bulk" creation from a list of existing jobs,
> bypassing the Jenkins GUI, and doing the necessary changes on the
> fly).
>
> Gilles
>
> [1] Cf. the preeminence of a Clirr report over the analysis of
>  code functionality in real use-cases pre-release of RNG v1.1.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[RESULT][VOTE] Release Apache Commons CSV 1.6 based on RC1

[Benedikt Ritter]

Hi,

this vote passes with the following result:

Gary Gregory: +1
Bruno P. Kinoshita: +1
Sergio Fernández: +1 (non-binding)
Benedikt Ritter: +1

I'll continue with the release procedure.

Thank you
Benedikt

Am Mi., 19. Sep. 2018 um 14:31 Uhr schrieb Benedikt Ritter <
brit...@apache.org>:

> Hi,
>
> we have fixed some bugs and added some features since Commons CSV 1.5 has
> been released, so I would like to release Commons CSV 1.6 based on RC1
>
> Commons CSV 1.6 is available for review here:
>   https://dist.apache.org/repos/dist/dev/commons/csv/1.6-RC1/ (r29508)
>
> The tag is here:
>
> https://git-wip-us.apache.org/repos/asf?p=commons-csv.git;a=tag;h=3c2d7919f325d1f046dff55e139455693cc68005
>
> The Maven Artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/
>
> These are the Maven Artifacts and their hashes:
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6-sources.jar.asc
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-sources.jar.asc>
> (SHA1: 5ca098877478f554085dace80ef4bf484ec422c0)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6.jar.asc
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6.jar.asc>
> (SHA1: 2c637fa312b01e091b6bf5388bca4c40890b6f8a)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6-test-sources.jar.asc
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-test-sources.jar.asc>
> (SHA1: 3ac363851526e57f0b833faf9ae58d93769df377)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6.jar
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6.jar>
> (SHA1: 22b3c2f901af973a8ec4f24e80c8c0c77a600b79)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6.pom
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6.pom>
> (SHA1: 7d6919d5b7f35a736631b37cf07c6e146e02e2d6)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6-javadoc.jar
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-javadoc.jar>
> (SHA1: 1a912bc6e79af7903600cbc9ee7c365ee356c9af)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6.pom.asc
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6.pom.asc>
> (SHA1: 122fd1dd76797a3df6e21de7269f65843ade912c)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6-tests.jar
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-tests.jar>
> (SHA1: 25316661324eacc7f8f61a9f389cb9efe034e43f)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6-sources.jar
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-sources.jar>
> (SHA1: 7163d5c8c70c71d32507583a3f6297302b32fa71)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6-tests.jar.asc
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-tests.jar.asc>
> (SHA1: 0f148adef1676bb532170a6e4fffbbcf98f69dd5)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6-test-sources.jar
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-test-sources.jar>
> (SHA1: 5c5d54b48c86d4972a9894dbf35edcdc5656930f)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6-javadoc.jar.asc
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-javadoc.jar.asc>
> (SHA1: 2f03131beeab5cf5c38e0b19e85bd0d8dfe14fd2)
>
> I have tested this with Java 8 using Maven 3.5.4.
>
> Details of changes since 1.1 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/csv/1.6-RC1/RELEASE-NOTES.txt
>
> http://home.apache.org/~britter/commons/commons-csv-1.6-RC1/changes-report.html
>
> Site:
>   http://home.apache.org/~britter/commons/commons-csv-1.6-RC1/
> (note some *relative* links are broken and the 1.6 directories are not yet
> created - these will be OK once the site is deployed)
>
> Clirr Report (compared to 1.5):
>
> http://home.apache.org/~britter/commons/commons-csv-1.6-RC1/clirr-report.html
>
> RAT Report:
>
> http://home.apache.org/~britter/commons/commons-csv-1.6-RC1/rat-report.html
>

Re: [VOTE] Release Apache Commons CSV 1.6 based on RC1

[Benedikt Ritter]

+1

Am Mi., 19. Sep. 2018 um 14:31 Uhr schrieb Benedikt Ritter <
brit...@apache.org>:

> Hi,
>
> we have fixed some bugs and added some features since Commons CSV 1.5 has
> been released, so I would like to release Commons CSV 1.6 based on RC1
>
> Commons CSV 1.6 is available for review here:
>   https://dist.apache.org/repos/dist/dev/commons/csv/1.6-RC1/ (r29508)
>
> The tag is here:
>
> https://git-wip-us.apache.org/repos/asf?p=commons-csv.git;a=tag;h=3c2d7919f325d1f046dff55e139455693cc68005
>
> The Maven Artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/
>
> These are the Maven Artifacts and their hashes:
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6-sources.jar.asc
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-sources.jar.asc>
> (SHA1: 5ca098877478f554085dace80ef4bf484ec422c0)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6.jar.asc
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6.jar.asc>
> (SHA1: 2c637fa312b01e091b6bf5388bca4c40890b6f8a)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6-test-sources.jar.asc
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-test-sources.jar.asc>
> (SHA1: 3ac363851526e57f0b833faf9ae58d93769df377)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6.jar
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6.jar>
> (SHA1: 22b3c2f901af973a8ec4f24e80c8c0c77a600b79)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6.pom
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6.pom>
> (SHA1: 7d6919d5b7f35a736631b37cf07c6e146e02e2d6)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6-javadoc.jar
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-javadoc.jar>
> (SHA1: 1a912bc6e79af7903600cbc9ee7c365ee356c9af)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6.pom.asc
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6.pom.asc>
> (SHA1: 122fd1dd76797a3df6e21de7269f65843ade912c)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6-tests.jar
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-tests.jar>
> (SHA1: 25316661324eacc7f8f61a9f389cb9efe034e43f)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6-sources.jar
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-sources.jar>
> (SHA1: 7163d5c8c70c71d32507583a3f6297302b32fa71)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6-tests.jar.asc
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-tests.jar.asc>
> (SHA1: 0f148adef1676bb532170a6e4fffbbcf98f69dd5)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6-test-sources.jar
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-test-sources.jar>
> (SHA1: 5c5d54b48c86d4972a9894dbf35edcdc5656930f)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6-javadoc.jar.asc
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-javadoc.jar.asc>
> (SHA1: 2f03131beeab5cf5c38e0b19e85bd0d8dfe14fd2)
>
> I have tested this with Java 8 using Maven 3.5.4.
>
> Details of changes since 1.1 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/csv/1.6-RC1/RELEASE-NOTES.txt
>
> http://home.apache.org/~britter/commons/commons-csv-1.6-RC1/changes-report.html
>
> Site:
>   http://home.apache.org/~britter/commons/commons-csv-1.6-RC1/
> (note some *relative* links are broken and the 1.6 directories are not yet
> created - these will be OK once the site is deployed)
>
> Clirr Report (compared to 1.5):
>
> http://home.apache.org/~britter/commons/commons-csv-1.6-RC1/clirr-report.html
>
> RAT Report:
>
> http://home.apache.org/~britter/commons/commons-csv-1.6-RC1/rat-report.html
>
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
>
> Please review this release candidate and vote. This vote will close no
> sooner than 72 hours from now, i.e. sometime after 14:30 CEST 22-September
> 2018
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
> Thanks!
> Benedikt
>

Re: [VOTE] Release Apache Commons CSV 1.6 based on RC1

[Benedikt Ritter]

This vote is still pending. Please review the RC and cast your vote.

Thank you,
Benedikt

Am Mi., 19. Sep. 2018 um 14:31 Uhr schrieb Benedikt Ritter <
brit...@apache.org>:

> Hi,
>
> we have fixed some bugs and added some features since Commons CSV 1.5 has
> been released, so I would like to release Commons CSV 1.6 based on RC1
>
> Commons CSV 1.6 is available for review here:
>   https://dist.apache.org/repos/dist/dev/commons/csv/1.6-RC1/ (r29508)
>
> The tag is here:
>
> https://git-wip-us.apache.org/repos/asf?p=commons-csv.git;a=tag;h=3c2d7919f325d1f046dff55e139455693cc68005
>
> The Maven Artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/
>
> These are the Maven Artifacts and their hashes:
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6-sources.jar.asc
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-sources.jar.asc>
> (SHA1: 5ca098877478f554085dace80ef4bf484ec422c0)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6.jar.asc
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6.jar.asc>
> (SHA1: 2c637fa312b01e091b6bf5388bca4c40890b6f8a)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6-test-sources.jar.asc
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-test-sources.jar.asc>
> (SHA1: 3ac363851526e57f0b833faf9ae58d93769df377)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6.jar
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6.jar>
> (SHA1: 22b3c2f901af973a8ec4f24e80c8c0c77a600b79)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6.pom
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6.pom>
> (SHA1: 7d6919d5b7f35a736631b37cf07c6e146e02e2d6)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6-javadoc.jar
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-javadoc.jar>
> (SHA1: 1a912bc6e79af7903600cbc9ee7c365ee356c9af)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6.pom.asc
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6.pom.asc>
> (SHA1: 122fd1dd76797a3df6e21de7269f65843ade912c)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6-tests.jar
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-tests.jar>
> (SHA1: 25316661324eacc7f8f61a9f389cb9efe034e43f)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6-sources.jar
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-sources.jar>
> (SHA1: 7163d5c8c70c71d32507583a3f6297302b32fa71)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6-tests.jar.asc
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-tests.jar.asc>
> (SHA1: 0f148adef1676bb532170a6e4fffbbcf98f69dd5)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6-test-sources.jar
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-test-sources.jar>
> (SHA1: 5c5d54b48c86d4972a9894dbf35edcdc5656930f)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6-javadoc.jar.asc
> <https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-javadoc.jar.asc>
> (SHA1: 2f03131beeab5cf5c38e0b19e85bd0d8dfe14fd2)
>
> I have tested this with Java 8 using Maven 3.5.4.
>
> Details of changes since 1.1 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/csv/1.6-RC1/RELEASE-NOTES.txt
>
> http://home.apache.org/~britter/commons/commons-csv-1.6-RC1/changes-report.html
>
> Site:
>   http://home.apache.org/~britter/commons/commons-csv-1.6-RC1/
> (note some *relative* links are broken and the 1.6 directories are not yet
> created - these will be OK once the site is deployed)
>
> Clirr Report (compared to 1.5):
>
> http://home.apache.org/~britter/commons/commons-csv-1.6-RC1/clirr-report.html
>
> RAT Report:
>
> http://home.apache.org/~britter/commons/commons-csv-1.6-RC1/rat-report.html
>
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
>
> Please review this release candidate and vote. This vote will close no
> sooner than 72 hours from now, i.e. sometime after 14:30 CEST 22-September
> 2018
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
> Thanks!
> Benedikt
>

Re: Apache Commons CSV build does not work on Java 11 EA (Was: [VOTE] Release Apache Commons CSV 1.6 based on RC1)

[Benedikt Ritter]

Am Do., 20. Sep. 2018 um 18:19 Uhr schrieb Rory O'Donnell <
rory.odonn...@oracle.com>:

> Gary/Benedikt,
>
> I was advised by my JaCoCo contact that you are using JaCoCo version 0.8.1,
>
> while support for Java 11 was added in *0.8.2* - see
> https://www.jacoco.org/jacoco/trunk/doc/changes.html


Thank you Rory, we will update our build to use the latest JaCoCo version.


>
>
> Rgds,Rory
>
> On 20/09/2018 13:45, Gary Gregory wrote:
> > This seems to be a problem surfaced by JaCoCo.
> >
> > Gary
> >
> >
> > On Thu, Sep 20, 2018, 01:15 Benedikt Ritter  wrote:
> >
> >> Hello Rory,
> >>
> >> please see below - the Apache Commons CSV component can not be build on
> >> Windows using Java 11 EA. I did not have the time to investigate this
> yet,
> >> but maybe you're already aware of this?
> >>
> >> Regards,
> >> Benedikt
> >>
> >> -- Forwarded message -
> >> From: Gary Gregory 
> >> Date: Do., 20. Sep. 2018 um 02:30 Uhr
> >> Subject: Re: [VOTE] Release Apache Commons CSV 1.6 based on RC1
> >> To: Commons Developers List 
> >>
> >>
> >> +1
> >>
> >> bin zip: ASC, SHA512 OK
> >> src zip: ASC, SHA512 OK
> >>
> >>  From src zip:
> >>
> >> Builds OK with 'mvn -V clean package 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_181, vendor: Oracle Corporation, runtime: C:\Program
> >> Files\Java\jdk1.8.0_181\jre
> >> Default locale: en_US, platform encoding: Cp1252
> >> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> >>
> >> Maven apache-rat:check OK
> >> Maven clirr:check OK
> >>
> >> Generated reports OK.
> >>
> >> Running 'mvn clean package' OK with:
> >>
> >> 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: 9.0.4, vendor: Oracle Corporation, runtime: C:\Program
> >> Files\Java\jdk-9.0.4
> >> Default locale: en_US, platform encoding: Cp1252
> >> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> >>
> >> 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: 10.0.2, vendor: Oracle Corporation, runtime: C:\Program
> >> Files\Java\jdk-10.0.2
> >> Default locale: en_US, platform encoding: Cp1252
> >> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> >>
> >> FAILs with:
> >>
> >> 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: 11, vendor: Oracle Corporation, runtime: C:\Program
> >> Files\Java\jdk-11
> >> Default locale: en_US, platform encoding: Cp1252
> >> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> >>
> >> [INFO]
> >> 
> >> [INFO] BUILD FAILURE
> >> [INFO]
> >> 
> >> [INFO] Total time: 13.831 s
> >> [INFO] Finished at: 2018-09-19T18:30:03-06:00
> >> [INFO]
> >> 
> >> [ERROR] Failed to execute goal
> >> org.apache.maven.plugins:maven-surefire-plugin:2.22.0:test
> (default-test)
> >> on project commons-csv: There are test failures.
> >> [ERROR]
> >> [ERROR] Please refer to
> >> C:\temp\rc\commons-csv-1.6-src\target\surefire-reports for the
> individual
> >> test results.
> >> [ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump,
> >> [date].dumpstream and [date]-jvmRun[N].dumpstream.
> >> [ERROR] The forked VM terminated without properly saying goodbye. VM
> crash
> >> or System.exit called?
> >> [ERROR] Command was cmd.exe /X /C ""C

[COLLECTIONS] japicmp:cmp is always skipped

[Benedikt Ritter]

Hi,

I'm currently working on getting the collections build to pass again. We
can't use clirr anymore because it can't handle Java 8 default methods.
I've replaced clirr with japicmp [1]. Problem is, that the japicmp:cmp goal
is always skipped although I've added the profile.japicmp file to the
repository. Any idea?

Regards,
Benedikt

[1] https://github.com/apache/commons-collections/pull/54

Apache Commons CSV build does not work on Java 11 EA (Was: [VOTE] Release Apache Commons CSV 1.6 based on RC1)

[Benedikt Ritter]

re.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1194)
[ERROR] at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1022)
[ERROR] at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:868)
[ERROR] at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
[ERROR] at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
[ERROR] at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
[ERROR] at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
[ERROR] at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
[ERROR] at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
[ERROR] at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
[ERROR] at
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
[ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:954)
[ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
[ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:192)
[ERROR] at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[ERROR] at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[ERROR] at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[ERROR] at
java.base/java.lang.reflect.Method.invoke(Method.java:566)
[ERROR] at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
[ERROR] at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
[ERROR] at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
[ERROR] at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
[ERROR]

Gary


On Wed, Sep 19, 2018 at 6:31 AM Benedikt Ritter  wrote:

> Hi,
>
> we have fixed some bugs and added some features since Commons CSV 1.5 has
> been released, so I would like to release Commons CSV 1.6 based on RC1
>
> Commons CSV 1.6 is available for review here:
>   https://dist.apache.org/repos/dist/dev/commons/csv/1.6-RC1/ (r29508)
>
> The tag is here:
>
>
>
https://git-wip-us.apache.org/repos/asf?p=commons-csv.git;a=tag;h=3c2d7919f325d1f046dff55e139455693cc68005
>
> The Maven Artifacts are here:
>
>
>
https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/
>
> These are the Maven Artifacts and their hashes:
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6-sources.jar.asc
> <
>
https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-sources.jar.asc
> >
> (SHA1: 5ca098877478f554085dace80ef4bf484ec422c0)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6.jar.asc
> <
>
https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6.jar.asc
> >
> (SHA1: 2c637fa312b01e091b6bf5388bca4c40890b6f8a)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6-test-sources.jar.asc
> <
>
https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-test-sources.jar.asc
> >
> (SHA1: 3ac363851526e57f0b833faf9ae58d93769df377)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6.jar
> <
>
https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6.jar
> >
> (SHA1: 22b3c2f901af973a8ec4f24e80c8c0c77a600b79)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6.pom
> <
>
https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6.pom
> >
> (SHA1: 7d6919d5b7f35a736631b37cf07c6e146e02e2d6)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6-javadoc.jar
> <
>
https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-javadoc.jar
> >
> (SHA1: 1a912bc6e79af7903600cbc9ee7c365ee356c9af)
> /org/apache/commons/commons-csv/1.6/commons-csv-1.6.po

Re: [All] CP definitions (Was: svn commit: r1841296 [...])

[Benedikt Ritter]

Hello,

Reverting this change was discussed here [1]. It was a result of this
commit [2] breaking multiple component builds. As Stefan points out the
initial change does not make sense, since the componentId is always just
the name without "commons-" (e.g. math4). But the folders for all the
websites have the commons prefix (e.g. commons-math).

I just restored the old (working) behavior. I'm fine with making things
easier/more straight forward. But let's make sure that all the other
components still work.

Regards,
Benedikt

[1]
https://lists.apache.org/thread.html/304129bf7d25a2118ee3f324214c04e1e8f0846e7ee43a57b100a26e@%3Cdev.commons.apache.org%3E
[2]
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?r1=1831599&r2=1832339

Am Mi., 19. Sep. 2018 um 17:25 Uhr schrieb Gary Gregory <
garydgreg...@gmail.com>:

> On Wed, Sep 19, 2018 at 8:30 AM Rob Tompkins  wrote:
>
> > I think the plan moving forward here is that we should do the following:
> >
> > math
> > math4
> >
> > And change [parent] back to
> >
> > 
> >
> https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${commons.componentid}
> > 
> >
> > Yeah?
> >
>
> LGTM.
>
> Gary
>
>
> >
> > -Rob
> >
> > > On Sep 19, 2018, at 9:36 AM, Rob Tompkins  wrote:
> > >
> > >
> > >
> > >> On Sep 19, 2018, at 9:28 AM, Gilles 
> > wrote:
> > >>
> > >>> On Wed, 19 Sep 2018 06:45:13 -0600, Gary Gregory wrote:
> > >>> The difference is to account for artifact ids that contain a version
> > like
> > >>> commons-lang3. The component id is then just commons-lang. You must
> not
> > >>> have versions in names for certain names like in the download page.
> > This
> > >>> change will probably break builds like pool, dbcp, lang, and so on.
> > >>
> > >> Hmm, this completes the confusion!
> > >>
> > >> If "artifactId" is e.g. commons-lang3 then I don't understand how
> > >> the reverted line works because (AFAICT) the SVN URL is
> > >>
> >
> https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-lang/
> > >>
> > >> The [Math] POM contains these lines:
> > >> ---CUT---
> > >>   
> > >>   math4
> > >> ---CUT---
> > >> Correct or not?
> > >
> > > Half of the components are correct, half aren’t.
> > >
> > > What’s the consensus here? My thought was that componentId=math is
> > actually correct based on the documentation, and we need and
> > “artifactIdSuffix” or something analogous.
> > >
> > > -Rob
> > >
> > >>
> > >> It also uses a fix string:
> > >> ---CUT---
> > >> 
> >
> https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-math
> > 
> > >> ---CUT---
> > >> whereas a variable (as in the commit below) would seem more portable.
> > >>
> > >> Why isn't "" defined in CP only (using the
> > appropriate
> > >> variable overridden in each component)?
> > >>
> > >> Why having
> > >> ---CUT---
> > >> math
> > >> ---CUT---
> > >> that doesn't look at all like a "path"?
> > >> We could define a quite more explicit ""
> > >> that could serve for composing a path, as well as for any
> > >> other purpose where the component is meant, independently
> > >> of artefact identifier syntax or major version.
> > >>
> > >>
> > >> Regards,
> > >> Gilles
> > >>
> > >>> Gary
> > >>>
> >  On Wed, Sep 19, 2018, 04:07 Gilles 
> > wrote:
> > 
> >  Hi.
> > 
> >  Are we sure that the fix/revert below to work as intended for
> >  *all* components?
> > 
> >  Common usage should be enforced (e.g. to allow anyone to help
> >  releasing any component), and ancient inconsistencies fixed.
> > 
> >  With a concrete example of a component that has had major
> >  version changes (and top-level package change accordingly),
> >  what is
> >  commons.componentid
> >  and what is
> >  project.artefactId
> >  ?
> > 
> >  Thanks,
> >  Gilles
> > 
> >  On Wed, 19 Sep 2018 08:06:17 -, brit...@apache.org wrote:
> > > Author: britter
> > > Date: Wed Sep 19 08:06:17 2018
> > > New Revision: 1841296
> > >
> > > URL: http://svn.apache.org/viewvc?rev=1841296&view=rev
> > > Log:
> > > COMMONSSITE-124: Revert change in commons.scmPubUrl in Parent 47
> > >
> > > Modified:
> > >commons/proper/commons-parent/trunk/pom.xml
> > >commons/proper/commons-parent/trunk/src/changes/changes.xml
> > >
> > > Modified: commons/proper/commons-parent/trunk/pom.xml
> > > URL:
> > >
> > >
> > 
> >
> http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?rev=1841296&r1=1841295&r2=1841296&view=diff
> > >
> > >
> > 
> >
> ==
> > > --- commons/proper/commons-parent/trunk/pom.xml (original)
> > > +++ commons/proper/commons-parent/trunk/pom.xml Wed Sep 19 08:06:17
> > > 2018
> > > @@ -1940,7 +1940,7 @@
> > > 
> > > ${commons.componentid}
> > >
> 

Re: [ALL] Multiple things broken in commons build infrastructure

[Benedikt Ritter]

Am Mi., 19. Sep. 2018 um 12:23 Uhr schrieb Gilles <
gil...@harfang.homelinux.org>:

> Hi.
>
> On Wed, 19 Sep 2018 11:41:53 +0200, Benedikt Ritter wrote:
> > Hello,
> >
> > I'm trying to release commons-csv and there are multiple things
> > broken at
> > the moment:
> >
> > - the site build does not work because of COMMONSSITE-124
> > - the OSGi bundle symbolic name is generated incorrectly because fo
> > COMMONSSITE-125
> > - the commons-build-plugin goal prefix has been changed to from
> > commons to
> > commons-build, but no documentation has been updated. Neither our
> > release
> > documentation nor the plugin documentation. I had to dig into the git
> > history to find the commit that introduced the change. But there is
> > no
> > explanation why we need this change. I'm currently updating our
> > documentation to reflect the new plugin goal prefix.
> >
> > I'm asking everybody who works on commons-parent or the
> > commons-build-plugin to take special care because our release process
> > is
> > painful enough even without this detective work...
>
> +1
> But it is clearly not enough: things that used to work should not
> unexpectedly break, or if it does for a good reason, components
> should be updated in a timely manner, i.e. when the change occurred,
> not weeks, months or years later when nobody has a clue about the
> problem.
>

Maybe we need to do more rigorous code reviews when these components are
changed...


>
> Is it possible to set up Jenkins jobs (for all components) that
> would automatically pick up the current CP snapshot to detect most
> of the undesired changes?
>

I think that would be possible but it would be a lot of work.

Benedikt


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

Re: [lang3] Problem with the OSGi metadata: Bundle-SymbolicName / breaking change between 3.7 and 3.8

[Benedikt Ritter]

Am Mi., 19. Sep. 2018 um 16:42 Uhr schrieb Rob Tompkins :

> Do we have a JIRA for this?
>

Yes, it's LANG-1419 and COMMONSSITE-125

Benedikt


>
> > On Sep 19, 2018, at 7:59 AM, Benedikt Ritter  wrote:
> >
> > Hi,
> >
> > Am Mi., 19. Sep. 2018 um 13:44 Uhr schrieb Rob Tompkins <
> chtom...@gmail.com <mailto:chtom...@gmail.com>
> >> :
> >
> >>
> >>
> >>> On Sep 19, 2018, at 4:25 AM, Benedikt Ritter  <mailto:brit...@apache.org>> wrote:
> >>>
> >>> ... bringing this to the developers list...
> >>>
> >>> I think this issue has been caused by this change:
> >>>
> >>
> http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?r1=1833874&r2=1833926
> <
> http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?r1=1833874&r2=1833926
> >
> >>
> >> Do we roll a 3.8.1?
> >>
> >
> > I plan to do so once I've released commons-csv 1.6. We probably need to
> > create 3.8.1 based on the 3.8 release tag because we already introduced
> the
> > Java 8 changes on the master branch and I don't think those changes
> should
> > be included in a patch release.
> >
> > Regards,
> > Benedikt
> >
> >
> >>
> >> -Rob
> >>>
> >>> I don't understand why an update of the commons build plugin had to
> >> change
> >>> the OSGi meta data being generated. Maybe the change
> >>> to commons.osgi.symbolicName was by accident? Can it be reverted?
> >>>
> >>> Regards,
> >>> Benedikt
> >>>
> >>> Am Do., 6. Sep. 2018 um 21:35 Uhr schrieb P. Ottlinger <
> >>> pottlin...@apache.org>:
> >>>
> >>>> Hi,
> >>>>
> >>>> thanks for quick response ...
> >>>>
> >>>>> Am 06.09.2018 um 21:24 schrieb Oliver Heger:
> >>>>> So opening a ticket in Jira would be the correct action to take.
> >>>>
> >>>> https://issues.apache.org/jira/browse/LANG-1419
> >>>>
> >>>> Done :-) Hopefully I didn't miss any important stuff in Jira.
> >>>>
> >>>> Cheers,
> >>>> Phil
> >>>>
> >>>> -
> >>>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> >>>> For additional commands, e-mail: user-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>
>

Re: [VOTE] Release Apache Commons CSV 1.6 based on RC1

[Benedikt Ritter]

Hello Gary,

Am Mi., 19. Sep. 2018 um 14:51 Uhr schrieb Gary Gregory <
garydgreg...@gmail.com>:

> Note that we are NOT supposed to use SHA1 or MD5 anymore. Your vote message
> should provide SHA256 or SHA512. Note that the dist files do provide proper
> SHA file.
>

As far as I understood maven central can't deal with SHA256/SHA512 yet. So
I thought that SHA512 only go to the dist area.

Benedikt


>
> Gary
>
> On Wed, Sep 19, 2018, 06:31 Benedikt Ritter  wrote:
>
> > Hi,
> >
> > we have fixed some bugs and added some features since Commons CSV 1.5 has
> > been released, so I would like to release Commons CSV 1.6 based on RC1
> >
> > Commons CSV 1.6 is available for review here:
> >   https://dist.apache.org/repos/dist/dev/commons/csv/1.6-RC1/ (r29508)
> >
> > The tag is here:
> >
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=commons-csv.git;a=tag;h=3c2d7919f325d1f046dff55e139455693cc68005
> >
> > The Maven Artifacts are here:
> >
> >
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/
> >
> > These are the Maven Artifacts and their hashes:
> > /org/apache/commons/commons-csv/1.6/commons-csv-1.6-sources.jar.asc
> > <
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-sources.jar.asc
> > >
> > (SHA1: 5ca098877478f554085dace80ef4bf484ec422c0)
> > /org/apache/commons/commons-csv/1.6/commons-csv-1.6.jar.asc
> > <
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6.jar.asc
> > >
> > (SHA1: 2c637fa312b01e091b6bf5388bca4c40890b6f8a)
> > /org/apache/commons/commons-csv/1.6/commons-csv-1.6-test-sources.jar.asc
> > <
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-test-sources.jar.asc
> > >
> > (SHA1: 3ac363851526e57f0b833faf9ae58d93769df377)
> > /org/apache/commons/commons-csv/1.6/commons-csv-1.6.jar
> > <
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6.jar
> > >
> > (SHA1: 22b3c2f901af973a8ec4f24e80c8c0c77a600b79)
> > /org/apache/commons/commons-csv/1.6/commons-csv-1.6.pom
> > <
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6.pom
> > >
> > (SHA1: 7d6919d5b7f35a736631b37cf07c6e146e02e2d6)
> > /org/apache/commons/commons-csv/1.6/commons-csv-1.6-javadoc.jar
> > <
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-javadoc.jar
> > >
> > (SHA1: 1a912bc6e79af7903600cbc9ee7c365ee356c9af)
> > /org/apache/commons/commons-csv/1.6/commons-csv-1.6.pom.asc
> > <
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6.pom.asc
> > >
> > (SHA1: 122fd1dd76797a3df6e21de7269f65843ade912c)
> > /org/apache/commons/commons-csv/1.6/commons-csv-1.6-tests.jar
> > <
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-tests.jar
> > >
> > (SHA1: 25316661324eacc7f8f61a9f389cb9efe034e43f)
> > /org/apache/commons/commons-csv/1.6/commons-csv-1.6-sources.jar
> > <
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-sources.jar
> > >
> > (SHA1: 7163d5c8c70c71d32507583a3f6297302b32fa71)
> > /org/apache/commons/commons-csv/1.6/commons-csv-1.6-tests.jar.asc
> > <
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-tests.jar.asc
> > >
> > (SHA1: 0f148adef1676bb532170a6e4fffbbcf98f69dd5)
> > /org/apache/commons/commons-csv/1.6/commons-csv-1.6-test-sources.jar
> > <
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-test-sources.jar
> > >
> > (SHA1: 5c5d54b48c86d4972a9894dbf35edcdc5656930f)
> > /org/apache/commons/commons-csv/1.6/commons-csv-1.6-javadoc.jar.asc
> > <
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/commons-csv-1.6-javadoc.jar.asc
> > &

[VOTE] Release Apache Commons CSV 1.6 based on RC1

[Benedikt Ritter]

Hi,

we have fixed some bugs and added some features since Commons CSV 1.5 has
been released, so I would like to release Commons CSV 1.6 based on RC1

Commons CSV 1.6 is available for review here:
  https://dist.apache.org/repos/dist/dev/commons/csv/1.6-RC1/ (r29508)

The tag is here:

https://git-wip-us.apache.org/repos/asf?p=commons-csv.git;a=tag;h=3c2d7919f325d1f046dff55e139455693cc68005

The Maven Artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1380/org/apache/commons/commons-csv/1.6/

These are the Maven Artifacts and their hashes:
/org/apache/commons/commons-csv/1.6/commons-csv-1.6-sources.jar.asc

(SHA1: 5ca098877478f554085dace80ef4bf484ec422c0)
/org/apache/commons/commons-csv/1.6/commons-csv-1.6.jar.asc

(SHA1: 2c637fa312b01e091b6bf5388bca4c40890b6f8a)
/org/apache/commons/commons-csv/1.6/commons-csv-1.6-test-sources.jar.asc

(SHA1: 3ac363851526e57f0b833faf9ae58d93769df377)
/org/apache/commons/commons-csv/1.6/commons-csv-1.6.jar

(SHA1: 22b3c2f901af973a8ec4f24e80c8c0c77a600b79)
/org/apache/commons/commons-csv/1.6/commons-csv-1.6.pom

(SHA1: 7d6919d5b7f35a736631b37cf07c6e146e02e2d6)
/org/apache/commons/commons-csv/1.6/commons-csv-1.6-javadoc.jar

(SHA1: 1a912bc6e79af7903600cbc9ee7c365ee356c9af)
/org/apache/commons/commons-csv/1.6/commons-csv-1.6.pom.asc

(SHA1: 122fd1dd76797a3df6e21de7269f65843ade912c)
/org/apache/commons/commons-csv/1.6/commons-csv-1.6-tests.jar

(SHA1: 25316661324eacc7f8f61a9f389cb9efe034e43f)
/org/apache/commons/commons-csv/1.6/commons-csv-1.6-sources.jar

(SHA1: 7163d5c8c70c71d32507583a3f6297302b32fa71)
/org/apache/commons/commons-csv/1.6/commons-csv-1.6-tests.jar.asc

(SHA1: 0f148adef1676bb532170a6e4fffbbcf98f69dd5)
/org/apache/commons/commons-csv/1.6/commons-csv-1.6-test-sources.jar

(SHA1: 5c5d54b48c86d4972a9894dbf35edcdc5656930f)
/org/apache/commons/commons-csv/1.6/commons-csv-1.6-javadoc.jar.asc

(SHA1: 2f03131beeab5cf5c38e0b19e85bd0d8dfe14fd2)

I have tested this with Java 8 using Maven 3.5.4.

Details of changes since 1.1 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/csv/1.6-RC1/RELEASE-NOTES.txt

http://home.apache.org/~britter/commons/commons-csv-1.6-RC1/changes-report.html

Site:
  http://home.apache.org/~britter/commons/commons-csv-1.6-RC1/
(note some *relative* links are broken and the 1.6 directories are not yet
created - these will be OK once the site is deployed)

Clirr Report (compared to 1.5):

http://home.apache.org/~britter/commons/commons-csv-1.6-RC1/clirr-report.html

RAT Report:

http://home.apache.org/~britter/commons/commons-csv-1.6-RC1/rat-report.html

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

Please review this release candidate and vote. This vote will close no
sooner than 72 hours from now, i.e. sometime after 14:30 CEST 22-September
2018

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

Thanks!
Benedikt

Re: [lang3] Problem with the OSGi metadata: Bundle-SymbolicName / breaking change between 3.7 and 3.8

[Benedikt Ritter]

Hi,

Am Mi., 19. Sep. 2018 um 13:44 Uhr schrieb Rob Tompkins :

>
>
> > On Sep 19, 2018, at 4:25 AM, Benedikt Ritter  wrote:
> >
> > ... bringing this to the developers list...
> >
> > I think this issue has been caused by this change:
> >
> http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?r1=1833874&r2=1833926
>
> Do we roll a 3.8.1?
>

I plan to do so once I've released commons-csv 1.6. We probably need to
create 3.8.1 based on the 3.8 release tag because we already introduced the
Java 8 changes on the master branch and I don't think those changes should
be included in a patch release.

Regards,
Benedikt


>
> -Rob
> >
> > I don't understand why an update of the commons build plugin had to
> change
> > the OSGi meta data being generated. Maybe the change
> > to commons.osgi.symbolicName was by accident? Can it be reverted?
> >
> > Regards,
> > Benedikt
> >
> > Am Do., 6. Sep. 2018 um 21:35 Uhr schrieb P. Ottlinger <
> > pottlin...@apache.org>:
> >
> >> Hi,
> >>
> >> thanks for quick response ...
> >>
> >>> Am 06.09.2018 um 21:24 schrieb Oliver Heger:
> >>> So opening a ticket in Jira would be the correct action to take.
> >>
> >> https://issues.apache.org/jira/browse/LANG-1419
> >>
> >> Done :-) Hopefully I didn't miss any important stuff in Jira.
> >>
> >> Cheers,
> >> Phil
> >>
> >> -
> >> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: user-h...@commons.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[ALL] Multiple things broken in commons build infrastructure

[Benedikt Ritter]

Hello,

I'm trying to release commons-csv and there are multiple things broken at
the moment:

- the site build does not work because of COMMONSSITE-124
- the OSGi bundle symbolic name is generated incorrectly because fo
COMMONSSITE-125
- the commons-build-plugin goal prefix has been changed to from commons to
commons-build, but no documentation has been updated. Neither our release
documentation nor the plugin documentation. I had to dig into the git
history to find the commit that introduced the change. But there is no
explanation why we need this change. I'm currently updating our
documentation to reflect the new plugin goal prefix.

I'm asking everybody who works on commons-parent or the
commons-build-plugin to take special care because our release process is
painful enough even without this detective work...

Regards,
Benedikt

Re: [lang3] Problem with the OSGi metadata: Bundle-SymbolicName / breaking change between 3.7 and 3.8

[Benedikt Ritter]

I've checked the commons-csv build, since commons-lang is somehow special
because of the componentId being lang3 (we talked about this on the other
thread). It looks like this change also broke commons-csv. I think we
should revert it.

Benedikt

Am Mi., 19. Sep. 2018 um 10:25 Uhr schrieb Benedikt Ritter <
brit...@apache.org>:

> ... bringing this to the developers list...
>
> I think this issue has been caused by this change:
> http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?r1=1833874&r2=1833926
>
> I don't understand why an update of the commons build plugin had to change
> the OSGi meta data being generated. Maybe the change
> to commons.osgi.symbolicName was by accident? Can it be reverted?
>
> Regards,
> Benedikt
>
> Am Do., 6. Sep. 2018 um 21:35 Uhr schrieb P. Ottlinger <
> pottlin...@apache.org>:
>
>> Hi,
>>
>> thanks for quick response ...
>>
>> Am 06.09.2018 um 21:24 schrieb Oliver Heger:
>> > So opening a ticket in Jira would be the correct action to take.
>>
>> https://issues.apache.org/jira/browse/LANG-1419
>>
>> Done :-) Hopefully I didn't miss any important stuff in Jira.
>>
>> Cheers,
>> Phil
>>
>> -
>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>> For additional commands, e-mail: user-h...@commons.apache.org
>>
>>

Re: [lang3] Problem with the OSGi metadata: Bundle-SymbolicName / breaking change between 3.7 and 3.8

[Benedikt Ritter]

... bringing this to the developers list...

I think this issue has been caused by this change:
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?r1=1833874&r2=1833926

I don't understand why an update of the commons build plugin had to change
the OSGi meta data being generated. Maybe the change
to commons.osgi.symbolicName was by accident? Can it be reverted?

Regards,
Benedikt

Am Do., 6. Sep. 2018 um 21:35 Uhr schrieb P. Ottlinger <
pottlin...@apache.org>:

> Hi,
>
> thanks for quick response ...
>
> Am 06.09.2018 um 21:24 schrieb Oliver Heger:
> > So opening a ticket in Jira would be the correct action to take.
>
> https://issues.apache.org/jira/browse/LANG-1419
>
> Done :-) Hopefully I didn't miss any important stuff in Jira.
>
> Cheers,
> Phil
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
>

Re: [parent] change in commons.scmPubUrl in Parent 47

[Benedikt Ritter]

Am Do., 6. Sep. 2018 um 09:52 Uhr schrieb Benedikt Ritter <
brit...@apache.org>:

> I have created COMMONSSITE-124 [1] in order to fix this. Will implement a
> fix later today.
>
> Benedikt
>
> [1] https://issues.apache.org/jira/browse/COMMONSSITE-124
>

COMMONSSITE-124 has been resolved in r1841296 [1]. To fix component site
builds using commons-parent 47 add the following to the properties section
of your pom.xml:



https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${project.artifactId}


Benedikt

[1] http://svn.apache.org/viewvc?view=revision&revision=1841296


>
> Am Fr., 31. Aug. 2018 um 13:24 Uhr schrieb Benedikt Ritter <
> brit...@apache.org>:
>
>>
>>
>> Am Fr., 31. Aug. 2018 um 11:38 Uhr schrieb sebb :
>>
>>> On 31 August 2018 at 10:16, Benedikt Ritter  wrote:
>>> > Hello,
>>> >
>>> > I upgraded commons-csv from parent v43 to parent v47. Now the site
>>> build
>>> > doesn't work anymore (see below). I think we should roll back said
>>> chance,
>>> > since it broke multiple working component builds.
>>>
>>> Which change are you talking about?
>>>
>>
>> The one from the thread title...
>>
>>
>>>
>>> Note that if a CP version causes problems, just don't use it.
>>> Either revert to an earlier version or release a new one that fixes
>>> the issue and then use that.
>>>
>>> > Benedikt
>>> >
>>> > commons-csv build log:
>>> >
>>> > ~/w/a/c/commons-csv git:(master) 1M > mvn site
>>> > [INFO] Scanning for projects...
>>> > [INFO]
>>> > [INFO] ---< org.apache.commons:commons-csv
>>> >>---
>>> > [INFO] Building Apache Commons CSV 1.6-SNAPSHOT
>>> > [INFO] [ jar
>>> > ]-
>>> > [INFO]
>>> > [INFO] --- maven-antrun-plugin:1.8:run (prepare-checkout) @
>>> commons-csv ---
>>> > [WARNING] Parameter tasks is deprecated, use target instead
>>> > [INFO] Executing tasks
>>> >
>>> > main:
>>> >  [exec] svn: E17: URL '
>>> >
>>> https://svn.apache.org/repos/infra/websites/production/commons/content/proper/csv
>>> '
>>> > doesn't exist
>>> >  [exec] Result: 1
>>> >  [exec] Skipped '/Users/bene/commons-sites/csv/javadocs'
>>> >  [exec] svn: E155007: None of the targets are working copies
>>> >  [exec] Result: 1
>>> > [INFO]
>>> >
>>> 
>>> > [INFO] BUILD FAILURE
>>> > [INFO]
>>> >
>>> 
>>> > [INFO] Total time: 3.199 s
>>> > [INFO] Finished at: 2018-08-31T11:13:39+02:00
>>> > [INFO]
>>> >
>>> 
>>> > [ERROR] Failed to execute goal
>>> > org.apache.maven.plugins:maven-antrun-plugin:1.8:run
>>> (prepare-checkout) on
>>> > project commons-csv: An Ant BuildException has occured:
>>> > /Users/bene/commons-sites/csv does not exist.
>>> > [ERROR] around Ant part .. @
>>> > 10:44 in
>>> >
>>> /Users/bene/workspace/apache/commons/commons-csv/target/antrun/build-main.xml
>>> > [ERROR] -> [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 Mi., 22. Aug. 2018 um 21:22 Uhr schrieb Benedikt Ritter <
>>> > brit...@apache.org>:
>>> >
>>> >>
>>> >>
>>> >> Am Mi., 22. Aug. 2018 um 14:33 Uhr schrieb Gilles <
>>> >> gil...@harfang.homelinux.org>:
>>> >>
>>> >>> On Wed, 22 Aug 2018 08:11:03 -0400, Rob Tompkins w

Re: [parent] change in commons.scmPubUrl in Parent 47

[Benedikt Ritter]

I have created COMMONSSITE-124 [1] in order to fix this. Will implement a
fix later today.

Benedikt

[1] https://issues.apache.org/jira/browse/COMMONSSITE-124

Am Fr., 31. Aug. 2018 um 13:24 Uhr schrieb Benedikt Ritter <
brit...@apache.org>:

>
>
> Am Fr., 31. Aug. 2018 um 11:38 Uhr schrieb sebb :
>
>> On 31 August 2018 at 10:16, Benedikt Ritter  wrote:
>> > Hello,
>> >
>> > I upgraded commons-csv from parent v43 to parent v47. Now the site build
>> > doesn't work anymore (see below). I think we should roll back said
>> chance,
>> > since it broke multiple working component builds.
>>
>> Which change are you talking about?
>>
>
> The one from the thread title...
>
>
>>
>> Note that if a CP version causes problems, just don't use it.
>> Either revert to an earlier version or release a new one that fixes
>> the issue and then use that.
>>
>> > Benedikt
>> >
>> > commons-csv build log:
>> >
>> > ~/w/a/c/commons-csv git:(master) 1M > mvn site
>> > [INFO] Scanning for projects...
>> > [INFO]
>> > [INFO] ---< org.apache.commons:commons-csv
>> >>---
>> > [INFO] Building Apache Commons CSV 1.6-SNAPSHOT
>> > [INFO] [ jar
>> > ]-
>> > [INFO]
>> > [INFO] --- maven-antrun-plugin:1.8:run (prepare-checkout) @ commons-csv
>> ---
>> > [WARNING] Parameter tasks is deprecated, use target instead
>> > [INFO] Executing tasks
>> >
>> > main:
>> >  [exec] svn: E17: URL '
>> >
>> https://svn.apache.org/repos/infra/websites/production/commons/content/proper/csv
>> '
>> > doesn't exist
>> >  [exec] Result: 1
>> >  [exec] Skipped '/Users/bene/commons-sites/csv/javadocs'
>> >  [exec] svn: E155007: None of the targets are working copies
>> >  [exec] Result: 1
>> > [INFO]
>> > 
>> > [INFO] BUILD FAILURE
>> > [INFO]
>> > 
>> > [INFO] Total time: 3.199 s
>> > [INFO] Finished at: 2018-08-31T11:13:39+02:00
>> > [INFO]
>> > 
>> > [ERROR] Failed to execute goal
>> > org.apache.maven.plugins:maven-antrun-plugin:1.8:run (prepare-checkout)
>> on
>> > project commons-csv: An Ant BuildException has occured:
>> > /Users/bene/commons-sites/csv does not exist.
>> > [ERROR] around Ant part ..
>> @
>> > 10:44 in
>> >
>> /Users/bene/workspace/apache/commons/commons-csv/target/antrun/build-main.xml
>> > [ERROR] -> [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 Mi., 22. Aug. 2018 um 21:22 Uhr schrieb Benedikt Ritter <
>> > brit...@apache.org>:
>> >
>> >>
>> >>
>> >> Am Mi., 22. Aug. 2018 um 14:33 Uhr schrieb Gilles <
>> >> gil...@harfang.homelinux.org>:
>> >>
>> >>> On Wed, 22 Aug 2018 08:11:03 -0400, Rob Tompkins wrote:
>> >>> >> On Aug 22, 2018, at 1:47 AM, Benedikt Ritter 
>> >>> >> wrote:
>> >>> >>
>> >>> >> Hi,
>> >>> >>
>> >>> >> I don't understand this discussion. Changes in Commons Parent have
>> >>> >> broken
>> >>> >> the commons-compress build. So we should either roll this changes
>> >>> >> back or
>> >>> >> those who need the changes in commons parent should fix the commons
>> >>> >> compress build.
>> >>> >
>> >>> > I think the problem at hand here is that we, across our projects,
>> are
>> >>> > inconsistent with our usage of componentId, so naturally any changes
>> >>> > to the way we consume 

Re: [VOTE] Release Apache Commons Weaver 2.0 based on RC1

[Benedikt Ritter]

Hello Matt,

- sigs and hashes are ok
- build from source archive
- website looks okay, but it still points to the SVN repo (see the other
thread on this list)
- there are some differences between release tag and source archive:

~/w/a/r/r/b/release-verification git:(master) 1M > diff -wqr
commons-weaver/ dist/source/commons-weaver-2.0-src
Only in commons-weaver/: .git
Only in commons-weaver/: .gitignore
Only in commons-weaver/: .travis.yml
Files commons-weaver/BUILDING.txt and
dist/source/commons-weaver-2.0-src/BUILDING.txt differ
Only in dist/source/commons-weaver-2.0-src/ant: pom.xml.releaseBackup
Only in dist/source/commons-weaver-2.0-src/build-tools:
pom.xml.releaseBackup
Only in dist/source/commons-weaver-2.0-src/dist: pom.xml.releaseBackup
Only in dist/source/commons-weaver-2.0-src/maven-plugin:
pom.xml.releaseBackup
Only in dist/source/commons-weaver-2.0-src/modules/normalizer:
pom.xml.releaseBackup
Only in dist/source/commons-weaver-2.0-src/modules: pom.xml.releaseBackup
Only in dist/source/commons-weaver-2.0-src/modules/privilizer/api:
pom.xml.releaseBackup
Only in dist/source/commons-weaver-2.0-src/modules/privilizer:
pom.xml.releaseBackup
Only in dist/source/commons-weaver-2.0-src/modules/privilizer/weaver:
pom.xml.releaseBackup
Only in dist/source/commons-weaver-2.0-src/parent: pom.xml.releaseBackup
Only in dist/source/commons-weaver-2.0-src: pom.xml.releaseBackup
Only in dist/source/commons-weaver-2.0-src/processor: pom.xml.releaseBackup
Only in dist/source/commons-weaver-2.0-src: release.properties

+1

Benedikt


Am Di., 4. Sep. 2018 um 17:58 Uhr schrieb Matt Benson :

> I would like to release the [weaver] component.
>
> Apache Commons Weaver 2.0 RC1 is available for review at:
>   *https://dist.apache.org/repos/dist/dev/commons/weaver/2.0-RC1/
> *
> (r29084).
>
> Maven artifacts are at:
>   https://repository.apache.org/content/repositories/orgapachecommons-1377
> .
>
> Tested with Oracle JDKs 8 and 10.
>
> The Git tag is:
>
>
> https://gitbox.apache.org/repos/asf?p=commons-weaver.git;a=tag;h=0eed2d07008fd2bfad32b6f8a03da0299cc61d65
> .
>
> Site (note some links may be broken; this will be fixed when the site
> is deployed):
>
>
> https://dist.apache.org/repos/dist/dev/commons/weaver/2.0-RC1/site/index.html
>
> RAT Report:
>
>
> https://dist.apache.org/repos/dist/dev/commons/weaver/2.0-RC1/site/rat-report.html
>
> Quality Reports (PMD/Checkstyle/Findbugs/japicmp):
>
>
> https://dist.apache.org/repos/dist/dev/commons/weaver/2.0-RC1/site/commons-weaver-parent/commons-weaver-processor/project-reports.html
>
>
> https://dist.apache.org/repos/dist/dev/commons/weaver/2.0-RC1/site/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-privilizer-parent/commons-weaver-privilizer-api/project-reports.html
>
>
> https://dist.apache.org/repos/dist/dev/commons/weaver/2.0-RC1/site/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-privilizer-parent/commons-weaver-privilizer/project-reports.html
>
>
> https://dist.apache.org/repos/dist/dev/commons/weaver/2.0-RC1/site/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-normalizer/project-reports.html
>
>
> https://dist.apache.org/repos/dist/dev/commons/weaver/2.0-RC1/site/commons-weaver-parent/commons-weaver-maven-plugin/project-reports.html
>
>
> https://dist.apache.org/repos/dist/dev/commons/weaver/2.0-RC1/site/commons-weaver-parent/commons-weaver-antlib/project-reports.html
>
> Keys: https://dist.apache.org/repos/dist/release/commons/KEYS
>
> Please review the release candidate and vote.
>   This vote will close no sooner than 72 hours from now, i.e. after
> 1600UTC 7-September 2018
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
>   Thanks!
>

Re: [WEAVER] Incomplete git migration?

[Benedikt Ritter]

Thank you for the information!

Benedikt

Am Mi., 5. Sep. 2018 um 10:17 Uhr schrieb Bruno P. Kinoshita
:

> I think you are probably correct about the SVN part being incomplete.
> As for the git repository, in a discussion about  Apache Sis about moving
> to git, I learned that those git-wip repositories are being transitioned
> into gitbox (wonder if the wip actually means work-in-progress?). Can't
> find the link, but there was actually an INFRA ticket somewhere where
> someone mentioned it.
>
> Anyhoo, you should find the link for the gitbox repositories here
> https://gitbox.apache.org/repos/asf, including commons-weaver, as well as
> a few other commons components. I think the other repositories will be
> slowly moved over there too.
>
> Hope that helps,Bruno
>
>   From: Benedikt Ritter 
>  To: Commons Developers List 
>  Sent: Wednesday, 5 September 2018 6:46 PM
>  Subject: [WEAVER] Incomplete git migration?
>
> Hi,
>
> I'm trying to check the latest commons weaver RC but I can't find the
> source repository. Matt posted a link to a Git tag, so I suspect the weaver
> uses git. If that is the case, it looks to me like the git migration is
> incomplete. The old source tree in SVN is still in it's place and has not
> been moved to the moved_to_git folder. Further more the website still has
> SVN URLs which should be updated to the new git URLs. Commons Weaver
> doesn't show up on http://git.apache.org. I tried
> https://git-wip-us.apache.org/repos/asf/commons-weaver.git but there is no
> repository there. Where can I find the codebase?
>
> Regards,
> Benedikt
>
>
>

[WEAVER] Incomplete git migration?

[Benedikt Ritter]

Hi,

I'm trying to check the latest commons weaver RC but I can't find the
source repository. Matt posted a link to a Git tag, so I suspect the weaver
uses git. If that is the case, it looks to me like the git migration is
incomplete. The old source tree in SVN is still in it's place and has not
been moved to the moved_to_git folder. Further more the website still has
SVN URLs which should be updated to the new git URLs. Commons Weaver
doesn't show up on http://git.apache.org. I tried
https://git-wip-us.apache.org/repos/asf/commons-weaver.git but there is no
repository there. Where can I find the codebase?

Regards,
Benedikt

Re: [parent] change in commons.scmPubUrl in Parent 47

[Benedikt Ritter]

Am Fr., 31. Aug. 2018 um 11:38 Uhr schrieb sebb :

> On 31 August 2018 at 10:16, Benedikt Ritter  wrote:
> > Hello,
> >
> > I upgraded commons-csv from parent v43 to parent v47. Now the site build
> > doesn't work anymore (see below). I think we should roll back said
> chance,
> > since it broke multiple working component builds.
>
> Which change are you talking about?
>

The one from the thread title...


>
> Note that if a CP version causes problems, just don't use it.
> Either revert to an earlier version or release a new one that fixes
> the issue and then use that.
>
> > Benedikt
> >
> > commons-csv build log:
> >
> > ~/w/a/c/commons-csv git:(master) 1M > mvn site
> > [INFO] Scanning for projects...
> > [INFO]
> > [INFO] ---< org.apache.commons:commons-csv
> >>---
> > [INFO] Building Apache Commons CSV 1.6-SNAPSHOT
> > [INFO] [ jar
> > ]-
> > [INFO]
> > [INFO] --- maven-antrun-plugin:1.8:run (prepare-checkout) @ commons-csv
> ---
> > [WARNING] Parameter tasks is deprecated, use target instead
> > [INFO] Executing tasks
> >
> > main:
> >  [exec] svn: E17: URL '
> >
> https://svn.apache.org/repos/infra/websites/production/commons/content/proper/csv
> '
> > doesn't exist
> >  [exec] Result: 1
> >  [exec] Skipped '/Users/bene/commons-sites/csv/javadocs'
> >  [exec] svn: E155007: None of the targets are working copies
> >  [exec] Result: 1
> > [INFO]
> > 
> > [INFO] BUILD FAILURE
> > [INFO]
> > 
> > [INFO] Total time: 3.199 s
> > [INFO] Finished at: 2018-08-31T11:13:39+02:00
> > [INFO]
> > 
> > [ERROR] Failed to execute goal
> > org.apache.maven.plugins:maven-antrun-plugin:1.8:run (prepare-checkout)
> on
> > project commons-csv: An Ant BuildException has occured:
> > /Users/bene/commons-sites/csv does not exist.
> > [ERROR] around Ant part .. @
> > 10:44 in
> >
> /Users/bene/workspace/apache/commons/commons-csv/target/antrun/build-main.xml
> > [ERROR] -> [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 Mi., 22. Aug. 2018 um 21:22 Uhr schrieb Benedikt Ritter <
> > brit...@apache.org>:
> >
> >>
> >>
> >> Am Mi., 22. Aug. 2018 um 14:33 Uhr schrieb Gilles <
> >> gil...@harfang.homelinux.org>:
> >>
> >>> On Wed, 22 Aug 2018 08:11:03 -0400, Rob Tompkins wrote:
> >>> >> On Aug 22, 2018, at 1:47 AM, Benedikt Ritter 
> >>> >> wrote:
> >>> >>
> >>> >> Hi,
> >>> >>
> >>> >> I don't understand this discussion. Changes in Commons Parent have
> >>> >> broken
> >>> >> the commons-compress build. So we should either roll this changes
> >>> >> back or
> >>> >> those who need the changes in commons parent should fix the commons
> >>> >> compress build.
> >>> >
> >>> > I think the problem at hand here is that we, across our projects, are
> >>> > inconsistent with our usage of componentId, so naturally any changes
> >>> > to the way we consume it in the parent are breaking changes. For
> >>> > example:
> >>> >
> >>> > https://github.com/apache/commons-lang/blob/master/pom.xml#L573
> >>> > <https://github.com/apache/commons-lang/blob/master/pom.xml#L573>
> >>>
> >>> This one is wrong, according to a convention explicitly mentioned
> >>> in some POM files, e.g.:
> >>> ---CUT---
> >>>  
> >>>  rng
> >>> ---CUT---
> >>>
> >>
> >> I've raised LANG-1414 [1] to fix this.
> >>
> >> Benedikt
> >>
> >> [1] https://is

Re: [parent] change in commons.scmPubUrl in Parent 47

[Benedikt Ritter]

Hello,

I upgraded commons-csv from parent v43 to parent v47. Now the site build
doesn't work anymore (see below). I think we should roll back said chance,
since it broke multiple working component builds.

Benedikt

commons-csv build log:

~/w/a/c/commons-csv git:(master) 1M > mvn site
[INFO] Scanning for projects...
[INFO]
[INFO] ---< org.apache.commons:commons-csv
>---
[INFO] Building Apache Commons CSV 1.6-SNAPSHOT
[INFO] [ jar
]-
[INFO]
[INFO] --- maven-antrun-plugin:1.8:run (prepare-checkout) @ commons-csv ---
[WARNING] Parameter tasks is deprecated, use target instead
[INFO] Executing tasks

main:
 [exec] svn: E17: URL '
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/csv'
doesn't exist
 [exec] Result: 1
 [exec] Skipped '/Users/bene/commons-sites/csv/javadocs'
 [exec] svn: E155007: None of the targets are working copies
 [exec] Result: 1
[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 3.199 s
[INFO] Finished at: 2018-08-31T11:13:39+02:00
[INFO]

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-antrun-plugin:1.8:run (prepare-checkout) on
project commons-csv: An Ant BuildException has occured:
/Users/bene/commons-sites/csv does not exist.
[ERROR] around Ant part .. @
10:44 in
/Users/bene/workspace/apache/commons/commons-csv/target/antrun/build-main.xml
[ERROR] -> [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 Mi., 22. Aug. 2018 um 21:22 Uhr schrieb Benedikt Ritter <
brit...@apache.org>:

>
>
> Am Mi., 22. Aug. 2018 um 14:33 Uhr schrieb Gilles <
> gil...@harfang.homelinux.org>:
>
>> On Wed, 22 Aug 2018 08:11:03 -0400, Rob Tompkins wrote:
>> >> On Aug 22, 2018, at 1:47 AM, Benedikt Ritter 
>> >> wrote:
>> >>
>> >> Hi,
>> >>
>> >> I don't understand this discussion. Changes in Commons Parent have
>> >> broken
>> >> the commons-compress build. So we should either roll this changes
>> >> back or
>> >> those who need the changes in commons parent should fix the commons
>> >> compress build.
>> >
>> > I think the problem at hand here is that we, across our projects, are
>> > inconsistent with our usage of componentId, so naturally any changes
>> > to the way we consume it in the parent are breaking changes. For
>> > example:
>> >
>> > https://github.com/apache/commons-lang/blob/master/pom.xml#L573
>> > <https://github.com/apache/commons-lang/blob/master/pom.xml#L573>
>>
>> This one is wrong, according to a convention explicitly mentioned
>> in some POM files, e.g.:
>> ---CUT---
>>  
>>  rng
>> ---CUT---
>>
>
> I've raised LANG-1414 [1] to fix this.
>
> Benedikt
>
> [1] https://issues.apache.org/jira/browse/LANG-1414
>
>
>>
>> Gilles
>>
>> > versus
>> >
>> > https://github.com/apache/commons-collections/blob/master/pom.xml#L487
>> >
>> > <https://github.com/apache/commons-collections/blob/master/pom.xml#L487
>> >
>> >
>> > -Rob
>> >
>> >
>> >>
>> >> Regards,
>> >> Benedikt
>> >>
>> >> Am Do., 16. Aug. 2018 um 19:08 Uhr schrieb Gary Gregory <
>> >> garydgreg...@gmail.com>:
>> >>
>> >>> On Thu, Aug 16, 2018 at 10:27 AM Stefan Bodewig
>> >>> 
>> >>> wrote:
>> >>>
>> >>>> On 2018-08-16, Gary Gregory wrote:
>> >>>>
>> >>>>> I've use the release plugin a bunch without trouble. You might
>> >>>>> want to
>> >>>> see
>> >>>>> how other POMs are configured, for example [dbcp].
>> >>>>
>> >>>> The same way as Compress (no commons- prefix), I've got no idea
>> >>>> why
>> >>>> running site-deploy should work for it.
>> >>>>
>> >>>> You use the rel

Re: [ALL] SHA256/512 hashes

[Benedikt Ritter]

Am Do., 30. Aug. 2018 um 13:45 Uhr schrieb sebb :

> On 30 August 2018 at 11:19, Thomas Vandahl  wrote:
> > On 28.08.18 12:03, sebb wrote:
> >> On 28 August 2018 at 09:25, Mark Struberg 
> wrote:
>  This is unlikely to happen as long as it does not cover multi-module
> builds
> >>>
> >>> The maven-release-plugin covers multi-module releases since many years.
> >>>
> >>> In the projects I'm working on there is no 'release manager'.
> >>> _Everybody_ can do releases without having to know anything special.
> >>> This is where the maven-release-plugin really shines.
> >>> Just use mvn release:prepare + mvn release:perform and be done.
> >>
> >> If it works first time.
> >
> > I think the release plugin does quite a good job in resuming broken
> > build processes, rolling back etc.
>
> Only for the RM.
>
> Meanwhile, trunk has been changed.
>
> >>
> >> The problem is that the Maven release plugin design assumes that the
> >> first release attempt will succeed.
> >> As such, it updates trunk to the new snapshot version.
> >> (This causes issues with CI builds)
> >
> > You are free to choose whatever developmentVersion should be recorded.
>
> It should not be necessary to downdate the new version.
>
> >> It also assumes that the current workspace does not contain anything
> >> it should not.
> >
> > I actually consider this an advantage. It helps you to avoid
> > inconsistent source trees.
>
> Huh?
>
> If a local workspace contains spurious files, by definition it is
> inconsistent.
>
> > If you want to get around this, see
> > checkModificationExcludeList of the prepare goal.
>
> Again, it should be the default to use a clean checkout of the tag for
> building the binary/source artifacts.
>

Please note, that all what you are saying is just your opinion on how a
release should be created. The maven team clearly has another opinion on
that. Both are valid.

Our release process is cumbersome and fragile leading to all release
looking a little different from each other, depending on who is RM.
The pain that our release process causes has been brought up again and
again since I started here at commons back in 2011. I wonder whether it is
a good idea to use a tool like maven that is pretty opinionated on how to
do things and then bend it to do it another way. Maybe we should simply use
maven the way it is intended. Or if we can't live with the way maven does
things, maybe we should use a tool that gives us more liberty in
customizing the build, e.g. gradle.

Benedikt


>
> > Bye, Thomas
> >
> > -
> > 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: [All] What's in a "beta" release?

[Benedikt Ritter]

This discussion keeps popping up every few month. At the end we alway
conclude that we don't want to publish anything that's binary incompatible
under the same coordinates. So way are we discussing this again? Appending
"beta" to a release version will not stop people from using it. So why not
simply call it 1.0 and be done with it?

Benedikt

Am Fr., 31. Aug. 2018 um 01:30 Uhr schrieb sebb :

> On 30 August 2018 at 15:35, Gary Gregory  wrote:
> > But SNAPSHOT builds _are_ publicly available on repository.apache.org.
> Sure
> > they come and go and you cannot rely on their permanence.
>
> Just about all our code is available from URLs that don't require logins.
>
> However only formal releases should be announced to the general public.
>
> Other links should be confined to pages intended for Commons developers
>
> > Gary
> >
> > On Thu, Aug 30, 2018, 04:50 sebb  wrote:
> >
> >> SNAPSHOT builds must only be published to Commons developers.
> >> They cannot be published on public download pages.
> >>
> >> Also they may disappear or be replaced at any time.
> >>
> >> Beta builds are subject to a release VOTE, and so can be published in
> >> the usual way.
> >> Once published, they are permanently available.
> >>
> >> On 30 August 2018 at 09:38, Benedikt Ritter  wrote:
> >> > What's the difference to a nightly build being published to the Apache
> >> > Snapshot repo?
> >> >
> >> > Benedikt
> >> >
> >> > Am Mi., 29. Aug. 2018 um 21:51 Uhr schrieb Gary Gregory <
> >> > garydgreg...@gmail.com>:
> >> >
> >> >> We do not have hard rules for betas AFAIK. IMO, only a beta can
> depend
> >> on
> >> >> another beta, for example see HttpComponents. We should not release a
> >> >> non-beta that depends on a beta. I think breaking BC is to be
> expected
> >> in
> >> >> an alpha and less so in a beta. Changing package names and
> coordinates
> >> from
> >> >> one beta to the next seems a bit excessive but I would not object to
> it.
> >> >>
> >> >> Gary
> >> >>
> >> >> On Wed, Aug 29, 2018, 10:36 Gilles 
> >> wrote:
> >> >>
> >> >> > Hello.
> >> >> >
> >> >> > Do you have an idea of what it would take to automate "beta"
> >> >> > releases?
> >> >> > By this I mean: take a component (at some state) and create
> >> >> > a  branch (with all the necessary adaptations) to become an
> >> >> > official release.
> >> >> >
> >> >> > Are "beta" releases subject to the same BC requirements as
> >> >> > "ordinary" ones?  Concretely, suppose that several releases
> >> >> > will be necessary: Do they have to change top-level package
> >> >> > name?
> >> >> >
> >> >> > Can a (non-"beta") release (of some component) depend on a
> >> >> > "beta" release (of another component)?  Or has the former to
> >> >> > be a "beta" too?
> >> >> >
> >> >> > Rationale: I imagine that uploading to "Maven Central" may
> >> >> > help correcting the misrepresentation of resources available
> >> >> > from this project.
> >> >> >
> >> >> >
> >> >> > Regards,
> >> >> > 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
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [All] What's in a "beta" release?

[Benedikt Ritter]

What's the difference to a nightly build being published to the Apache
Snapshot repo?

Benedikt

Am Mi., 29. Aug. 2018 um 21:51 Uhr schrieb Gary Gregory <
garydgreg...@gmail.com>:

> We do not have hard rules for betas AFAIK. IMO, only a beta can depend on
> another beta, for example see HttpComponents. We should not release a
> non-beta that depends on a beta. I think breaking BC is to be expected in
> an alpha and less so in a beta. Changing package names and coordinates from
> one beta to the next seems a bit excessive but I would not object to it.
>
> Gary
>
> On Wed, Aug 29, 2018, 10:36 Gilles  wrote:
>
> > Hello.
> >
> > Do you have an idea of what it would take to automate "beta"
> > releases?
> > By this I mean: take a component (at some state) and create
> > a  branch (with all the necessary adaptations) to become an
> > official release.
> >
> > Are "beta" releases subject to the same BC requirements as
> > "ordinary" ones?  Concretely, suppose that several releases
> > will be necessary: Do they have to change top-level package
> > name?
> >
> > Can a (non-"beta") release (of some component) depend on a
> > "beta" release (of another component)?  Or has the former to
> > be a "beta" too?
> >
> > Rationale: I imagine that uploading to "Maven Central" may
> > help correcting the misrepresentation of resources available
> > from this project.
> >
> >
> > Regards,
> > Gilles
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: [LANG] Request for Comments for LANG-1417

[Benedikt Ritter]

Am Di., 28. Aug. 2018 um 18:52 Uhr schrieb Pascal Schumacher <
pascalschumac...@gmx.net>:

> Hi Benedikt,
>
> not sure if anything is gained this change.
>
> It is already possible use lambda expressions or method references
> instead of ThreadPredicate/ThreadGroupPredicate.
>
> Users will have to change their code to avoid deprecation warnings.
>
> I would prefer to just annotate ThreadPredicate and ThreadGroupPredicate
> with @FunctionalInterface and be done.
>

Good point and probably the best solution! Will adapt my PR.

Thanks,
Benedikt


>
> Regards,
> Pascal
>
> Am 28.08.2018 um 11:32 schrieb Benedikt Ritter:
> > Hi,
> >
> > I've implemented a proposal to get rid of ThreadPredicate and
> > ThreadGroupPredicate in ThreadUtils [1]. I have two questions about this
> > issue:
> >
> > 1) It does not seem possible to let our custom pre Java 8 predicates
> extend
> > java.util.function.Predicate. I've explained why I think this is not
> > possible in LANG-1417 [2]. I'd like to here comments about that. Am I
> > missing something?
> > 2) Should be put the new java.util.function.Predicate based API inside
> > ThreadUtils or should we deprecate ThreadUtils all together und create a
> > new version of the class (ThreadUtils2 / ThreadUtilsJava8 /
> > org.apache.commons.thread.ThreadUtils) that only operates on Predicates?
> >
> > Regards,
> > Benedikt
> >
> > [1] https://github.com/apache/commons-lang/349
> > [2] https://issues.apache.org/jira/browse/LANG-1417
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[LANG] Request for Comments for LANG-1417

[Benedikt Ritter]

Hi,

I've implemented a proposal to get rid of ThreadPredicate and
ThreadGroupPredicate in ThreadUtils [1]. I have two questions about this
issue:

1) It does not seem possible to let our custom pre Java 8 predicates extend
java.util.function.Predicate. I've explained why I think this is not
possible in LANG-1417 [2]. I'd like to here comments about that. Am I
missing something?
2) Should be put the new java.util.function.Predicate based API inside
ThreadUtils or should we deprecate ThreadUtils all together und create a
new version of the class (ThreadUtils2 / ThreadUtilsJava8 /
org.apache.commons.thread.ThreadUtils) that only operates on Predicates?

Regards,
Benedikt

[1] https://github.com/apache/commons-lang/349
[2] https://issues.apache.org/jira/browse/LANG-1417

Re: [VOTE] Release Apache Commons JCS 2.2.1 based on RC4

[Benedikt Ritter]

Hi,

- sigs and hashes are good
- builds fine with maven 3.5.4 from src distribution
- website looks good
- release notes look good
- there are some differences between the src distribution and release tag:

~/w/a/r/r/t/jcs git:(upstream ⚡ master) > diff -r commons-jcs-2.2.1-RC4/
commons-jcs-2.2.1-src
Only in commons-jcs-2.2.1-RC4/: .gitignore
Only in commons-jcs-2.2.1-RC4/: .svn
Only in commons-jcs-2.2.1-RC4/: .travis.yml
Only in commons-jcs-2.2.1-src: LICENSE
Only in commons-jcs-2.2.1-RC4/: LICENSE.txt
Only in commons-jcs-2.2.1-src: NOTICE
Only in commons-jcs-2.2.1-RC4/: NOTICE.txt
Only in commons-jcs-2.2.1-RC4/: auxiliary-builds
Only in commons-jcs-2.2.1-RC4/: checkstyle.xml
Only in commons-jcs-2.2.1-RC4/: commons-jcs-sandbox
Only in commons-jcs-2.2.1-RC4/: init-git-svn.sh
Only in commons-jcs-2.2.1-RC4/: jcache-fast.sh
Only in commons-jcs-2.2.1-RC4/: maven-eclipse-codestyle.xml

This should be fixed for the next release.

+1

Regards,
Benedikt

Am Do., 23. Aug. 2018 um 17:32 Uhr schrieb Thomas Vandahl :

> I would like to make another attempt to release Apache Commons JCS 2.2.1
> (a bugfix release)
>
> Apache Commons JCS 2.2.1 RC4 is available for review here:
>
> https://dist.apache.org/repos/dist/dev/commons/jcs/ (svn revision 28918)
>
> The SVN tag commons-jcs-2.2.1-RC4 commit for this RC4 is here:
>
>
> https://svn.apache.org/repos/asf/commons/proper/jcs/tags/commons-jcs-2.2.1-RC4
> (r1838700
> 
> )
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1373
>
> I have built and tested this using:
>
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
> 2018-06-17T20:33:14+02:00)
> Maven home: /Users/thomas/Dev/apache-maven-3.5.4
> Java version: 1.8.0_144, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.11.6", arch: "x86_64", family: "mac"
>
> Details of changes since 2.2 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/jcs/RELEASE-NOTES.txt
>
>
> https://dist.apache.org/repos/dist/dev/commons/jcs/site-2.2.1-RC4/changes-report.html
>
> Site:
> https://dist.apache.org/repos/dist/dev/commons/jcs/site-2.2.1-RC4/
>
> CLIRR Report (compared to 2.2):
>
>
> https://dist.apache.org/repos/dist/dev/commons/jcs/site-2.2.1-RC4/commons-jcs-core/clirr-report.html
>
> RAT Report:
>
>
> https://dist.apache.org/repos/dist/dev/commons/jcs/site-2.2.1-RC4/commons-jcs-core/rat-report.html
>
> KEYS:
> https://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
> Bye, Thomas.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [COLLECTIONS] Master branch build failing

[Benedikt Ritter]

Hi,

Am Fr., 24. Aug. 2018 um 09:06 Uhr schrieb Benedikt Ritter <
brit...@apache.org>:

>
>
> Am Do., 23. Aug. 2018 um 20:12 Uhr schrieb sebb :
>
>> Huh?
>>
>> Looks like the failure is due to Clirr is reporting some breaks; not
>> sure how that can depend on the Java version.
>>
>
> Maybe related to Java 8 default methods? I'm just guessing here... Need to
> dig into this on the weekend.
>

It looks like this is related to Clirr handling default methods the wrong
way. So we probably need to fix clirr in order to use it. I found a mirror
of the code on GitHub in Emmanuel Bourg's account [1]. We could probably
try to fix clirr, but I'd like to explore whether it would be okay to drop
clirr entirely and only use jacimp instead (which seems to work with Java
8).

Regards,
Benedikt

[1] https://github.com/ebourg/clirr/issues/1


>
> Benedikt
>
>
>>
>>
>> On 23 August 2018 at 18:37, Gary Gregory  wrote:
>> > This has to do with the Java version used to run the build... I've seen
>> it
>> > locally but just switched Java version to avoid it.
>> >
>> > Gary
>> >
>> > On Thu, Aug 23, 2018, 11:18 Benedikt Ritter  wrote:
>> >
>> >> Hi,
>> >>
>> >> it looks like the master branch build for commons-collections is
>> failing
>> >> for a while now [1]. Does anybody have the time to look into this?
>> >>
>> >> Benedikt
>> >>
>> >> [1] https://travis-ci.org/apache/commons-collections/jobs/404183011
>> >>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>

Re: New release distribution checksum policy

[Benedikt Ritter]

Hi Thomas,

Am Fr., 24. Aug. 2018 um 13:13 Uhr schrieb Thomas Vandahl :

> Hi Benedikt,
>
> On 23.08.18 18:25, Benedikt Ritter wrote:
> > Am Do., 23. Aug. 2018 um 09:16 Uhr schrieb Thomas Vandahl  >:
> >
> >> Shall we use this for commons-parent?
> >>
> >
> > Sounds reasonable to me.
>
> If I'm not mistaken, the requirement for SHA-512 checksums only exists
> for the source distribution, not the binaries. At least this is what I
> derive from Hervés implementation in Apache Parent 21. However, the
> plugin configuration only kicks in, if the source release artifact name
> ends with "-source-release.[zip|tar*]" From what I see in the latest
> votes, Apache Commons uses another naming scheme (I do, too). Shall we
> adapt?
>

What do you mean? Adapt our artifact naming scheme or adapt what Apache
Parent 21 does? Since SHA-512 checksums are required now, we need to find a
way to implement this :-) I'm not sure what's the best way for that right
now. What do others think?

Benedikt


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

Re: [COLLECTIONS] Master branch build failing

[Benedikt Ritter]

Am Do., 23. Aug. 2018 um 20:12 Uhr schrieb sebb :

> Huh?
>
> Looks like the failure is due to Clirr is reporting some breaks; not
> sure how that can depend on the Java version.
>

Maybe related to Java 8 default methods? I'm just guessing here... Need to
dig into this on the weekend.

Benedikt


>
>
> On 23 August 2018 at 18:37, Gary Gregory  wrote:
> > This has to do with the Java version used to run the build... I've seen
> it
> > locally but just switched Java version to avoid it.
> >
> > Gary
> >
> > On Thu, Aug 23, 2018, 11:18 Benedikt Ritter  wrote:
> >
> >> Hi,
> >>
> >> it looks like the master branch build for commons-collections is failing
> >> for a while now [1]. Does anybody have the time to look into this?
> >>
> >> Benedikt
> >>
> >> [1] https://travis-ci.org/apache/commons-collections/jobs/404183011
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [CSV] Inconsistent record separator behavior

[Benedikt Ritter]

Am Do., 23. Aug. 2018 um 20:17 Uhr schrieb sebb :

> On 23 August 2018 at 17:31, Benedikt Ritter  wrote:
> > Hi,
> >
> > Am Do., 23. Aug. 2018 um 12:11 Uhr schrieb sebb :
> >
> >> On 23 August 2018 at 07:10, Benedikt Ritter  wrote:
> >> > Hey sebb,
> >> >
> >> > Am Do., 23. Aug. 2018 um 01:23 Uhr schrieb sebb :
> >> >
> >> >> On 23 August 2018 at 00:01, Bruno P. Kinoshita
> >> >>  wrote:
> >> >> >
> >> >> >>Maybe I'm just not getting it, but it feels pretty messed up :-)
> >> >> >
> >> >> >
> >> >> > Mutual feeling, and +1 for consistency. From what I understood,
> users
> >> >> should be able to parse these crazy CVS's, but if they tried to
> >> re-create
> >> >> them, with comments, then they wouldn't be able to avoid the
> >> >> println/newline (so it wouldn't be parseable later with the same
> >> reader).
> >> >> >
> >> >> >
> >> >> > We probably need a ticket for it to aggregate the discussion and
> >> maybe a
> >> >> possible solution.
> >> >>
> >> >> I'm wondering whether we need to be as flexible when *creating* the
> CSV
> >> >> files.
> >> >>
> >> >> "Be liberal in what you accept, and conservative in what you send"
> (Jon
> >> >> Postel)
> >> >>
> >> >> In this case send == create, as it might be sent to other less
> liberal
> >> >> readers.
> >> >>
> >> >> I don't have a problem with the output being less flexible, so long
> as
> >> >> it is sufficiently flexible (which I think it likely is already).
> >> >>
> >> >> I don't think consistency is necessary - or even desirable - here.
> >> >>
> >> >
> >> > okay, but wouldn't you expect that you can use a CSVFormat instance to
> >> read
> >> > a file that you created with it? This is currently not the case.
> >>
> >> Sorry, I misread the problem.
> >>
> >> Yes, it should be able to read what it writes.
> >>
> >> So the issue remains: should the reader be able to parse the unusual
> >> format, or should the writer not be able to create it?
> >>
> >> I don't have a particular view on that, except that allowing LF and
> >> CRLF only seems too restricting.
> >> We should allow at least CR alone. I don't know whether there are any
> >> other reasonable separators.
> >>
> >
> > As Bruno pointed out, there seem to be formats that have record separator
> > that are not new lines. So maybe CSVPrinter.printComment(String) should
> not
> > scan for CR and LF but for the record separator.
> >
>
> Makes sense.
>
> >>
> >> Perhaps we could just document the method to warn that using anything
> >> other than CR, LF or CRLF will produce an output file that is not
> >> parseable?
> >>
> >
> > That sounds like a good approach. But how would you implement that? You
> > probably don't want to introduce a dependency on a logging framework just
> > for that, do you?
>
> I meant: add a warning to the documentation.
>

+1 for that! CSVPrinter has almost no class level documentation, so I
wanted to improve that anyway.

Benedikt


>
> > Regards,
> > Benedikt
> >
> >
> >>
> >> > Regards,
> >> > Benedikt
> >> >
> >> >
> >> >>
> >> >> > Cheers
> >> >> >
> >> >> > 
> >> >> > From: Benedikt Ritter 
> >> >> > To: Commons Developers List ;
> >> >> brunodepau...@yahoo.com.br
> >> >> > Sent: Thursday, 23 August 2018 7:10 AM
> >> >> > Subject: Re: [CSV] Inconsistent record separator behavior
> >> >> >
> >> >> >
> >> >> >
> >> >> > Hi Bruno,
> >> >> >
> >> >> > Am Mi., 22. Aug. 2018 um 15:10 Uhr schrieb Bruno P. Kinoshita
> >> >> > :
> >> >> >
> >> >> >> Hi,
> >> >> >>
> >> >> >>
> >> >> >> Will try to look at the code and give a better answer during the
> >> >>

[COLLECTIONS] Master branch build failing

[Benedikt Ritter]

Hi,

it looks like the master branch build for commons-collections is failing
for a while now [1]. Does anybody have the time to look into this?

Benedikt

[1] https://travis-ci.org/apache/commons-collections/jobs/404183011

Re: [CSV] Inconsistent record separator behavior

[Benedikt Ritter]

Hi,

Am Do., 23. Aug. 2018 um 12:11 Uhr schrieb sebb :

> On 23 August 2018 at 07:10, Benedikt Ritter  wrote:
> > Hey sebb,
> >
> > Am Do., 23. Aug. 2018 um 01:23 Uhr schrieb sebb :
> >
> >> On 23 August 2018 at 00:01, Bruno P. Kinoshita
> >>  wrote:
> >> >
> >> >>Maybe I'm just not getting it, but it feels pretty messed up :-)
> >> >
> >> >
> >> > Mutual feeling, and +1 for consistency. From what I understood, users
> >> should be able to parse these crazy CVS's, but if they tried to
> re-create
> >> them, with comments, then they wouldn't be able to avoid the
> >> println/newline (so it wouldn't be parseable later with the same
> reader).
> >> >
> >> >
> >> > We probably need a ticket for it to aggregate the discussion and
> maybe a
> >> possible solution.
> >>
> >> I'm wondering whether we need to be as flexible when *creating* the CSV
> >> files.
> >>
> >> "Be liberal in what you accept, and conservative in what you send" (Jon
> >> Postel)
> >>
> >> In this case send == create, as it might be sent to other less liberal
> >> readers.
> >>
> >> I don't have a problem with the output being less flexible, so long as
> >> it is sufficiently flexible (which I think it likely is already).
> >>
> >> I don't think consistency is necessary - or even desirable - here.
> >>
> >
> > okay, but wouldn't you expect that you can use a CSVFormat instance to
> read
> > a file that you created with it? This is currently not the case.
>
> Sorry, I misread the problem.
>
> Yes, it should be able to read what it writes.
>
> So the issue remains: should the reader be able to parse the unusual
> format, or should the writer not be able to create it?
>
> I don't have a particular view on that, except that allowing LF and
> CRLF only seems too restricting.
> We should allow at least CR alone. I don't know whether there are any
> other reasonable separators.
>

As Bruno pointed out, there seem to be formats that have record separator
that are not new lines. So maybe CSVPrinter.printComment(String) should not
scan for CR and LF but for the record separator.


>
> Perhaps we could just document the method to warn that using anything
> other than CR, LF or CRLF will produce an output file that is not
> parseable?
>

That sounds like a good approach. But how would you implement that? You
probably don't want to introduce a dependency on a logging framework just
for that, do you?

Regards,
Benedikt


>
> > Regards,
> > Benedikt
> >
> >
> >>
> >> > Cheers
> >> >
> >> > 
> >> > From: Benedikt Ritter 
> >> > To: Commons Developers List ;
> >> brunodepau...@yahoo.com.br
> >> > Sent: Thursday, 23 August 2018 7:10 AM
> >> > Subject: Re: [CSV] Inconsistent record separator behavior
> >> >
> >> >
> >> >
> >> > Hi Bruno,
> >> >
> >> > Am Mi., 22. Aug. 2018 um 15:10 Uhr schrieb Bruno P. Kinoshita
> >> > :
> >> >
> >> >> Hi,
> >> >>
> >> >>
> >> >> Will try to look at the code and give a better answer during the
> >> weekend.
> >> >> But risking a silly question, would it mean that users are not able
> to
> >> >> parse a CSV unless each CSV row is separated by LF or CRLF?
> >> >
> >> >
> >> > Yes.
> >> >
> >> >
> >> >> I remember getting a CSV in a government website some time ago that
> was
> >> >> formatted in a very strange way, and if I remember well it was a
> small
> >> >> file, but without LF or CRLF. I think it was using | to separate the
> >> rows,
> >> >> and , for columns.
> >> >>
> >> >
> >> > I didn't know that there are formats that don't use a new line as line
> >> > separator.
> >> >
> >> >
> >> >>
> >> >>
> >> >> Quick search returned at least another person with similar issue
> >> >>
> >>
> https://stackoverflow.com/questions/29903202/how-to-read-csv-on-python-with-newline-separator
> >> >>
> >> >>
> >> >> Not sure if I understood the problem well, but in c

Re: Use of Java 8 features in the commons

[Benedikt Ritter]

Hi Eitan,

Am Do., 23. Aug. 2018 um 14:39 Uhr schrieb Eitan Adler :

> On Wed, 22 Aug 2018 at 23:28, Benedikt Ritter  wrote:
> >
> > Hi,
> >
> > Am Mo., 20. Aug. 2018 um 19:09 Uhr schrieb Benedikt Ritter <
> > brit...@apache.org>:
> >
> > > Hi,
> > >
> > > any objections against raising the minimum required Java version for
> lang
> > > 3.9 to Java 1.8?
> > >
> >
> > Since there where no objections, I've created a PR for this change:
> > https://github.com/apache/commons-lang/pull/346
>
> Apologies if this was discussed in the past (and if so, please point
> me at the discussion).
>
> As the various commons libraries switch to Java 8 minimum what do
> people thinking of mechanical migrations to use new languages
> features. For example making of use of method references, stream API,
> etc. Is this something we should only do when we're touching the
> relevant code, or are wider migrations reasonable?
>

Yes we should use the new features available to improve implementation of
our code base. I'm not a friend of automatic migration. I think it's better
do this by hand. Otherwise you might have undesired results.

Benedikt


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

Re: New release distribution checksum policy

[Benedikt Ritter]

Am Do., 23. Aug. 2018 um 09:16 Uhr schrieb Thomas Vandahl :

> Shall we use this for commons-parent?
>

Sounds reasonable to me.

Benedikt


>
> Bye, Thomas.
>
>  Forwarded Message 
> Subject: Re: New release distribution checksum policy
> Date: Thu, 23 Aug 2018 08:02:45 +0200
> From: Hervé BOUTEMY 
> Reply-To: memb...@apache.org
> To: memb...@apache.org
>
> FYI, Apache parent POM 21 has been released
> https://s.apache.org/asf-pom-21
>
> it generates .sha512 checksum in target/checkout/target/ during release
> with Maven Release Plugin, ready to be copied to Apache dist area: I
> used it during the release (eating my own dog's food), the .sha512 file
> in this release comes from this tooling
>
> notice: nothing goes through any Maven repository (be it local, staging
> or central), then it does not hurt Apache Nexus nor Maven central controls
>
> Regards,
>
> Hervé
>
> Le vendredi 17 août 2018, 12:32:57 CEST Mark Struberg a écrit :
> > Thanks Hervé, really appreciated!
> >
> > I suggest to only enforce the new rules once all our toolchain is ready.
> > And again: what to do with older content? Shouldn't we also at least go
> > through all out dist + archive and add the sha512?
> >
> > LieGrue,
> > strub
> >
> > > Am 17.08.2018 um 11:34 schrieb herve.bout...@free.fr:
> > >
> > > for people using Maven release plugin as configured by Apache parent
> POM
> > > [1], an update for version 21 is in progress tracked as MPOM-205 [2]
> > > which will provide the .sha512 checksum file with the source release
> > > archive and its signature in target/checkout/target/
> > >
> > > I'll start the release vote tomorrow
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > [1] https://maven.apache.org/pom/asf/
> > >
> > > [2] https://issues.apache.org/jira/browse/MPOM-205
> > >
> > > - Mail original -
> > > De: "Henk P. Penning" 
> > > À: memb...@apache.org
> > > Envoyé: Jeudi 16 Août 2018 12:23:36
> > > Objet: Re: New release distribution checksum policy
> > >
> > > On Thu, 16 Aug 2018, Mark Struberg wrote:
> > >> Date: Thu, 16 Aug 2018 09:14:57 +0200
> > >> From: Mark Struberg 
> > >> To: memb...@apache.org
> > >> Subject: Re: New release distribution checksum policy
> > >>
> > >> What is the date when this should be effective?
> > >>
> > >   The policy is already 'effective' ; the policy page has been changed.
> > >   In fact, the page was mauled weeks ago ; then slowly converged
> > >
> > >   to its present state :
> > > http://www.apache.org/dev/release-distribution#sigs-and-sums
> > >>
> > >> Projects will likely need to update their build process, updating
> > >> maven plugins, etc
> > >>
> > >   The Maven people assure me that Maven does not support 'deployment'
> > >   into /dist/. Period.
> > >
> > >   For Maven-based projects, publishing into /dist/ in 'manual labor' ;
> > >   this involves :
> > >   -- removing .md5's
> > >   -- replacing .sha1's by .sha256's or .sha512's
> > >   I think that is unfortunate, but that's the way it is ;
> > >   it seems fixable, but I know almost nothing about Maven.
> > >
> > >   For other (non-Maven-based) projects, generating a SHA-256,
> > >   instead of a SHA-1, should be easy ...
> > >>
> > >> So I suggest to at least give a 3 month buffer period.
> > >>
> > >   The only new "MUST" is :
> > > New releases MUST have a SHA-256 and/or SHA-512 checksum file
> > >
> > >   ... and who/what is checking that ?
> > >
> > >   https://checker.apache.org/ 'solves' it by classifying
> > >   a resulting policy violation as a 'warning'.
> > >   In a few months that could be changed to 'error'.
> > >>
> > >> While it is possible to create collisions in sha1 it is rather
> > >> unlikely *right now* to create a collision PLUS get a valid binary out
> > >> of it.  We are talking about a multi-month effort in a cloud-scale GPU
> > >> environment afaik.
> > >>
> > >   I agree there is no immediate danger ; the change is cosmetic.
> > >   Like other org's, we must be seen to be moving away from SHA-1.
> > >   Hopefully there are fewer "why is SHA-1 deprecated?" than
> > >   "shouldn't we deprecate SHA-1?" threads :-).
> > >>
> > >> Another question: is it possible to create sha256 in our Nexus at
> > >> least for repository.a.o?  We could then provide this hash for our old
> > >> releases as well and later adapt our download pages.
> > >>
> > >> txs and LieGrue,
> > >> strub
> > >>
> > >   Groeten,
> > >
> > >   Henk Penning
> > >
> > >    _
> > > Henk P. Penning, ICT-beta R Uithof MG-403_/ \_
> > > Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \
> > > Leuvenlaan 4, 3584CE Utrecht, NL  F +31 30 253 4553 \_/ \_/
> > > http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/
> > >
> > >>> Am 15.08.2018 um 10:19 schrieb Henk P. Penning :
> > >>>
> > >>> On Tue, 14 Aug 2018, Shane Curcuru wrote:
> >  Date: Tue, 14 Aug 2018 15:18:34 +0200
> >  From

Re: [LANG] Minimum required Java version for 3.9

[Benedikt Ritter]

Hi,

Am Mo., 20. Aug. 2018 um 19:09 Uhr schrieb Benedikt Ritter <
brit...@apache.org>:

> Hi,
>
> any objections against raising the minimum required Java version for lang
> 3.9 to Java 1.8?
>

Since there where no objections, I've created a PR for this change:
https://github.com/apache/commons-lang/pull/346


>
> Regards,
> Benedikt
>

Re: [CSV] Inconsistent record separator behavior

[Benedikt Ritter]

Hey sebb,

Am Do., 23. Aug. 2018 um 01:23 Uhr schrieb sebb :

> On 23 August 2018 at 00:01, Bruno P. Kinoshita
>  wrote:
> >
> >>Maybe I'm just not getting it, but it feels pretty messed up :-)
> >
> >
> > Mutual feeling, and +1 for consistency. From what I understood, users
> should be able to parse these crazy CVS's, but if they tried to re-create
> them, with comments, then they wouldn't be able to avoid the
> println/newline (so it wouldn't be parseable later with the same reader).
> >
> >
> > We probably need a ticket for it to aggregate the discussion and maybe a
> possible solution.
>
> I'm wondering whether we need to be as flexible when *creating* the CSV
> files.
>
> "Be liberal in what you accept, and conservative in what you send" (Jon
> Postel)
>
> In this case send == create, as it might be sent to other less liberal
> readers.
>
> I don't have a problem with the output being less flexible, so long as
> it is sufficiently flexible (which I think it likely is already).
>
> I don't think consistency is necessary - or even desirable - here.
>

okay, but wouldn't you expect that you can use a CSVFormat instance to read
a file that you created with it? This is currently not the case.

Regards,
Benedikt


>
> > Cheers
> >
> > 
> > From: Benedikt Ritter 
> > To: Commons Developers List ;
> brunodepau...@yahoo.com.br
> > Sent: Thursday, 23 August 2018 7:10 AM
> > Subject: Re: [CSV] Inconsistent record separator behavior
> >
> >
> >
> > Hi Bruno,
> >
> > Am Mi., 22. Aug. 2018 um 15:10 Uhr schrieb Bruno P. Kinoshita
> > :
> >
> >> Hi,
> >>
> >>
> >> Will try to look at the code and give a better answer during the
> weekend.
> >> But risking a silly question, would it mean that users are not able to
> >> parse a CSV unless each CSV row is separated by LF or CRLF?
> >
> >
> > Yes.
> >
> >
> >> I remember getting a CSV in a government website some time ago that was
> >> formatted in a very strange way, and if I remember well it was a small
> >> file, but without LF or CRLF. I think it was using | to separate the
> rows,
> >> and , for columns.
> >>
> >
> > I didn't know that there are formats that don't use a new line as line
> > separator.
> >
> >
> >>
> >>
> >> Quick search returned at least another person with similar issue
> >>
> https://stackoverflow.com/questions/29903202/how-to-read-csv-on-python-with-newline-separator
> >>
> >>
> >> Not sure if I understood the problem well, but in case it makes sense...
> >> my suggestion would be to perhaps confirm if we could change
> >> CSVPrinter.printComment to accept other characters for line ending?
> >>
> >
> > The inconsistency I'm seeing is, that we an the one hand accept any
> > character sequence as a record separator. Comments in a way a like
> special
> > records to me. But our implementation seems to put them on a new "line"
> > using the println() method. The println() method in turn uses the record
> > seperator to start a new record. So it's not necessarily a new line.
> > Nevertheless while processing a comment, we look out for CR and LF and
> then
> > we call println() again. Maybe I'm just not getting it, but it feels
> pretty
> > messed up :-)
> >
> > Regards,
> > Benedikt
> >
> >
> >
> >>
> >>
> >> Thanks!
> >>
> >> Bruno
> >>
> >>
> >> 
> >> From: Benedikt Ritter 
> >> To: Commons Developers List 
> >> Sent: Tuesday, 21 August 2018 7:13 PM
> >> Subject: [CSV] Inconsistent record separator behavior
> >>
> >>
> >>
> >> Hi,
> >>
> >>
> >> we have this strange handling of record separator / line endings in CSV:
> >>
> >>
> >> Users can use what ever character sequence they like as a record
> separator.
> >>
> >> I could for example use the ! character to mark the end of a record.
> >>
> >> Then we have CSVPrinter.printComment(String). This inserts comments
> into a
> >>
> >> CSV output. It detects CRLF and call println() on the CSVFormat, which
> in
> >>
> >> turn uses the record separator to indicate a new record...
> >>
> >>
> >> So n

Re: [lang] (fix) Add missing @Test annotation

[Benedikt Ritter]

Nice one!

Am Mi., 22. Aug. 2018 um 13:13 Uhr schrieb :

> Repository: commons-lang
> Updated Branches:
>   refs/heads/master d1e72ebed -> ce178d8e8
>
>
> (fix) Add missing @Test annotation
>
>
> Project: http://git-wip-us.apache.org/repos/asf/commons-lang/repo
> Commit:
> http://git-wip-us.apache.org/repos/asf/commons-lang/commit/ce178d8e
> Tree: http://git-wip-us.apache.org/repos/asf/commons-lang/tree/ce178d8e
> Diff: http://git-wip-us.apache.org/repos/asf/commons-lang/diff/ce178d8e
>
> Branch: refs/heads/master
> Commit: ce178d8e87ff6f9a12aea4b217c1e09254936236
> Parents: d1e72eb
> Author: Eitan Adler 
> Authored: Wed Aug 22 04:06:44 2018 -0700
> Committer: Eitan Adler 
> Committed: Wed Aug 22 04:07:44 2018 -0700
>
> --
>  src/test/java/org/apache/commons/lang3/EnumUtilsTest.java | 1 +
>  1 file changed, 1 insertion(+)
> --
>
>
>
> http://git-wip-us.apache.org/repos/asf/commons-lang/blob/ce178d8e/src/test/java/org/apache/commons/lang3/EnumUtilsTest.java
> --
> diff --git a/src/test/java/org/apache/commons/lang3/EnumUtilsTest.java
> b/src/test/java/org/apache/commons/lang3/EnumUtilsTest.java
> index 7c732b2..2b9dc08 100644
> --- a/src/test/java/org/apache/commons/lang3/EnumUtilsTest.java
> +++ b/src/test/java/org/apache/commons/lang3/EnumUtilsTest.java
> @@ -407,6 +407,7 @@ public class EnumUtilsTest {
>  EnumUtils.processBitVector(TooMany.class, 0L);
>  }
>
> +@Test
>  public void test_processBitVectors_longClass() {
>  assertEquals(EnumSet.noneOf(TooMany.class),
> EnumUtils.processBitVectors(TooMany.class, 0L));
>  assertEquals(EnumSet.of(TooMany.A),
> EnumUtils.processBitVectors(TooMany.class, 1L));
>
>

Re: [parent] change in commons.scmPubUrl in Parent 47

[Benedikt Ritter]

Am Mi., 22. Aug. 2018 um 14:33 Uhr schrieb Gilles <
gil...@harfang.homelinux.org>:

> On Wed, 22 Aug 2018 08:11:03 -0400, Rob Tompkins wrote:
> >> On Aug 22, 2018, at 1:47 AM, Benedikt Ritter 
> >> wrote:
> >>
> >> Hi,
> >>
> >> I don't understand this discussion. Changes in Commons Parent have
> >> broken
> >> the commons-compress build. So we should either roll this changes
> >> back or
> >> those who need the changes in commons parent should fix the commons
> >> compress build.
> >
> > I think the problem at hand here is that we, across our projects, are
> > inconsistent with our usage of componentId, so naturally any changes
> > to the way we consume it in the parent are breaking changes. For
> > example:
> >
> > https://github.com/apache/commons-lang/blob/master/pom.xml#L573
> > <https://github.com/apache/commons-lang/blob/master/pom.xml#L573>
>
> This one is wrong, according to a convention explicitly mentioned
> in some POM files, e.g.:
> ---CUT---
>  
>  rng
> ---CUT---
>

I've raised LANG-1414 [1] to fix this.

Benedikt

[1] https://issues.apache.org/jira/browse/LANG-1414


>
> Gilles
>
> > versus
> >
> > https://github.com/apache/commons-collections/blob/master/pom.xml#L487
> >
> > <https://github.com/apache/commons-collections/blob/master/pom.xml#L487>
> >
> > -Rob
> >
> >
> >>
> >> Regards,
> >> Benedikt
> >>
> >> Am Do., 16. Aug. 2018 um 19:08 Uhr schrieb Gary Gregory <
> >> garydgreg...@gmail.com>:
> >>
> >>> On Thu, Aug 16, 2018 at 10:27 AM Stefan Bodewig
> >>> 
> >>> wrote:
> >>>
> >>>> On 2018-08-16, Gary Gregory wrote:
> >>>>
> >>>>> I've use the release plugin a bunch without trouble. You might
> >>>>> want to
> >>>> see
> >>>>> how other POMs are configured, for example [dbcp].
> >>>>
> >>>> The same way as Compress (no commons- prefix), I've got no idea
> >>>> why
> >>>> running site-deploy should work for it.
> >>>>
> >>>> You use the release plugin if you only want to publish the site
> >>>> and not
> >>>> cut a release?
> >>>>
> >>>
> >>> I use the plugin build the dist folder (which includes a site) and
> >>> generate
> >>> the vote email text. For the real site, after the vote, I use the
> >>> stock
> >>> site-deploy goal.
> >>>
> >>>
> >>>>
> >>>>> You have to keep in mind that components like Collections, Lang,
> >>>>> Pool,
> >>>> and
> >>>>> DBCP, the folder name is different from the artifact id because
> >>>>> the
> >>>>> artifact id contains a major version number, for example
> >>>>> commons-lang
> >>> is
> >>>>> the folder but commons-lang3 is the AID.
> >>>>
> >>>> The parent POM says about componentId:
> >>>>
> >>>>
> >>>${project.artifactId}
> >>>
> >>>${project.artifactId}
> >>>
> >>> For the seconds comment it should read
> >>> >>>> 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: [parent] change in commons.scmPubUrl in Parent 47

[Benedikt Ritter]

Am Mi., 22. Aug. 2018 um 16:55 Uhr schrieb Gilles <
gil...@harfang.homelinux.org>:

> On Wed, 22 Aug 2018 16:24:57 +0200, Stefan Bodewig wrote:
> > On 2018-08-22, Rob Tompkins wrote:
> >
> >>> On Aug 22, 2018, at 9:03 AM, Stefan Bodewig 
> >>> wrote:
> >
> >>> On 2018-08-22, Rob Tompkins wrote:
> >
> >>>>> On Aug 22, 2018, at 1:47 AM, Benedikt Ritter 
> >>>>> wrote:
> >
> >>>>> Hi,
> >
> >>>>> I don't understand this discussion. Changes in Commons Parent
> >>>>> have broken
> >>>>> the commons-compress build. So we should either roll this changes
> >>>>> back or
> >>>>> those who need the changes in commons parent should fix the
> >>>>> commons
> >>>>> compress build.
> >
> >>>> I think the problem at hand here is that we, across our projects,
> >>>> are
> >>>> inconsistent with our usage of componentId, so naturally any
> >>>> changes
> >>>> to the way we consume it in the parent are breaking changes. For
> >>>> example:
> >
> >>>> https://github.com/apache/commons-lang/blob/master/pom.xml#L573
> >>>> <https://github.com/apache/commons-lang/blob/master/pom.xml#L573>
> >>>> versus
> >>>>
> >>>>
> https://github.com/apache/commons-collections/blob/master/pom.xml#L487
> >>>> <
> https://github.com/apache/commons-collections/blob/master/pom.xml#L487>
> >
> >>> Anyway
> >
> >>> https://github.com/apache/commons-parent/blob/trunk/pom.xml#L1942
> >
> >>> is wrong for both of them as all subdirectories of
> >>>
> >>>
> https://svn.apache.org/repos/infra/websites/production/commons/content/proper/
> >>> start with "commons-" and no ${commons.componentid} does so. That's
> >>> why
> >>> I don't understand how site-deploy can work for commons-lang or
> >>> commons-collections. I've simply overwritten the commons.scmPubUrl
> >>> in
> >>> Compress' POM to make it work again.
> >
> >> I think that’s the standard practice at this point.
> >
> >>
> >> https://github.com/apache/commons-collections/blob/master/pom.xml#L519
> >> <https://github.com/apache/commons-collections/blob/master/pom.xml#L519
> >
> >
> >> https://github.com/apache/commons-lang/blob/master/pom.xml#L587
> >
> > In that case I may come back to my original question of why
> > commons.scmPubUrl - which worked for many in parent 46 - has been
> > changed to a value in 47 that (almost?) all components need to
> > overwrite
> > :-)
> >
> > This has been water under the bridge for me and I wouldn't have
> > brought
> > it up again, but if I now see others need to adjust as well, I may
> > better ask once again.
>
> Sure; it needs clarification.
> I'm probably somewhat of an heretic since I modify the web site by
> manually copying the contents of "target/staging" to "site-content"
> and doing "svn commit". :-}
> Hence I wouldn't know whether "site-deploy" works for e.g. [RNG].
>

Okay, so this sounds to me, that we should revert the change of
commons.scmPubUrl.
Stefan explantation of way site-deploy can't work for any component anymore
makes sense to me.

Benedikt


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

Re: Build failed in Jenkins: commons-csv #88

[Benedikt Ritter]

Am Mi., 22. Aug. 2018 um 19:15 Uhr schrieb sebb :

> I discovered yesterday that not all of the beam* nodes are set up with
> creds for deploying snapshots:
>
> https://issues.apache.org/jira/browse/INFRA-16935
>
> Unless otherwise advised, jobs should be set up to run on ubuntu nodes.
>
> This means ensuring that you enable:
>   "Restrict where this project can be run"
> and enter the word: ubuntu
>
> I've done this for CSV which has just completed OK.
>

Thank you very much!


>
> On 20 August 2018 at 17:53, Benedikt Ritter  wrote:
> > These failures don't seem to be related to my changes. Any idea how to
> fix
> > this?
> >
> > -- Forwarded message -
> > From: Apache Jenkins Server 
> > Date: Mo., 20. Aug. 2018 um 08:50 Uhr
> > Subject: Build failed in Jenkins: commons-csv #88
> > To: 
> >
> >
> > See <
> >
> https://builds.apache.org/job/commons-csv/88/display/redirect?page=changes
> >
> >
> > Changes:
> >
> > [britter] Add missing predefined formats to class documentation
> >
> > --
> > [...truncated 155.25 KB...]
> > [INFO] Downloaded from central:
> >
> https://repo.maven.apache.org/maven2/org/apache/httpcomponents/httpcore/4.4.4/httpcore-4.4.4.pom
> > (5.5 kB at 240 kB/s)
> > [INFO] Downloading from central:
> >
> https://repo.maven.apache.org/maven2/org/apache/httpcomponents/httpcomponents-core/4.4.4/httpcomponents-core-4.4.4.pom
> > [INFO] Downloaded from central:
> >
> https://repo.maven.apache.org/maven2/org/apache/httpcomponents/httpcomponents-core/4.4.4/httpcomponents-core-4.4.4.pom
> > (13 kB at 537 kB/s)
> > [INFO] Downloading from central:
> >
> https://repo.maven.apache.org/maven2/commons-codec/commons-codec/1.9/commons-codec-1.9.pom
> > [INFO] Downloaded from central:
> >
> https://repo.maven.apache.org/maven2/commons-codec/commons-codec/1.9/commons-codec-1.9.pom
> > (12 kB at 481 kB/s)
> > [INFO] Downloading from central:
> >
> https://repo.maven.apache.org/maven2/org/apache/commons/commons-parent/32/commons-parent-32.pom
> > [INFO] Downloaded from central:
> >
> https://repo.maven.apache.org/maven2/org/apache/commons/commons-parent/32/commons-parent-32.pom
> > (53 kB at 2.1 MB/s)
> > [INFO] Downloading from central:
> >
> https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-java/0.9.5/plexus-java-0.9.5.pom
> > [INFO] Downloaded from central:
> >
> https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-java/0.9.5/plexus-java-0.9.5.pom
> > (2.4 kB at 97 kB/s)
> > [INFO] Downloading from central:
> >
> https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-languages/0.9.5/plexus-languages-0.9.5.pom
> > [INFO] Downloaded from central:
> >
> https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-languages/0.9.5/plexus-languages-0.9.5.pom
> > (2.3 kB at 95 kB/s)
> > [INFO] Downloading from central:
> > https://repo.maven.apache.org/maven2/org/ow2/asm/asm/6.0/asm-6.0.pom
> > [INFO] Downloaded from central:
> > https://repo.maven.apache.org/maven2/org/ow2/asm/asm/6.0/asm-6.0.pom
> (1.9
> > kB at 84 kB/s)
> > [INFO] Downloading from central:
> >
> https://repo.maven.apache.org/maven2/org/ow2/asm/asm-parent/6.0/asm-parent-6.0.pom
> > [INFO] Downloaded from central:
> >
> https://repo.maven.apache.org/maven2/org/ow2/asm/asm-parent/6.0/asm-parent-6.0.pom
> > (5.5 kB at 229 kB/s)
> > [INFO] Downloading from central:
> >
> https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-container-default/1.0-alpha-7/plexus-container-default-1.0-alpha-7.pom
> > [INFO] Downloaded from central:
> >
> https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-container-default/1.0-alpha-7/plexus-container-default-1.0-alpha-7.pom
> > (1.3 kB at 56 kB/s)
> > [INFO] Downloading from central:
> >
> https://repo.maven.apache.org/maven2/plexus/plexus-containers/1.0.2/plexus-containers-1.0.2.pom
> > [INFO] Downloaded from central:
> >
> https://repo.maven.apache.org/maven2/plexus/plexus-containers/1.0.2/plexus-containers-1.0.2.pom
> > (471 B at 20 kB/s)
> > [INFO] Downloading from central:
> >
> https://repo.maven.apache.org/maven2/plexus/plexus-root/1.0.3/plexus-root-1.0.3.pom
> > [INFO] Downloaded from central:
> >
> https://repo.maven.apache.org/maven2/plexus/plexus-root/1.0.3/plexus-root-1.0.3.pom
> > (6.0 kB at 262 kB/s)
> > [INFO] Downloading from central:
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/shared/maven-s

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

[Benedikt Ritter]

Hi Gary,
Am Mi., 22. Aug. 2018 um 16:04 Uhr schrieb Gary Gregory <
garydgreg...@gmail.com>:

> WRT signing tags, ATM, I cannot git's -s option to work with GPG on
> Windows. Any clues?
>

Sorry, I'm on macOS. For that to work I needed to have the gpg-agent
running. But I don't know whether this is a unix thing.

The tag signing alone would not cause me to vote -1. I can live with an
unsigned tag. What really needs to be fixed are the differences between src
distribution and release tag in my opinion. I'll have time on Saturday to
have a look into that if you don't get to it until then.

Regards,
Benedikt


>
> Gary
>
> On Tue, Aug 21, 2018 at 1:06 AM Benedikt Ritter 
> wrote:
>
> > Hello Gary,
> >
> > -1, I there are several issues that we need to fix this before we can
> > release 2.6.1.
> >
> > I think the RELEASE NOTES need more work:
> >
> > "The Apache Commons Pool team is pleased to announce the release of
> Apache
> > Commons Pool 2.6.1-SNAPSHOT."
> > "No client code changes are required to migrate from versions 2.0-2.3 to
> > version 2.4.3." - what about migration to 2.6.1?
> > "Version 2 requires JDK level 1.6 or above" - Website states that Java 7
> is
> > required.
> >
> > The release tag is not signed:
> > ~/w/a/r/p/commons-pool git:(master) > git tag -v commons-pool-2.6.1-RC1
> > object 87c5dc14a967a70dd6e640395d4e842b021cdb8f
> > type commit
> > tag commons-pool-2.6.1-RC1
> > tagger Gary Gregory  1534517006 -0600
> >
> > Tag Apache Commons Pool release 2.6.1 RC1
> > error: no signature found
> >
> > There are various differences between to release tag in git and the
> > contents of the src archive:
> > ~/w/a/r/pool-2.6.1 > diff -rq commons-pool commons-pool2-2.6.1-src
> > Only in commons-pool: .git
> > Only in commons-pool: .gitignore
> > Only in commons-pool: .travis.yml
> > Only in commons-pool: CONTRIBUTING.md
> > Files commons-pool/NOTICE.txt and commons-pool2-2.6.1-src/NOTICE.txt
> differ
> > Only in commons-pool: README.md
> > Files commons-pool/RELEASE-NOTES.txt and
> > commons-pool2-2.6.1-src/RELEASE-NOTES.txt differ
> > Files commons-pool/pom.xml and commons-pool2-2.6.1-src/pom.xml differ
> > Only in commons-pool: pool-RC.sh
> > Only in commons-pool: pool-pre-RC.sh
> > Only in commons-pool: pool-release.sh
> > Only in commons-pool/src: assembly
> > Files commons-pool/src/changes/changes.xml and
> > commons-pool2-2.6.1-src/src/changes/changes.xml differ
> > Files commons-pool/src/site/resources/download_pool.cgi and
> > commons-pool2-2.6.1-src/src/site/resources/download_pool.cgi differ
> > Files commons-pool/src/site/site.xml and
> > commons-pool2-2.6.1-src/src/site/site.xml differ
> > Files commons-pool/src/site/xdoc/index.xml and
> > commons-pool2-2.6.1-src/src/site/xdoc/index.xml differ
> > Files commons-pool/src/site/xdoc/issue-tracking.xml and
> > commons-pool2-2.6.1-src/src/site/xdoc/issue-tracking.xml differ
> >
> > Some of them are okay (e.g. git files) but others are not (like
> > changes.xml)
> >
> > The build works on my machine using:
> > ~/w/a/r/p/commons-pool2-2.6.1-src > mvn -version
> > Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
> > 2018-06-17T20:33:14+02:00)
> > Maven home: /usr/local/Cellar/maven/3.5.4/libexec
> > Java version: 1.8.0_161, vendor: Oracle Corporation, runtime:
> > /Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home/jre
> > Default locale: de_DE, platform encoding: UTF-8
> > OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac"
> >
> > Regards,
> > Benedikt
> >
> > Am Fr., 17. Aug. 2018 um 18:08 Uhr schrieb Gary Gregory <
> > ggreg...@apache.org
> > >:
> >
> > > We have fixed one bug and updated optional dependencies since Apache
> > > Commons Pool 2.6.0 was released, so I would like to release Apache
> > Commons
> > > Pool 2.6.1.
> > >
> > > Apache Commons Pool 2.6.1 RC1 is available for review here:
> > > https://dist.apache.org/repos/dist/dev/commons/pool/2.6.1-RC1 (svn
> > > revision 28810)
> > >
> > > The Git tag commons-pool-2.6.1-RC1 commit for this RC is
> > > 87c5dc14a967a70dd6e640395d4e842b021cdb8f 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.1-RC1
>

Re: [CSV] Inconsistent record separator behavior

[Benedikt Ritter]

Hi Bruno,

Am Mi., 22. Aug. 2018 um 15:10 Uhr schrieb Bruno P. Kinoshita
:

> Hi,
>
>
> Will try to look at the code and give a better answer during the weekend.
> But risking a silly question, would it mean that users are not able to
> parse a CSV unless each CSV row is separated by LF or CRLF?


Yes.


> I remember getting a CSV in a government website some time ago that was
> formatted in a very strange way, and if I remember well it was a small
> file, but without LF or CRLF. I think it was using | to separate the rows,
> and , for columns.
>

I didn't know that there are formats that don't use a new line as line
separator.


>
>
> Quick search returned at least another person with similar issue
> https://stackoverflow.com/questions/29903202/how-to-read-csv-on-python-with-newline-separator
>
>
> Not sure if I understood the problem well, but in case it makes sense...
> my suggestion would be to perhaps confirm if we could change
> CSVPrinter.printComment to accept other characters for line ending?
>

The inconsistency I'm seeing is, that we an the one hand accept any
character sequence as a record separator. Comments in a way a like special
records to me. But our implementation seems to put them on a new "line"
using the println() method. The println() method in turn uses the record
seperator to start a new record. So it's not necessarily a new line.
Nevertheless while processing a comment, we look out for CR and LF and then
we call println() again. Maybe I'm just not getting it, but it feels pretty
messed up :-)

Regards,
Benedikt


>
>
> Thanks!
>
> Bruno
>
>
> 
> From: Benedikt Ritter 
> To: Commons Developers List 
> Sent: Tuesday, 21 August 2018 7:13 PM
> Subject: [CSV] Inconsistent record separator behavior
>
>
>
> Hi,
>
>
> we have this strange handling of record separator / line endings in CSV:
>
>
> Users can use what ever character sequence they like as a record separator.
>
> I could for example use the ! character to mark the end of a record.
>
> Then we have CSVPrinter.printComment(String). This inserts comments into a
>
> CSV output. It detects CRLF and call println() on the CSVFormat, which in
>
> turn uses the record separator to indicate a new record...
>
>
> So now I'm thinking: Does it make sense to use anything else but LF or CRLF
>
> as record separator? Maybe we should deprecate
>
> CSVFormat.recordSeparator(String) and introduce a LineEnding enum where
>
> users can choose between LF and CRLF. This way we can make the behavior
>
> between parsing and printing consistent.
>
>
> Thoughts?
>
> Benedikt
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [LANG] Minimum required Java version for 3.9

[Benedikt Ritter]

Hi,

Am Mi., 22. Aug. 2018 um 10:52 Uhr schrieb Francesco Chicchiriccò <
ilgro...@apache.org>:

> On 2018/08/20 17:09:27, Benedikt Ritter  wrote:
> > Hi,
> >
> > any objections against raising the minimum required Java version for lang
> > 3.9 to Java 1.8?
>
> +1
>
> Wouldn't 4.0 express better the change for the minimum required Java
> version?
>

We had the convention that Java version changes are okay, as long as the
code is binary compatible. Before we go 4.0, I'd like to see what oracle is
doing with the new release train where they release Java every few month.
I'm not sure what this means for us...

Benedikt


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

Re: [parent] change in commons.scmPubUrl in Parent 47

[Benedikt Ritter]

Hi,

I don't understand this discussion. Changes in Commons Parent have broken
the commons-compress build. So we should either roll this changes back or
those who need the changes in commons parent should fix the commons
compress build.

Regards,
Benedikt

Am Do., 16. Aug. 2018 um 19:08 Uhr schrieb Gary Gregory <
garydgreg...@gmail.com>:

> On Thu, Aug 16, 2018 at 10:27 AM Stefan Bodewig 
> wrote:
>
> > On 2018-08-16, Gary Gregory wrote:
> >
> > > I've use the release plugin a bunch without trouble. You might want to
> > see
> > > how other POMs are configured, for example [dbcp].
> >
> > The same way as Compress (no commons- prefix), I've got no idea why
> > running site-deploy should work for it.
> >
> > You use the release plugin if you only want to publish the site and not
> > cut a release?
> >
>
> I use the plugin build the dist folder (which includes a site) and generate
> the vote email text. For the real site, after the vote, I use the stock
> site-deploy goal.
>
>
> >
> > > You have to keep in mind that components like Collections, Lang, Pool,
> > and
> > > DBCP, the folder name is different from the artifact id because the
> > > artifact id contains a major version number, for example commons-lang
> is
> > > the folder but commons-lang3 is the AID.
> >
> > The parent POM says about componentId:
> >
> > 
> ${project.artifactId}
> 
> ${project.artifactId}
>
> For the seconds comment it should read
>  > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: [LANG] Minimum required Java version for 3.9

[Benedikt Ritter]

Hi Matt,
Am Di., 21. Aug. 2018 um 16:12 Uhr schrieb Matt Benson :

> Do you have specific new features or deprecations in mind to accompany the
> bump?
>

I'd like to add some helpers for working with java.util.Optional for
example. There are most certainly more opportunities for new Lang APIs once
we have access to the functional interfaces in java.util.function.

java.lang.Objects and java.lang.Arrays also got some new methods in 1.8
which make methods from ObjectUtils and ArrayUtils obsolete.
I also hope that we can deprecate parts of the time package because in Java
1.8 there is the new date and time API.

Regards,
Benedikt


>
> Matt
>
> On Tue, Aug 21, 2018, 7:00 AM Pascal Schumacher 
> wrote:
>
> > +1
> >
> > Am 20. August 2018 19:09:27 MESZ schrieb Benedikt Ritter <
> > brit...@apache.org>:
> > >Hi,
> > >
> > >any objections against raising the minimum required Java version for
> > >lang
> > >3.9 to Java 1.8?
> > >
> > >Regards,
> > >Benedikt
> >
>

[CSV] Inconsistent record separator behavior

[Benedikt Ritter]

Hi,

we have this strange handling of record separator / line endings in CSV:

Users can use what ever character sequence they like as a record separator.
I could for example use the ! character to mark the end of a record.
Then we have CSVPrinter.printComment(String). This inserts comments into a
CSV output. It detects CRLF and call println() on the CSVFormat, which in
turn uses the record separator to indicate a new record...

So now I'm thinking: Does it make sense to use anything else but LF or CRLF
as record separator? Maybe we should deprecate
CSVFormat.recordSeparator(String) and introduce a LineEnding enum where
users can choose between LF and CRLF. This way we can make the behavior
between parsing and printing consistent.

Thoughts?
Benedikt

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

[Benedikt Ritter]

Hello Gary,

-1, I there are several issues that we need to fix this before we can
release 2.6.1.

I think the RELEASE NOTES need more work:

"The Apache Commons Pool team is pleased to announce the release of Apache
Commons Pool 2.6.1-SNAPSHOT."
"No client code changes are required to migrate from versions 2.0-2.3 to
version 2.4.3." - what about migration to 2.6.1?
"Version 2 requires JDK level 1.6 or above" - Website states that Java 7 is
required.

The release tag is not signed:
~/w/a/r/p/commons-pool git:(master) > git tag -v commons-pool-2.6.1-RC1
object 87c5dc14a967a70dd6e640395d4e842b021cdb8f
type commit
tag commons-pool-2.6.1-RC1
tagger Gary Gregory  1534517006 -0600

Tag Apache Commons Pool release 2.6.1 RC1
error: no signature found

There are various differences between to release tag in git and the
contents of the src archive:
~/w/a/r/pool-2.6.1 > diff -rq commons-pool commons-pool2-2.6.1-src
Only in commons-pool: .git
Only in commons-pool: .gitignore
Only in commons-pool: .travis.yml
Only in commons-pool: CONTRIBUTING.md
Files commons-pool/NOTICE.txt and commons-pool2-2.6.1-src/NOTICE.txt differ
Only in commons-pool: README.md
Files commons-pool/RELEASE-NOTES.txt and
commons-pool2-2.6.1-src/RELEASE-NOTES.txt differ
Files commons-pool/pom.xml and commons-pool2-2.6.1-src/pom.xml differ
Only in commons-pool: pool-RC.sh
Only in commons-pool: pool-pre-RC.sh
Only in commons-pool: pool-release.sh
Only in commons-pool/src: assembly
Files commons-pool/src/changes/changes.xml and
commons-pool2-2.6.1-src/src/changes/changes.xml differ
Files commons-pool/src/site/resources/download_pool.cgi and
commons-pool2-2.6.1-src/src/site/resources/download_pool.cgi differ
Files commons-pool/src/site/site.xml and
commons-pool2-2.6.1-src/src/site/site.xml differ
Files commons-pool/src/site/xdoc/index.xml and
commons-pool2-2.6.1-src/src/site/xdoc/index.xml differ
Files commons-pool/src/site/xdoc/issue-tracking.xml and
commons-pool2-2.6.1-src/src/site/xdoc/issue-tracking.xml differ

Some of them are okay (e.g. git files) but others are not (like changes.xml)

The build works on my machine using:
~/w/a/r/p/commons-pool2-2.6.1-src > mvn -version
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
2018-06-17T20:33:14+02:00)
Maven home: /usr/local/Cellar/maven/3.5.4/libexec
Java version: 1.8.0_161, vendor: Oracle Corporation, runtime:
/Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac"

Regards,
Benedikt

Am Fr., 17. Aug. 2018 um 18:08 Uhr schrieb Gary Gregory :

> We have fixed one bug and updated optional dependencies since Apache
> Commons Pool 2.6.0 was released, so I would like to release Apache Commons
> Pool 2.6.1.
>
> Apache Commons Pool 2.6.1 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/pool/2.6.1-RC1 (svn
> revision 28810)
>
> The Git tag commons-pool-2.6.1-RC1 commit for this RC is
> 87c5dc14a967a70dd6e640395d4e842b021cdb8f 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.1-RC1
>
> Maven artifacts are here:
>
>
> https://repository.apache.org/content/repositories/orgapachecommons-1370/org/apache/commons/commons-pool2/2.6.1/
>
> These are the Maven artifacts and their hashes in Nexus:
>
> #Release SHA-256s
> #Fri Aug 17 09:52:45 MDT 2018
>
> commons-pool2-2.6.1-bin-zip.asc=c557973fdb9b917eb9bd3aea01db5ec1fd9ba81dc44de3ebbfcf0d30d3034457
>
> commons-pool2-2.6.1-src-tar.gz=2c9a0cd9ca5d78321139abf66bf63bfdffab4e2c84949220efc836bab14925fb
>
> commons-pool2-2.6.1-sources-java-source=9ec444a335d22398db9e2b8cff08651bb200b9a43be70603ee864a69698d70a1
>
> commons-pool2-2.6.1-bin-tar.gz.asc=420d24c516e0a85461f4b723f26b3d1004f5891fe35eeb221438f1bebc529697
>
> commons-pool2-2.6.1-src-zip=1039a4c88929549e5bb859443a02bf65679d94fd2722c8da2b0b116f737157ed
>
> commons-pool2-2.6.1-bin-tar.gz=0e136611fcd6475cef0604c63901a64169af674e0a4bdc3eb6bdfd3f9974e189
>
> commons-pool2-2.6.1-sources-jar.asc=b2d7c010ac17fa8c25b1a07c964774e520170b293d7280257dae730a7e6f273c
>
> commons-pool2-2.6.1-src-tar.gz.asc=e5101573bb01aef53d69dc4161b0ce39629cc8a8029edf20eda8b591acba9ff0
>
> commons-pool2-2.6.1-bin-zip=9c67aebafbbe9a6937f51fd88dee2c5bf2b2bb38391faf866cf2c0ec1d0144b2
>
> commons-pool2-2.6.1-tests-jar.asc=1aff7c2d2482c8ad8abfbdbf5a5e6e2a2d6842f5ff3812b83de53dc78139101f
>
> commons-pool2-2.6.1-javadoc-jar.asc=627815d18443a31a0965209c23f4c38f7a4f252983db8adbf5766c4e744070a4
>
> commons-pool2-2.6.1-pom.asc=53303ad02b290d2d7740f4b322c8f3c3de1cab273fccd56afe487d161d827b3a
>
> commons-pool2-2.6.1-jar.asc=48c226b9cecd68c3ff4b745ccc5279fceb3feb537483ed0c5b81ef29ae95ec4b
>
> commons-pool2-2.6.1-tests-test-jar=54a0e606fbd469582b0b87ee61ebb5fd05b2895cd70649ce61b4a759528880a8
>
> commons-pool2-2.6.1-javadoc-javadoc=246788c13a31585bf53d937ab5689d6553dd317b120919e65e0851ace5cd0e1e
>
> commons-pool2

[LANG] Minimum required Java version for 3.9

[Benedikt Ritter]

Hi,

any objections against raising the minimum required Java version for lang
3.9 to Java 1.8?

Regards,
Benedikt

Fwd: Build failed in Jenkins: commons-csv #88

[Benedikt Ritter]

These failures don't seem to be related to my changes. Any idea how to fix
this?

-- Forwarded message -
From: Apache Jenkins Server 
Date: Mo., 20. Aug. 2018 um 08:50 Uhr
Subject: Build failed in Jenkins: commons-csv #88
To: 


See <
https://builds.apache.org/job/commons-csv/88/display/redirect?page=changes>

Changes:

[britter] Add missing predefined formats to class documentation

--
[...truncated 155.25 KB...]
[INFO] Downloaded from central:
https://repo.maven.apache.org/maven2/org/apache/httpcomponents/httpcore/4.4.4/httpcore-4.4.4.pom
(5.5 kB at 240 kB/s)
[INFO] Downloading from central:
https://repo.maven.apache.org/maven2/org/apache/httpcomponents/httpcomponents-core/4.4.4/httpcomponents-core-4.4.4.pom
[INFO] Downloaded from central:
https://repo.maven.apache.org/maven2/org/apache/httpcomponents/httpcomponents-core/4.4.4/httpcomponents-core-4.4.4.pom
(13 kB at 537 kB/s)
[INFO] Downloading from central:
https://repo.maven.apache.org/maven2/commons-codec/commons-codec/1.9/commons-codec-1.9.pom
[INFO] Downloaded from central:
https://repo.maven.apache.org/maven2/commons-codec/commons-codec/1.9/commons-codec-1.9.pom
(12 kB at 481 kB/s)
[INFO] Downloading from central:
https://repo.maven.apache.org/maven2/org/apache/commons/commons-parent/32/commons-parent-32.pom
[INFO] Downloaded from central:
https://repo.maven.apache.org/maven2/org/apache/commons/commons-parent/32/commons-parent-32.pom
(53 kB at 2.1 MB/s)
[INFO] Downloading from central:
https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-java/0.9.5/plexus-java-0.9.5.pom
[INFO] Downloaded from central:
https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-java/0.9.5/plexus-java-0.9.5.pom
(2.4 kB at 97 kB/s)
[INFO] Downloading from central:
https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-languages/0.9.5/plexus-languages-0.9.5.pom
[INFO] Downloaded from central:
https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-languages/0.9.5/plexus-languages-0.9.5.pom
(2.3 kB at 95 kB/s)
[INFO] Downloading from central:
https://repo.maven.apache.org/maven2/org/ow2/asm/asm/6.0/asm-6.0.pom
[INFO] Downloaded from central:
https://repo.maven.apache.org/maven2/org/ow2/asm/asm/6.0/asm-6.0.pom (1.9
kB at 84 kB/s)
[INFO] Downloading from central:
https://repo.maven.apache.org/maven2/org/ow2/asm/asm-parent/6.0/asm-parent-6.0.pom
[INFO] Downloaded from central:
https://repo.maven.apache.org/maven2/org/ow2/asm/asm-parent/6.0/asm-parent-6.0.pom
(5.5 kB at 229 kB/s)
[INFO] Downloading from central:
https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-container-default/1.0-alpha-7/plexus-container-default-1.0-alpha-7.pom
[INFO] Downloaded from central:
https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-container-default/1.0-alpha-7/plexus-container-default-1.0-alpha-7.pom
(1.3 kB at 56 kB/s)
[INFO] Downloading from central:
https://repo.maven.apache.org/maven2/plexus/plexus-containers/1.0.2/plexus-containers-1.0.2.pom
[INFO] Downloaded from central:
https://repo.maven.apache.org/maven2/plexus/plexus-containers/1.0.2/plexus-containers-1.0.2.pom
(471 B at 20 kB/s)
[INFO] Downloading from central:
https://repo.maven.apache.org/maven2/plexus/plexus-root/1.0.3/plexus-root-1.0.3.pom
[INFO] Downloaded from central:
https://repo.maven.apache.org/maven2/plexus/plexus-root/1.0.3/plexus-root-1.0.3.pom
(6.0 kB at 262 kB/s)
[INFO] Downloading from central:
https://repo.maven.apache.org/maven2/org/apache/maven/shared/maven-shared-utils/3.0.1/maven-shared-utils-3.0.1.jar
[INFO] Downloading from central:
https://repo.maven.apache.org/maven2/org/apache/maven/shared/maven-invoker/2.2/maven-invoker-2.2.jar
[INFO] Downloading from central:
https://repo.maven.apache.org/maven2/org/apache/maven/shared/maven-common-artifact-filters/3.0.0/maven-common-artifact-filters-3.0.0.jar
[INFO] Downloading from central:
https://repo.maven.apache.org/maven2/org/apache/maven/shared/maven-artifact-transfer/0.9.1/maven-artifact-transfer-0.9.1.jar
[INFO] Downloading from central:
https://repo.maven.apache.org/maven2/org/slf4j/slf4j-api/1.7.5/slf4j-api-1.7.5.jar
[INFO] Downloaded from central:
https://repo.maven.apache.org/maven2/org/apache/maven/shared/maven-invoker/2.2/maven-invoker-2.2.jar
(30 kB at 1.1 MB/s)
[INFO] Downloading from central:
https://repo.maven.apache.org/maven2/org/apache/maven/doxia/doxia-sink-api/1.7/doxia-sink-api-1.7.jar
[INFO] Downloaded from central:
https://repo.maven.apache.org/maven2/org/apache/maven/shared/maven-shared-utils/3.0.1/maven-shared-utils-3.0.1.jar
(154 kB at 5.1 MB/s)
[INFO] Downloading from central:
https://repo.maven.apache.org/maven2/org/apache/maven/doxia/doxia-logging-api/1.7/doxia-logging-api-1.7.jar
[INFO] Downloaded from central:
https://repo.maven.apache.org/maven2/org/apache/maven/shared/maven-artifact-transfer/0.9.1/maven-artifact-transfer-0.9.1.jar
(123 kB at 4.1 MB/s)
[INFO] Downloading from central:
https://repo.maven.apache.org/maven2

[ALL] Make checkstyle:check part of default maven goal?

[Benedikt Ritter]

Hi,

one thing I always have to do when preparing a release is to fix all the
checkstyle and findbugs errors. This step could be eliminated if we added
checkstyle:check and findbugs:check to the maven default goal. This way it
would be executed on CI builds and we would see failing checkstyle/findbugs
right away.

WDYT?
Benedikt

[CSV] Preparing release 1.6

[Benedikt Ritter]

Hi,

it's been a year since the last CSV release. I think it is time to push out
the improvements we have on the master branch. I'm going to work towards a
release in the next week. If there is something you would like to fix
before 1.6 - now is your chance ;-)

Regards,
Benedikt

Re: [ALL] GitLab?

[Benedikt Ritter]

Hi Gary,

Am Fr., 17. Aug. 2018 um 16:27 Uhr schrieb Gary Gregory <
garydgreg...@gmail.com>:

> Hi All:
>
> I see https://gitlab.com/ApacheMirror
>
> I wonder if this is our official mirror on GL and whether we should mirror
> our Commons projects there.
>

Although I love GitLab as a tool, I don't think we should mirror our
projects to more than one hosted SCM. It will get hard to track issues und
PRs created at GitHub and GitLab.

Regards,
Benedikt


>
> Gary
>

Re: [LANG] Adding isEmpty and isNotEmpty methods to ObjectUtils

[Benedikt Ritter]

Hello Alexander,

Am Fr., 17. Aug. 2018 um 15:09 Uhr schrieb Alexander Tsvetkov <
alexander.tsvetkov...@gmail.com>:

> Hi Benedikt,
>
> Yes, ObjectUtils.isEmpty(null) would return true. You can review the pull
> request (https://github.com/apache/commons-lang/pull/342) if you'd like to
> see the entire implementation in its current state.
>

LGTM, but I like to work until after the release of Lang 3.8 before we
apply this changes. So I'll probably merge your changes on Sunday or Monday.

Regards,
Benedikt


>
> Thanks and best regards,
> Alexander
>
> 2018-08-17 15:41 GMT+03:00 Benedikt Ritter :
>
> > Hello Alexander,
> >
> > welcome to the mailing list and thanks for your contribution.
> >
> > Am Fr., 17. Aug. 2018 um 10:43 Uhr schrieb Alexander Tsvetkov <
> > alexander.tsvetkov...@gmail.com>:
> >
> > > Hi all,
> > >
> > > First of all, apologies if I have messed something up - this is my
> first
> > > attempt at contributing to Apache.
> > >
> > > With that said, I'd like to propose adding two new methods to Commons
> > > Lang's ObjectUtils class:
> > >   - isEmpty()
> > >   - isNotEmpty()
> > >
> > > These would check whether the object is empty (or not empty
> respectively)
> > > based on its type:
> > >   - CharSequence - Considered empty if its length is zero.
> > >   - Array - Considered empty if its length is zero.
> > >   - Collection - Considered empty if it has zero elements.
> > >   - Map - Considered empty if it has zero key-value mappings.
> > > The object would be considered "not-empty" if its type is not one of
> the
> > > types mentioned above.
> > >
> > > There is an already existing method that does exactly this in Spring's
> > > ObjectUtils (see
> > >
> > > https://github.com/spring-projects/spring-framework/blob/
> > 2ac23badee02697c5eb87c46f955387b32a0d581/spring-core/src/
> > main/java/org/springframework/util/ObjectUtils.java#L134
> > > ),
> > > but I think it would be helpful to people (myself and my team included)
> > if
> > > there was a similar method in Commons Lang's ObjectUtils. That way we
> > > wouldn't have to add a dependency to Spring or re-implement the method
> in
> > > our code base.
> > >
> > > What do you think?
> > >
> >
> > sounds reasonable. How would you handle null inputs? For example
> > StringUtils.isEmpty(null) == true, so I would expect the same behavior
> from
> > ObjectUtils.isEmpty
> >
> > Regards,
> > Benedikt
> >
> >
> > >
> > > I've opened a JIRA ticket and a GitHub pull request as well:
> > > https://issues.apache.org/jira/browse/LANG-1411
> > > https://github.com/apache/commons-lang/pull/342
> > >
> > > Best regards,
> > > Alexander
> > >
> >
>

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

[Benedikt Ritter]

Hello Rob,

this RC looks good to me. +1

Good job!
Benedikt

Am Do., 16. Aug. 2018 um 03:54 Uhr 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: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [LANG] Adding isEmpty and isNotEmpty methods to ObjectUtils

[Benedikt Ritter]

Hello Alexander,

welcome to the mailing list and thanks for your contribution.

Am Fr., 17. Aug. 2018 um 10:43 Uhr schrieb Alexander Tsvetkov <
alexander.tsvetkov...@gmail.com>:

> Hi all,
>
> First of all, apologies if I have messed something up - this is my first
> attempt at contributing to Apache.
>
> With that said, I'd like to propose adding two new methods to Commons
> Lang's ObjectUtils class:
>   - isEmpty()
>   - isNotEmpty()
>
> These would check whether the object is empty (or not empty respectively)
> based on its type:
>   - CharSequence - Considered empty if its length is zero.
>   - Array - Considered empty if its length is zero.
>   - Collection - Considered empty if it has zero elements.
>   - Map - Considered empty if it has zero key-value mappings.
> The object would be considered "not-empty" if its type is not one of the
> types mentioned above.
>
> There is an already existing method that does exactly this in Spring's
> ObjectUtils (see
>
> https://github.com/spring-projects/spring-framework/blob/2ac23badee02697c5eb87c46f955387b32a0d581/spring-core/src/main/java/org/springframework/util/ObjectUtils.java#L134
> ),
> but I think it would be helpful to people (myself and my team included) if
> there was a similar method in Commons Lang's ObjectUtils. That way we
> wouldn't have to add a dependency to Spring or re-implement the method in
> our code base.
>
> What do you think?
>

sounds reasonable. How would you handle null inputs? For example
StringUtils.isEmpty(null) == true, so I would expect the same behavior from
ObjectUtils.isEmpty

Regards,
Benedikt


>
> I've opened a JIRA ticket and a GitHub pull request as well:
> https://issues.apache.org/jira/browse/LANG-1411
> https://github.com/apache/commons-lang/pull/342
>
> Best regards,
> Alexander
>

I'm alive!

[Benedikt Ritter]

Hi all,

I have been pretty quite over the past 12 month. There are a lot of reasons
for this. The most important reasons are:
- I've been Lead Developer in a very challenging project which included a
lot of traveling between my home and Hamburg (which is about 250km from
here).
- I got married, and there was a lot of planning to do for the wedding.

But now I'm back and I want to start working on commons again. Looking
forward to collaborate with you again!

Regards,
Benedikt

Re: [Signing] New component for code signing

[Benedikt Ritter]

Hello Mark,

+1 In my opinion this is exactly what Commons should be doing.

Regards,
Benedikt

Mark Thomas  schrieb am Di., 23. Jan. 2018 um 07:34 Uhr:

> All,
>
> As you may know, the ASF has been using a code signing service for a
> number of years provided by Symantec. We use it to sign Commons Daemon
> Windows binaries.
>
> The code signing service has a web based GUI and a SOAP based API.
> Tomcat has written an Ant task to use the SOAP API and Sling has taken
> this used and used it as the basis for a Maven plug-in.
>
> Currently, the Ant task is hosted within the Tomcat codebase and the
> Maven plug-in within Sling. Both communities would like to move this to
> a better home where it can more easily be re-used by other Apache
> projects and other organisations using Symantec's code signing service.
>
> After some thought and discussion, we (Robert Munteanu and I) would like
> to propose this code signing component as a new component at Commons.
> Our reasons for this are as follows:
>
> - The code is written in Java
> - It is a relatively small component
> - It is a utility likely to be of interest to multiple Apache projects
> - If it is going to be re-used across multiple projects, it needs to be
>   formally released and that requires a PMC
>
> If accepted the plan would be:
> - commit the original Tomcat code for the Ant task
> - refactor it to allow re-use of code common to the Ant task and Maven
>   plug-in
> - add the Maven plug-in
> - release it as a single JAR that provided both the Ant task and the
>   Maven plug-in
> - Ongoing review and maintenance (there are a couple of areas that could
>   benefit from some improvement)
>
> Thoughts? Comments?
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Hello and possible addition

[Benedikt Ritter]

> Am 03.01.2018 um 15:02 schrieb Otto Fowler :
> 
> Just to check, Java 7 is the required language level?

Yes

> 
> 
> On January 3, 2018 at 07:12:03, Otto Fowler (ottobackwa...@gmail.com) wrote:
> 
> While working on adding some timing functionality to a Metron feature, I
> came across the
> Stopwatch
> 
> class, but found that it didn’t suite my needs.
> 
> What I wanted to do was to create a timing from a top level function in our
> Stellar
> 
> dsl, and have have a group of related timings, such that the end result
> was the overall time of the call, and nested timings of other calls
> executed during the dsl execution of that function. These timings would all
> be named, and have a path for identification and include timing the
> language compiler/execution as well as the function execution itself. It
> would be helpful if they were tagged in some way as well, such that the
> consumer could filter during visitation.
> 
> So I have written StackWatch  to
> provide this functionality, and submitted it in a Metron PR
> .
> 
> From the PR description:
> StackWatch
> 
> A set of utility classes under the new package stellar.common.timing have
> been added. These provide the StackWatch functionality.
> 
> StackWatch provides an abstraction over the Apache Commons StopWatch class
> that allows callers to create multiple named and possibly nested timing
> operations.
> 
> <…>
> 
> This class may be more generally useful to this and other projects, but I
> am not sure where it would live since we wouldn’t want it in common.
> 
> StackWatch uses a combination of Deque and a custom Tree implementation to
> create, start and end timing operations.
> 
> A Visitor pattern is also implemented to allow for retrieving the results
> after the completion of the operation.
> 
> See the StackWatch tests for examples of nested function timings.
> --
> 
> A quick look at the PR and it’s test or the github project ( they are in
> sync ) should show the idea.
> 
> I am sending this to see if this functionality would be appropriate for
> commons in some way. If so, the I can create the jira and submit the pr.
> Even if it is not appropriate, any feedback or pr’s on the github project
> would still be most welcome.
> 
> Thanks for all the work that has made commons so valuable to other Apache
> projects and java developers in general!


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

Re: Hello and possible addition

[Benedikt Ritter]

Hello Otto,

> Am 02.01.2018 um 04:28 schrieb Otto Fowler :
> 
> Hello Commons,
> 
> My name is Otto Fowler ( ottobackwards on github, otto -AT- apache.org at
> apache ), and I’m a PMC member of the Apache Metron
>  project.
> 
> While working on adding some timing functionality to a Metron feature, I
> came across the
> Stopwatch
> 
> class, but found that it didn’t suite my needs.
> 
> What I wanted to do was to create a timing from a top level function in our
> Stellar
> 
> dsl, and have have a group of related timings, such that the end result was
> the overall time of the call, and nested timings of other calls executed
> during the dsl execution of that function. These timings would all be
> named, and have a path for identification and include timing the language
> compiler/execution as well as the function execution itself. It would be
> helpful if they were tagged in some way as well, such that the consumer
> could filter during visitation.
> 
> So I have written StackWatch 
> to provide this functionality, and submitted it in a Metron PR
> .
> 
> From the PR description:
> StackWatch
> 
> A set of utility classes under the new package stellar.common.timing have
> been added. These provide the StackWatch functionality.
> 
> StackWatch provides an abstraction over the Apache Commons StopWatch class
> that allows callers to create multiple named and possibly nested timing
> operations.
> 
> <…>
> 
> This class may be more generally useful to this and other projects, but I
> am not sure where it would live since we wouldn’t want it in common.
> 
> StackWatch uses a combination of Deque and a custom Tree implementation to
> create, start and end timing operations.
> 
> A Visitor pattern is also implemented to allow for retrieving the results
> after the completion of the operation.
> 
> See the StackWatch tests for examples of nested function timings.
> --
> 
> A quick look at the PR and it’s test or the github project ( they are in
> sync ) should show the idea.
> 
> I am sending this to see if this functionality would be appropriate for
> commons in some way. If so, the I can create the jira and submit the pr.
> Even if it is not appropriate, any feedback or pr’s on the github project
> would still be most welcome.
> 
> Thanks for all the work that has made commons so valuable to other Apache
> projects and java developers in general!

This sounds like a useful tool. Nobody objected against adding it to commons 
lang, so I don’t see a reason not to include it. All Apache committers have 
write access to the commons repositories, so you good go ahead and add it 
yourself! But maybe it makes sense to create a Pull Request against the commons 
lang GitHub mirror so people are triggered to have a look :-)

Regards,
Benedikt


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

Re: [beanutils] Moving to beanutils2

[Benedikt Ritter]

Hi,

> Am 30.12.2017 um 16:24 schrieb Gary Gregory :
> 
> Who can speak to that code base?

I’ve worked on BeanUtils2 some years ago together with Simone Tripodi. I think 
we should better work on this redesign instead oh pushing the old code base as 
2.0 just to fix some dependencies. In fact I think that BeanUtils 1 exposes 
classes from Commons Collections in its public API is a big mess that we should 
fix when we roll a new major release.

Benedikt

> 
> Gary
> 
> On Dec 30, 2017 03:54, "Benedikt Ritter"  wrote:
> 
>> 
>> 
>>> Am 29.12.2017 um 19:58 schrieb Gary Gregory :
>>> 
>>> On Wed, Dec 27, 2017 at 11:55 AM, Gary Gregory 
>>> wrote:
>>> 
>>>> The changes for:
>>>> 
>>>> BEANUTILS-500 Upgrade commons-collections to 4
>>>> 
>>>> break BC (see BEANUTILS-500).
>>>> 
>>>> Therefore, I created BEANUTILS-503: Change packaging from
>>>> org.apache.commons.beanutils to org.apache.commons.beanutils2
>>>> 
>>>> This change should happen sooner rather than later IMO to allow folks
>>>> using SNAPSHOT builds to adapt.
>>>> 
>>>> Thoughts?
>>>> 
>>> 
>>> This is done is SVN trunk.
>> 
>> We already have a complete rewrite of the BeanUtils API in the sandbox
>> [1]. What do we want to do with that?
>> 
>> Regards,
>> Benedikt
>> 
>> [1] http://svn.apache.org/viewvc/commons/sandbox/beanutils2/trunk/
>> 
>>> 
>>> Gary
>>> 
>>> 
>>>> 
>>>> 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: [collections] toward 4.2

[Benedikt Ritter]

Hi,

> Am 30.12.2017 um 20:07 schrieb Gary Gregory :
> 
> On Dec 30, 2017 03:55, "Benedikt Ritter"  wrote:
> 
> Hi,
> 
> +1! We should finally get COLLECTIONS-653 out of the door.
> 
> 
> Do you mean that the Javado is Java-8-clean?

No, the Java 9 Module Manifest headers. The fix is already in trunk and just 
needs to be released.

Regards,
Benedikt

> 
> Gary
> 
> 
> Benedikt
> 
>> Am 29.12.2017 um 18:58 schrieb Gary Gregory :
>> 
>> Hi All,
>> 
>> Does anyone want to fix some issues for 4.2? I am thinking of pushing out
>> an RC soon.
>> 
>> This is what we have so far:
>> 
>> 
>>   
>> Unit tests MapUtilsTest and ListIteratorWrapperTest no longer fail on
>> Java 9.
>>   
>>   
>> Intermittent test failures in Windows for HashSetValuedHashMap.
>>   
>>   
>> Uncomment test in AbstractMapTest regarding LRUMap equals.
>>   
>>   
>> Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility.
>>   
>>   
>> Fix site build on Java 8.
>>   
>>   
>> Update Javadoc to Build on Java 1.8.
>>   
>>   
>> Build status, Coverage status and Maven central weren't in README.md
>>   
>>   
>> Improve efficiency of DefaultedMap.get.
>>   
>>   
>> Small improvements for generics, conditional statements, and warnings
>> suppressions.
>>   
>>   
>> Update platform from Java 6 to Java 7.
>>   
>>   
>> Web site spelling error: MultiValuedMapeList.
>>   
>>   > due-to="Enrique">
>>  Correction of Javadoc for
>> org.apache.commons.collections4.functors.CatchAndRethrowClosure.
>>   
>>   
>> Add null-safe MapUtils.size(Map<?, ?>) method.
>>   
>>   > due-to="Shailender Bathula, Gary Gregory">
>> PatriciaTrie prefixMap clear throws NullPointerException.
>>   
>>   
>> Add class SortedProperties to sort keys.
>>   
>> 
>> 
>> 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: [ALL] Who want's access to @ApacheCommons

[Benedikt Ritter]

Hi,

> Am 27.12.2017 um 18:10 schrieb Sergio Fernández :
> 
> I guess if the people managing the account could just RT the
> project-related tweets (particularly announcements), I think that would be
> great.
> 
> I'm happy to help on that, but I'm just a raw committer, not sure if it
> would be appropriate.

Sure thing! Just give me your twitter handle and I’ll add you.

Benedikt

> 
> On Tue, Dec 26, 2017 at 2:22 AM, Benedikt Ritter  wrote:
> 
>> Hi,
>> 
>> I’ve created the Apache Commons twitter account [1] a few years ago. I try
>> to announce anything that might be of interest for Commons users. Since my
>> activity for the project varies a bit depending on what is going on in my
>> life, I think it would be good if more people would have access to the
>> twitter account.
>> Twitter has ha nice feature, called Teams, where you can give other
>> Twitter users access to a team account. So if anybody wants to have access,
>> just ping me with your Twitter user name and I can grant you access.
>> 
>> Regards,
>> Benedikt
>> 
>> [1] https://twitter.com/ApacheCommons
>> 
>> 
>> -
>> 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: [beanutils] Toward 2.0.0

[Benedikt Ritter]

Hi,

> Am 28.12.2017 um 20:49 schrieb Gary Gregory :
> 
> Hi All,
> 
> - BeanUtils now has a new package o.a.c.beanutils2.
> - BeanUtils now depends on Apache Commons Collection 4 (instead of 3),
> which caused the above.
> 
> What more do we want before releasing 2.0.0?
> 
> Updating from BU 1.x to 2.x should be "simple" for now: Just update your
> imports.
> 
> Thoughts?

See my comment on the other thread. What about the BeanUtils rewrite we have in 
the Sandbox?

> 
> Gary


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

Re: [collections] toward 4.2

[Benedikt Ritter]

Hi,

+1! We should finally get COLLECTIONS-653 out of the door.

Benedikt

> Am 29.12.2017 um 18:58 schrieb Gary Gregory :
> 
> Hi All,
> 
> Does anyone want to fix some issues for 4.2? I am thinking of pushing out
> an RC soon.
> 
> This is what we have so far:
> 
>  
>
>  Unit tests MapUtilsTest and ListIteratorWrapperTest no longer fail on
> Java 9.
>
>
>  Intermittent test failures in Windows for HashSetValuedHashMap.
>
>
>  Uncomment test in AbstractMapTest regarding LRUMap equals.
>
>
>  Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility.
>
>
>  Fix site build on Java 8.
>
>
>  Update Javadoc to Build on Java 1.8.
>
>
>  Build status, Coverage status and Maven central weren't in README.md
>
>
>  Improve efficiency of DefaultedMap.get.
>
>
>  Small improvements for generics, conditional statements, and warnings
> suppressions.
>
>
>  Update platform from Java 6 to Java 7.
>
>
>  Web site spelling error: MultiValuedMapeList.
>
> due-to="Enrique">
>   Correction of Javadoc for
> org.apache.commons.collections4.functors.CatchAndRethrowClosure.
>
>
>  Add null-safe MapUtils.size(Map) method.
>
> due-to="Shailender Bathula, Gary Gregory">
>  PatriciaTrie prefixMap clear throws NullPointerException.
>
>
>  Add class SortedProperties to sort keys.
>
>  
> 
> Gary


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