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

2018-09-20 Thread Gary Gregory 
On Thu, Sep 20, 2018 at 2:33 PM P. Ottlinger  wrote:

> Hi,
>
> Am 19.09.2018 um 13:44 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=1833926
> >
> > Do we roll a 3.8.1?
>
>
> +1
>

The VOTE in already under way...

Gary


>
> Thanks,
> Phil
>
> -
> 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

2018-09-20 Thread P. Ottlinger 
Hi,

Am 19.09.2018 um 13:44 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=1833926
> 
> Do we roll a 3.8.1?


+1

Thanks,
Phil

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

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

2018-09-20 Thread Oliver Heger 
Hi Rob,

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

+1

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

Oliver

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

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

2018-09-20 Thread Rory O'Donnell 

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


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:\Program Files\Java\jdk-11\bin\java"

-javaagent:C:\\Users\\ggregory\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.1\\org.jacoco.agent-0.8.1-runtime.jar=destfile=C:\\temp\\rc\\commons-csv-1.6-src\\target\\jacoco.exec
-jar

C:\Users\ggregory\AppData\Local\Temp\surefire8193357594532737911\surefirebooter4797436355437582319.jar
C:\Users\ggregory\AppData\Local\Temp\surefire8193357594532737911
2018-09-19T18-30-01_925-jvmRun1 surefire14765244413659300989tmp
surefire_06894247545608575344tmp"
[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\jdk-11\bin\java"

-javaagent:C:\\Users\\ggregory\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.1\\org.jacoco.agent-0.8.1-runtime.jar=destfile=C:\\temp\\rc\\commons-csv-1.6-src\\target\\jacoco.exec
-jar

C:\Users\ggregory\AppData\Local\Temp\surefire8193357594532737911\surefirebooter4797436355437582319.jar
C:\Users\ggregory\AppData\Local\Temp\surefire8193357594532737911
2018-09-19T18-30-01_925-jvmRun1 surefire14765244413659300989tmp
surefire_06894247545608575344tmp"
[ERROR] Error occurred in starting fork, check output in log
[ERROR] Process Exit Code: 1
[ERROR] at

org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:671)
[ERROR] at

org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
[ERROR] at

org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:278)
[ERROR] at

Re: [All] CP definitions

2018-09-20 Thread Gilles 

On Thu, 20 Sep 2018 08:53:38 -0400, Rob Tompkins wrote:
On Sep 20, 2018, at 3:10 AM, Benedikt Ritter  
wrote:


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.


I’m relatively indifferent to how we accomplish this. For the sake of
discussion let our project.artifactId=commons-something where N
represents the major version of the release with N being the empty
string for a major version equal to 1. We still are stuck with half 
of

our projects in one state for building with componentid=something and
the other half with componentid=somethingN. Furthermore we need a
properties representing both “something” as well as “somethingN” 
given

that we have our dist urls and site urls not containing the major
release version.

Do you propose something other than:

something
somethingN

and change [parent] back to




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




What about starting from maven requirements and try and avoid
redundancies (that ultimately lead to inconsistencies)?

Given are
  
  

Can the parent POM generate the properties values required by
the "Commons" infrastructure from those (using maven plugin
code, I guess)?

E.g. generate "commons-lang" (a.o. to generate the path to the
web site's SVN repository) from
  commons-lang3
  3.9-SNAPSHOT

[Side-effect would be to enforce the rule for changing top-level
package name in step with a new major version.]

Best regards,
Gilles



If so, what is it? Let’s pick it and move forward.

Cheers,
-Rob

[Ref]
June conversation on the matter as well.
https://markmail.org/message/7xbk3zm6pornsrto



[...]



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

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

2018-09-20 Thread Rob Tompkins 



> On Sep 20, 2018, at 3:10 AM, Benedikt Ritter  wrote:
> 
> 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.

I’m relatively indifferent to how we accomplish this. For the sake of 
discussion let our project.artifactId=commons-something where N represents the 
major version of the release with N being the empty string for a major version 
equal to 1. We still are stuck with half of our projects in one state for 
building with componentid=something and the other half with 
componentid=somethingN. Furthermore we need a properties representing both 
“something” as well as “somethingN” given that we have our dist urls and site 
urls not containing the major release version. 

Do you propose something other than:

something
somethingN

and change [parent] back to



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



If so, what is it? Let’s pick it and move forward.

Cheers,
-Rob

[Ref]
June conversation on the matter as well.
https://markmail.org/message/7xbk3zm6pornsrto

> 
> 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=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

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

2018-09-20 Thread Gary Gregory 
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:\Program Files\Java\jdk-11\bin\java"
>
> -javaagent:C:\\Users\\ggregory\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.1\\org.jacoco.agent-0.8.1-runtime.jar=destfile=C:\\temp\\rc\\commons-csv-1.6-src\\target\\jacoco.exec
> -jar
>
> C:\Users\ggregory\AppData\Local\Temp\surefire8193357594532737911\surefirebooter4797436355437582319.jar
> C:\Users\ggregory\AppData\Local\Temp\surefire8193357594532737911
> 2018-09-19T18-30-01_925-jvmRun1 surefire14765244413659300989tmp
> surefire_06894247545608575344tmp"
> [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\jdk-11\bin\java"
>
> -javaagent:C:\\Users\\ggregory\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.1\\org.jacoco.agent-0.8.1-runtime.jar=destfile=C:\\temp\\rc\\commons-csv-1.6-src\\target\\jacoco.exec
> -jar
>
> C:\Users\ggregory\AppData\Local\Temp\surefire8193357594532737911\surefirebooter4797436355437582319.jar
> C:\Users\ggregory\AppData\Local\Temp\surefire8193357594532737911
> 2018-09-19T18-30-01_925-jvmRun1 surefire14765244413659300989tmp
> surefire_06894247545608575344tmp"
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 1
> [ERROR] at
>
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:671)
> [ERROR] at
>
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
> [ERROR] at
>
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:278)
> [ERROR] at
>
>

Re: [All] CP definitions

2018-09-20 Thread Gilles 

On Thu, 20 Sep 2018 09:10:50 +0200, Benedikt Ritter wrote:

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.


I'm for it too. But not everyone is (or thinks that things
get easier)...


But let's make sure that all the other
components still work.


I certainly agree, and am also frustrated that what used to work
suddenly doesn't anymore without anything related having changed
within the component's source repository.
Case in point is [RNG]: "mvn site:stage" doesn't work in "master"
for any version of CP. :-(

Gilles


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=1832339




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

Re: [COLLECTIONS] japicmp:cmp is always skipped

2018-09-20 Thread Gilles 

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. :-/

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

2018-09-20 Thread Gilles 

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]



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

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

2018-09-20 Thread Rory O'Donnell 

Hi Benedikt,

Can you log a bug and let me have the JI number ?

Thanks,Rory


On 20/09/2018 08: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:\Program Files\Java\jdk-11\bin\java"
-javaagent:C:\\Users\\ggregory\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.1\\org.jacoco.agent-0.8.1-runtime.jar=destfile=C:\\temp\\rc\\commons-csv-1.6-src\\target\\jacoco.exec
-jar
C:\Users\ggregory\AppData\Local\Temp\surefire8193357594532737911\surefirebooter4797436355437582319.jar
C:\Users\ggregory\AppData\Local\Temp\surefire8193357594532737911
2018-09-19T18-30-01_925-jvmRun1 surefire14765244413659300989tmp
surefire_06894247545608575344tmp"
[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\jdk-11\bin\java"
-javaagent:C:\\Users\\ggregory\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.1\\org.jacoco.agent-0.8.1-runtime.jar=destfile=C:\\temp\\rc\\commons-csv-1.6-src\\target\\jacoco.exec
-jar
C:\Users\ggregory\AppData\Local\Temp\surefire8193357594532737911\surefirebooter4797436355437582319.jar
C:\Users\ggregory\AppData\Local\Temp\surefire8193357594532737911
2018-09-19T18-30-01_925-jvmRun1 surefire14765244413659300989tmp
surefire_06894247545608575344tmp"
[ERROR] Error occurred in starting fork, check output in log
[ERROR] Process Exit Code: 1
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:671)
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:278)
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:244)
[ERROR] at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1194)
[ERROR] at

[COLLECTIONS] japicmp:cmp is always skipped

2018-09-20 Thread 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

[GitHub] commons-collections issue #54: Replace Clirr with japicmp, since clirr does ...

2018-09-20 Thread britter 
Github user britter commented on the issue:

https://github.com/apache/commons-collections/pull/54
  
The build produces:

```
[INFO] --- japicmp-maven-plugin:0.12.0:cmp (default-cli) @ 
commons-collections4 ---
[INFO] Skipping execution because parameter 'skip' was set to true.
```

And I don't understand why. When calling `mvn site`, the japicmp report is 
created. But the check goal is always skipped...


---

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

[GitHub] commons-collections pull request #54: Replace Clirr with japicmp, since clir...

2018-09-20 Thread britter 
GitHub user britter opened a pull request:

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

Replace Clirr with japicmp, since clirr does not handle Java 8 defaul…

…t methods

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/britter/commons-collections fix-broken-build

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-collections/pull/54.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #54


commit 9fdff0135e295d13d2ceca01bddd5dccb530722a
Author: Benedikt Ritter 
Date:   2018-09-20T07:27:01Z

Replace Clirr with japicmp, since clirr does not handle Java 8 default 
methods




---

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

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

2018-09-20 Thread Benedikt Ritter 
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:\Program Files\Java\jdk-11\bin\java"
-javaagent:C:\\Users\\ggregory\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.1\\org.jacoco.agent-0.8.1-runtime.jar=destfile=C:\\temp\\rc\\commons-csv-1.6-src\\target\\jacoco.exec
-jar
C:\Users\ggregory\AppData\Local\Temp\surefire8193357594532737911\surefirebooter4797436355437582319.jar
C:\Users\ggregory\AppData\Local\Temp\surefire8193357594532737911
2018-09-19T18-30-01_925-jvmRun1 surefire14765244413659300989tmp
surefire_06894247545608575344tmp"
[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\jdk-11\bin\java"
-javaagent:C:\\Users\\ggregory\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.1\\org.jacoco.agent-0.8.1-runtime.jar=destfile=C:\\temp\\rc\\commons-csv-1.6-src\\target\\jacoco.exec
-jar
C:\Users\ggregory\AppData\Local\Temp\surefire8193357594532737911\surefirebooter4797436355437582319.jar
C:\Users\ggregory\AppData\Local\Temp\surefire8193357594532737911
2018-09-19T18-30-01_925-jvmRun1 surefire14765244413659300989tmp
surefire_06894247545608575344tmp"
[ERROR] Error occurred in starting fork, check output in log
[ERROR] Process Exit Code: 1
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:671)
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:278)
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:244)
[ERROR] at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1194)
[ERROR] at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1022)
[ERROR] at

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

2018-09-20 Thread 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

2018-09-20 Thread 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 
> >> :
> >
> >>
> >>
> >>> 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=1833926
> <
> http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?r1=1833874=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>
>