[GitHub] commons-text issue #67: travis: remove travis profile from pom and use travi...

2017-10-01 Thread PascalSchumacher 
Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-text/pull/67
  
Seems to break coverall somehow. (By now there should have been an comment 
from the coveralls bot concerning code coverage,)


---

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

Re: [LOGGING] Release with Java 9 Module support

2017-10-01 Thread Stephen Colebourne 
On 1 October 2017 at 11:34, Stefan Bodewig  wrote:
> - only add the automatic module name to commons-logging and release api
> and adapter as they are.

Exactly. This is the right approach.
Stephen

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

Re: [LOGGING] Release with Java 9 Module support

2017-10-01 Thread Benedikt Ritter 


> Am 01.10.2017 um 19:00 schrieb Ralph Goers :
> 
> That isn’t what I suggested. Release all 3 but only turn commons-logging.jar 
> into a module.

Yes :o)

I’ll go ahead with this approach as soon as I find the time for it.

Cheers,
Benedikt

> 
> Ralph
> 
>> On Oct 1, 2017, at 1:25 AM, Benedikt Ritter  wrote:
>> 
>> Okay, so we agree to drop the api and adapters jars from the build and the
>> distribution? If that is the case, I think we are ready to release this.
>> 
>> Benedikt
>> 
>> Gary Gregory  schrieb am So. 1. Okt. 2017 um 03:39:
>> 
>>> On Sep 30, 2017 11:24, "Ralph Goers"  wrote:
>>> 
>>> Looking at the build script it appears that both the api and adapters
>>> modules contain a subset of what is in commons-logging.jar. I have no idea
>>> why this is but all three of them cannot be modularized. I would suggest
>>> only modularizing commons-logging.jar and ignoring the other two.
>>> 
>>> 
>>> Makes sense to me.
>>> 
>>> Gary
>>> 
>>> 
>>> Ralph
>>> 
 On Sep 30, 2017, at 1:28 AM, Benedikt Ritter  wrote:
 
 
> Am 26.09.2017 um 23:34 schrieb Stephen Colebourne >>> :
> 
> The contents of pom.xml look OK. I can't seem to browse to see if you
> changed anything else in that commit.
> 
> I would suggest being extra cautious when releasing, as a newer
> version of maven may have changed some of the config, and you don't
> want to release the two extra jars to maven central. (In fact, why not
> just delete their creation in pom.xml ?)
 
 They are part of our standard distribution (I don’t know why) [1]. In
>>> fact I saw commons-logging-api.jar fly by last time I build my Spring Boot
>>> project. So it seems that those additional artifacts are still in use.
 
 I don’t know how well this plays with Automatic-Module-Name. If I
>>> understand correctly only one jar can have org.apache.common.logging.
 
 Benedikt
 
 [1] http://commons.apache.org/proper/commons-logging/guide.
>>> html#Jars_Included_in_the_Standard_Distribution
 
> Stephen
> 
> On 26 September 2017 at 22:05, Benedikt Ritter 
>>> wrote:
>> 
>>> Am 26.09.2017 um 22:54 schrieb Stephen Colebourne <
>>> scolebou...@joda.org
 :
>>> 
>>> On 26 September 2017 at 18:48, Jörg Schaible 
>>> wrote:
 AFAICS we have only commons-logging. The other artifacts have not
>>> been part
 of any release in the last decade.
>>> 
>>> Simple then!
>> 
>> Please review revision 1809785. The build still creates all those jars,
>>> the Automatic-Module-Name header is added to commons-logging.jar
>>> MANIFEST.MF with value org.apache.commons.logging.
>> 
>> Regards,
>> Benedikt
>> 
>>> Stephen
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org
 
 
>>> 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


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

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

2017-10-01 Thread Jochen Wiedmann 
+1

On Sun, Oct 1, 2017 at 1:46 PM, Bruno P. Kinoshita
 wrote:
> Build passing OK with
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-11T05:41:47+13:00)Maven home: /opt/mavenJava version: 1.8.0_144, 
> vendor: Oracle CorporationJava home: /usr/lib/jvm/java-8-oracle/jreDefault 
> locale: en_US, platform encoding: UTF-8OS name: "linux", version: 
> "4.4.0-96-generic", arch: "amd64", family: "unix"
> and with
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-11T05:41:47+13:00)Maven home: /opt/mavenJava version: 1.7.0_80, 
> vendor: Oracle CorporationJava home: /usr/lib/jvm/java-7-oracle/jreDefault 
> locale: en_US, platform encoding: UTF-8OS name: "linux", version: 
> "4.4.0-96-generic", arch: "amd64", family: "unix"
> and with
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-11T05:41:47+13:00)Maven home: /opt/mavenJava version: 1.8.0, vendor: 
> IBM CorporationJava home: 
> /home/kinow/Development/java/ibm-java-x86_64-80/jreDefault locale: en_US, 
> platform encoding: UTF-8OS name: "linux", version: "4.4.0-96-generic", arch: 
> "amd64", family: "unix"
> Site looks good, with a trivial Checkstyle issue added in this release 
> (ByteOrderUtils.java, line 42 is missing a Javadoc comment), but no blocker 
> IMO. Other reports look good. There are some cobertura build errors in the 
> console with IBM JVM 8, but the reports still work fine, with no errors.
> Did not have time to check signatures. Everything else looking good.
> [ X ] +1 Release these artifacts
>
> Thanks for preparing this release.
> Bruno
>
>   From: Benedikt Ritter 
>  To: Commons Developers List 
>  Sent: Sunday, 1 October 2017 5:00 AM
>  Subject: [VOTE] Release Apache Commons IO 2.6 based on RC1
>
> Hello,
>
> we have fixed quite a few bugs and added some nice new features since Apache 
> Commons IO 2.5 was released, so I would like to release Apache Commons IO 2.6 
> based on RC1.
>
> Commons IO 2.6 RC1 is available for review here: 
> https://dist.apache.org/repos/dist/dev/commons/io/commons-io-2.6-RC1 (svn 
> revision 22054)
>
> The tag is here: 
> https://git-wip-us.apache.org/repos/asf?p=commons-io.git;a=tag;h=fabd0a40735c664d56f04915ea8d7efcdcff319b
>
> Commit ID the tag points at: 79e236e0508c43519a7ff7868e8d48883628b6e4
>
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecommons-1270
>
> These are the Maven artifacts and their hashes:
>
> /commons-io/commons-io/2.6/commons-io-2.6-test-sources.jar.asc
> (SHA1: 54c3042e2b950be96df68825e0889ba5b79189fb)
> /commons-io/commons-io/2.6/commons-io-2.6.pom.asc
> (SHA1: 988f223b4653ebfef0948480588269551cc0be20)
> /commons-io/commons-io/2.6/commons-io-2.6-tests.jar.asc
> (SHA1: f33d781c4094f9073f6f8e68177e2921eea9bef9)
> /commons-io/commons-io/2.6/commons-io-2.6.pom
> (SHA1: ecfafbe3b00367c7f5af85ce7b0d5280185b04bc)
> /commons-io/commons-io/2.6/commons-io-2.6.jar.asc
> (SHA1: 063958192131b0a9fde210b8689be6bb17e00cfa)
> /commons-io/commons-io/2.6/commons-io-2.6-test-sources.jar
> (SHA1: 4d3a2e96fc18e1b36072d95f0fe5ad619fdf0298)
> /commons-io/commons-io/2.6/commons-io-2.6-javadoc.jar
> (SHA1: c5c3a79a913d3a1b72269dafb50cadccff2a21f9)
> /commons-io/commons-io/2.6/commons-io-2.6-sources.jar
> (SHA1: 4bd49983c052672d77d0ae7b1acebcbf8d722b53)
> /commons-io/commons-io/2.6/commons-io-2.6-tests.jar
> (SHA1: c6779917952b18cf7de73d114b955528fc6efc95)
> /commons-io/commons-io/2.6/commons-io-2.6.jar
> (SHA1: 251d45c4adffe1ad8013be29e5d3d0642d7d25f1)
> /commons-io/commons-io/2.6/commons-io-2.6-javadoc.jar.asc
> (SHA1: 2e8f429f3465ee2c4d4a924f6c8baae6291f2edf)
> /commons-io/commons-io/2.6/commons-io-2.6-sources.jar.asc
> (SHA1: 26960e0113cf4621d0a4fec21dc358c231e5ae88)
>
> I have tested this with JDK 7, JDK 8 and JDK 9 using Maven 3.5.0.
>
> Details of changes since 2.5 are in the release notes:
>   
> https://dist.apache.org/repos/dist/dev/commons/io/commons-io-2.6-RC1/RELEASE-NOTES.txt
>   
> http://home.apache.org/~britter/commons/commons-io-2.6-RC1/changes-report.html
>
> Site:
>   http://home.apache.org/~britter/commons/commons-io-2.6-RC1/
> (note some *relative* links are broken and the 2.6 directories are not yet 
> created - these will be OK once the site is deployed)
>
> Clirr Report (compared to 2.5):
>   
> http://home.apache.org/~britter/commons/commons-io-2.6-RC1//clirr-report.html
>
> RAT Report:
>   http://home.apache.org/~britter/commons/commons-io-2.6-RC1/rat-report.html
>
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote. This vote will close no sooner 
> that 72 hours from now, i.e. sometime after 18:00 CEST (UTC+2) 03-October 2017
>
> [ ] +1 Release these artifacts
> [ ] +0 OK, but…
> [ ] -0 OK, but really should fix…
> [ ] -1 I oppose this release because...
>
> Thanks!
>
> Benedikt
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additi

Re: [LOGGING] Release with Java 9 Module support

2017-10-01 Thread Ralph Goers 

> On Oct 1, 2017, at 2:48 AM, sebb  wrote:
> 
> On 1 October 2017 at 10:08, Pascal Schumacher  > wrote:
>> Looks like commons-logging-api is used by some popular projects (Hibernate,
>> Hadoop, Camel):
>> 
>> http://www.mvnrepository.com/artifact/commons-logging/commons-logging-api/usages
>>  
>> 
>> 
>> but I guess they can easily switch to commons-logging.
> 
> Not sure I agree with that.
> 
> The purpose of the api jar is to define the API only without bringing
> in the rest of the code.
> Potentially having the implementation as well could cause issues.
> 
>> Commons-logging-adatper seem to be very rarely used:
>> 
>> http://www.mvnrepository.com/artifact/commons-logging/commons-logging-adapters/usages
>>  
>> 
>> 
>> As I understand it there is no other (realistic) choice than dropping the
>> api and the adpater jars, so +1 from me.
> 
> The split into API and implementation seems to me to be a
> well-established pattern, so if Maven or Java 9 cannot support that
> then it is Maven or Java 9 that needs to be fixed.

I would agree with you if commons-logging had done a proper job of splitting 
the api from the implementation. It did not. Everything is together in one 
source directory and the build picks and chooses what goes into each jar. Maven 
isn’t even in the picture here. If it was this probably would have been done 
properly. 

Java 9 isn’t going to be “fixed”. It simply does not allow classes in the same 
package to appear in more than one module. A proper separation of API from 
implementation would normally have put them in different packages.

Ralph

Re: [LOGGING] Release with Java 9 Module support

2017-10-01 Thread Ralph Goers 
That isn’t what I suggested. Release all 3 but only turn commons-logging.jar 
into a module.

Ralph

> On Oct 1, 2017, at 1:25 AM, Benedikt Ritter  wrote:
> 
> Okay, so we agree to drop the api and adapters jars from the build and the
> distribution? If that is the case, I think we are ready to release this.
> 
> Benedikt
> 
> Gary Gregory  schrieb am So. 1. Okt. 2017 um 03:39:
> 
>> On Sep 30, 2017 11:24, "Ralph Goers"  wrote:
>> 
>> Looking at the build script it appears that both the api and adapters
>> modules contain a subset of what is in commons-logging.jar. I have no idea
>> why this is but all three of them cannot be modularized. I would suggest
>> only modularizing commons-logging.jar and ignoring the other two.
>> 
>> 
>> Makes sense to me.
>> 
>> Gary
>> 
>> 
>> Ralph
>> 
>>> On Sep 30, 2017, at 1:28 AM, Benedikt Ritter  wrote:
>>> 
>>> 
 Am 26.09.2017 um 23:34 schrieb Stephen Colebourne >> :
 
 The contents of pom.xml look OK. I can't seem to browse to see if you
 changed anything else in that commit.
 
 I would suggest being extra cautious when releasing, as a newer
 version of maven may have changed some of the config, and you don't
 want to release the two extra jars to maven central. (In fact, why not
 just delete their creation in pom.xml ?)
>>> 
>>> They are part of our standard distribution (I don’t know why) [1]. In
>> fact I saw commons-logging-api.jar fly by last time I build my Spring Boot
>> project. So it seems that those additional artifacts are still in use.
>>> 
>>> I don’t know how well this plays with Automatic-Module-Name. If I
>> understand correctly only one jar can have org.apache.common.logging.
>>> 
>>> Benedikt
>>> 
>>> [1] http://commons.apache.org/proper/commons-logging/guide.
>> html#Jars_Included_in_the_Standard_Distribution
>>> 
 Stephen
 
 On 26 September 2017 at 22:05, Benedikt Ritter 
>> wrote:
> 
>> Am 26.09.2017 um 22:54 schrieb Stephen Colebourne <
>> scolebou...@joda.org
>>> :
>> 
>> On 26 September 2017 at 18:48, Jörg Schaible 
>> wrote:
>>> AFAICS we have only commons-logging. The other artifacts have not
>> been part
>>> of any release in the last decade.
>> 
>> Simple then!
> 
> Please review revision 1809785. The build still creates all those jars,
>> the Automatic-Module-Name header is added to commons-logging.jar
>> MANIFEST.MF with value org.apache.commons.logging.
> 
> Regards,
> Benedikt
> 
>> Stephen
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org
 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>> 
>>> 
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 



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

[GitHub] commons-text pull request #67: travis: remove travis profile from pom and us...

2017-10-01 Thread PascalSchumacher 
GitHub user PascalSchumacher opened a pull request:

https://github.com/apache/commons-text/pull/67

travis: remove travis profile from pom and use travis-jacoco profile …

…commons-parent

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

$ git pull https://github.com/PascalSchumacher/commons-text travis_profile

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

https://github.com/apache/commons-text/pull/67.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 #67


commit 15b200c60a4f17a6e6616e20265e2a8eee062607
Author: Pascal Schumacher 
Date:   2017-10-01T14:29:26Z

travis: remove travis profile from pom and use travis-jacoco profile 
commons-parent




---

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

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

2017-10-01 Thread Gary Gregory 
I also had not considered building on Java 9 since Java 9 has made such a
mess with backward compatibility and a lot of Maven plugins fail on Java 9.

Gary

On Oct 1, 2017 04:12, "Benedikt Ritter"  wrote:

> Hello Gary,
>
> - signatures are good
> - Release notes look good
> - Website looks good
>
> With Java 7 and Java 8 I get these test failures:
>
> Results :
>
> Failed tests:
>   ZipFileObjectTestCase.testReadingFilesInZipFile:98->readAndAssert:61
> zip:file:///var/folders/r3/mg882fyn5553f6wdhfb_6m7cgn/T/
> ZipFileObjectTestCase7763728418042728238.zip!/read-xml-tests/file1.xml
> expected:<..." encoding="UTF-8"?>[
> foo1]
> > but was:<..." encoding="UTF-8"?>[
> ]Root1>foo1
> >
>   
> ZipFileObjectTestCase.testReadingOneAfterClosingAnotherFile:133->readAndAssert:61
> zip:file:///var/folders/r3/mg882fyn5553f6wdhfb_6m7cgn/T/
> ZipFileObjectTestCase3559195487083894265.zip!/read-xml-tests/file1.xml
> expected:<..." encoding="UTF-8"?>[
> foo1]
> > but was:<..." encoding="UTF-8"?>[
> ]Root1>foo1
> >
>   ZipFileObjectTestCase.testReadingOneAfterClosingAnotherStream:155->
> resolveReadAssert:110->readAndAssert:61 zip:file:///var/folders/r3/
> mg882fyn5553f6wdhfb_6m7cgn/T/ZipFileObjectTestCase112008393
> 0847510889.zip!/read-xml-tests/file2.xml expected:<..."
> encoding="UTF-8"?>[
> foo2]
> > but was:<..." encoding="UTF-8"?>[
> ]Root2>foo2
> >
>
> Tests run: 2341, Failures: 3, Errors: 0, Skipped: 4
>
> On Java 9 I get four test errors in addition:
>
> Tests in error:
> org.apache.commons.vfs2.impl.test.VfsClassLoaderTests.
> testLoadClass(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests)
>   Run 1: PASS
>   Run 2: PASS
>   Run 3: PASS
>   Run 4: PASS
>   Run 5: PASS
>   Run 6: 
> VfsClassLoaderTests>AbstractProviderTestCase.runTest:190->testLoadClass:61
> » ClassNotFound
>   Run 7: 
> VfsClassLoaderTests>AbstractProviderTestCase.runTest:190->testLoadClass:61
> » ClassNotFound
>   Run 8: PASS
>   Run 9: PASS
>   Run 10: PASS
>   Run 11: PASS
>   Run 12: PASS
>   Run 13: PASS
>   Run 14: PASS
>   Run 15: PASS
>   Run 16: PASS
>   Run 17: PASS
>   Run 18: PASS
>   Run 19: PASS
>   Run 20: PASS
>   Run 21: PASS
>   Run 22: PASS
>   Run 23: PASS
>   Run 24: PASS
>   Run 25: PASS
>
> org.apache.commons.vfs2.impl.test.VfsClassLoaderTests.
> testSealing(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests)
>   Run 1: PASS
>   Run 2: PASS
>   Run 3: PASS
>   Run 4: PASS
>   Run 5: PASS
>   Run 6: 
> VfsClassLoaderTests>AbstractProviderTestCase.runTest:190->testSealing:88
> » ClassNotFound
>   Run 7: 
> VfsClassLoaderTests>AbstractProviderTestCase.runTest:190->testSealing:88
> » ClassNotFound
>   Run 8: PASS
>   Run 9: PASS
>   Run 10: PASS
>   Run 11: PASS
>   Run 12: PASS
>   Run 13: PASS
>   Run 14: PASS
>   Run 15: PASS
>   Run 16: PASS
>   Run 17: PASS
>   Run 18: PASS
>   Run 19: PASS
>   Run 20: PASS
>   Run 21: PASS
>   Run 22: PASS
>   Run 23: PASS
>   Run 24: PASS
>   Run 25: PASS
>
> org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTest.org.
> apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTest
>   Run 1: HdfsFileProviderTest.setUp:91 » ExceptionInInitializer
>   Run 2: HdfsFileProviderTest.tearDown:135 NullPointer
>
>   HdfsFileProviderTestCase$HdfsProviderTestSuite>
> AbstractTestSuite.run:137->setUp:98 » NoClassDefFound
>
> I building with:
>
> ~ > mvn -version
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
> MaxPermSize=128m; support was removed in 8.0
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
> 2017-04-03T21:39:06+02:00)
> Maven home: /usr/local/Cellar/maven/3.5.0/libexec
> Java version: 1.8.0_144, vendor: Oracle Corporation
> Java home: /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.12.6", arch: "x86_64", family: "mac"
>
> So I’m -1 on this release.
>
> Benedikt
>
> > Am 23.09.2017 um 18:43 schrieb Gary Gregory :
> >
> > We have fixed quite a few bugs and added some significant enhancements
> > since Apache Commons VFS 2.1 was released, so I would like to release
> > Apache Commons VFS 2.2.
> >
> > Apache Commons VFS 2.2 RC1 is available for review here:
> >https://dist.apache.org/repos/dist/dev/commons/vfs/ (svn revision
> 21925)
> >Get it: svn co https://dist.apache.org/repos/dist/dev/commons/vfs/
> >
> > The tag is here:
> >
> > https://svn.apache.org/repos/asf/commons/proper/vfs/tags/
> commons-vfs2-project-2.2-rc1/
> > (svn revision 1809435)
> >N.B. the SVN revision is required because SVN tags are not immutable.
> >Get it: svn co
> > https://svn.apache.org/repos/asf/commons/proper/vfs/tags/
> commons-vfs2-project-2.2-rc1/
> >
> > Maven artifacts are here:
> >
> > https://repository.apache.org/service/local/repositories/
> orgapachecommons-1268/content/org/apache/commons/commons-
> vfs2-distribution/2.2/
> >
> > These are the artifacts and their SHA1 hashes:
> >
> > /org/apache/commons/commons-vfs2-distrib

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

2017-10-01 Thread Gary Gregory 
As Pascal noted on this thread, these test failures happen only on
non-Windows systems and the tests have since been patched. I will wait
until tomorrow to consider canceling this vote as I am AFK until then.

Gary

On Oct 1, 2017 04:12, "Benedikt Ritter"  wrote:

Hello Gary,

- signatures are good
- Release notes look good
- Website looks good

With Java 7 and Java 8 I get these test failures:

Results :

Failed tests:
  ZipFileObjectTestCase.testReadingFilesInZipFile:98->readAndAssert:61
zip:file:///var/folders/r3/mg882fyn5553f6wdhfb_6m7cgn/T/
ZipFileObjectTestCase7763728418042728238.zip!/read-xml-tests/file1.xml
expected:<..." encoding="UTF-8"?>[
foo1]
> but was:<..." encoding="UTF-8"?>[
]Root1>foo1
>
  
ZipFileObjectTestCase.testReadingOneAfterClosingAnotherFile:133->readAndAssert:61
zip:file:///var/folders/r3/mg882fyn5553f6wdhfb_6m7cgn/T/
ZipFileObjectTestCase3559195487083894265.zip!/read-xml-tests/file1.xml
expected:<..." encoding="UTF-8"?>[
foo1]
> but was:<..." encoding="UTF-8"?>[
]Root1>foo1
>
  ZipFileObjectTestCase.testReadingOneAfterClosingAnotherStream:155->
resolveReadAssert:110->readAndAssert:61 zip:file:///var/folders/r3/
mg882fyn5553f6wdhfb_6m7cgn/T/ZipFileObjectTestCase112008393
0847510889.zip!/read-xml-tests/file2.xml expected:<..." encoding="UTF-8"?>[
foo2]
> but was:<..." encoding="UTF-8"?>[
]Root2>foo2
>

Tests run: 2341, Failures: 3, Errors: 0, Skipped: 4

On Java 9 I get four test errors in addition:

Tests in error:
org.apache.commons.vfs2.impl.test.VfsClassLoaderTests.
testLoadClass(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests)
  Run 1: PASS
  Run 2: PASS
  Run 3: PASS
  Run 4: PASS
  Run 5: PASS
  Run 6: 
VfsClassLoaderTests>AbstractProviderTestCase.runTest:190->testLoadClass:61
» ClassNotFound
  Run 7: 
VfsClassLoaderTests>AbstractProviderTestCase.runTest:190->testLoadClass:61
» ClassNotFound
  Run 8: PASS
  Run 9: PASS
  Run 10: PASS
  Run 11: PASS
  Run 12: PASS
  Run 13: PASS
  Run 14: PASS
  Run 15: PASS
  Run 16: PASS
  Run 17: PASS
  Run 18: PASS
  Run 19: PASS
  Run 20: PASS
  Run 21: PASS
  Run 22: PASS
  Run 23: PASS
  Run 24: PASS
  Run 25: PASS

org.apache.commons.vfs2.impl.test.VfsClassLoaderTests.
testSealing(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests)
  Run 1: PASS
  Run 2: PASS
  Run 3: PASS
  Run 4: PASS
  Run 5: PASS
  Run 6: 
VfsClassLoaderTests>AbstractProviderTestCase.runTest:190->testSealing:88
» ClassNotFound
  Run 7: 
VfsClassLoaderTests>AbstractProviderTestCase.runTest:190->testSealing:88
» ClassNotFound
  Run 8: PASS
  Run 9: PASS
  Run 10: PASS
  Run 11: PASS
  Run 12: PASS
  Run 13: PASS
  Run 14: PASS
  Run 15: PASS
  Run 16: PASS
  Run 17: PASS
  Run 18: PASS
  Run 19: PASS
  Run 20: PASS
  Run 21: PASS
  Run 22: PASS
  Run 23: PASS
  Run 24: PASS
  Run 25: PASS

org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTest.org.
apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTest
  Run 1: HdfsFileProviderTest.setUp:91 » ExceptionInInitializer
  Run 2: HdfsFileProviderTest.tearDown:135 NullPointer

  
HdfsFileProviderTestCase$HdfsProviderTestSuite>AbstractTestSuite.run:137->setUp:98
» NoClassDefFound

I building with:

~ > mvn -version
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
MaxPermSize=128m; support was removed in 8.0
Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T21:39:06+02:00)
Maven home: /usr/local/Cellar/maven/3.5.0/libexec
Java version: 1.8.0_144, vendor: Oracle Corporation
Java home: /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.12.6", arch: "x86_64", family: "mac"

So I’m -1 on this release.

Benedikt

> Am 23.09.2017 um 18:43 schrieb Gary Gregory :
>
> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons VFS 2.1 was released, so I would like to release
> Apache Commons VFS 2.2.
>
> Apache Commons VFS 2.2 RC1 is available for review here:
>https://dist.apache.org/repos/dist/dev/commons/vfs/ (svn revision
21925)
>Get it: svn co https://dist.apache.org/repos/dist/dev/commons/vfs/
>
> The tag is here:
>
> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/
commons-vfs2-project-2.2-rc1/
> (svn revision 1809435)
>N.B. the SVN revision is required because SVN tags are not immutable.
>Get it: svn co
> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/
commons-vfs2-project-2.2-rc1/
>
> Maven artifacts are here:
>
> https://repository.apache.org/service/local/repositories/
orgapachecommons-1268/content/org/apache/commons/commons-
vfs2-distribution/2.2/
>
> These are the artifacts and their SHA1 hashes:
>
> /org/apache/commons/commons-vfs2-distribution/2.2/commons-
vfs2-distribution-2.2-src.tar.gz
> (SHA1: 212a069b5b1534686b68fe35a6984920d9413fde)
> /org/apache/commons/commons-vfs2-distribution/2.2/commons-
vfs2-distribution-2.2-bin.zip.asc
> (SHA1: aac456496d4af37a1d1912b8348b4701cf337c85)
> /

Re: Support Percent-Encoding (described in RFC3986 and RFC7578)

2017-10-01 Thread Bruno P. Kinoshita 
Hi Giannis,
Had a quick look at the ticket, but with limited Internet I can't really 
thoroughly read and comment about it. Sometimes it may be easier to review a 
proposal for a new feature like yours if there is some code somewhere.
So if creating the pull request wouldn't take too long, it might be a good 
idea. So if you receive no replies here for a while, try replying to this 
thread with your pull request if you have prepared one.
As most Commons components are maintained by volunteers, sometimes it happens 
that they are busy with other components (or with life/work/etc), so it may - 
or may not - take a while to get a feedback on your proposal. Having the pull 
request may speed up things a bit.
Hope that helpsBruno

  From: Giannis Sermetziadis 
 To: dev@commons.apache.org 
 Sent: Saturday, 30 September 2017 9:31 AM
 Subject: Support Percent-Encoding (described in RFC3986 and RFC7578)
   
Hi there. I already created a Jira ticket for this (CODEC-240), but
then found the contribution instructions :)

My suggestion is to provide a codec that implements the
Percent-Encoding as defined in RFC3986 and RFC7578. This is similar to
URLCodec but does not force the ' ' to '+' encoding and others, but
follows the spec by encoding with what the spec defines only the
octets that are outside the allowed set of the encoding being used.

I can provide a pull-request, if you agree that this is useful.

Giannis

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

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

2017-10-01 Thread Bruno P. Kinoshita 
Build passing OK with
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
2015-11-11T05:41:47+13:00)Maven home: /opt/mavenJava version: 1.8.0_144, 
vendor: Oracle CorporationJava home: /usr/lib/jvm/java-8-oracle/jreDefault 
locale: en_US, platform encoding: UTF-8OS name: "linux", version: 
"4.4.0-96-generic", arch: "amd64", family: "unix"
and with
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
2015-11-11T05:41:47+13:00)Maven home: /opt/mavenJava version: 1.7.0_80, vendor: 
Oracle CorporationJava home: /usr/lib/jvm/java-7-oracle/jreDefault locale: 
en_US, platform encoding: UTF-8OS name: "linux", version: "4.4.0-96-generic", 
arch: "amd64", family: "unix"
and with
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
2015-11-11T05:41:47+13:00)Maven home: /opt/mavenJava version: 1.8.0, vendor: 
IBM CorporationJava home: 
/home/kinow/Development/java/ibm-java-x86_64-80/jreDefault locale: en_US, 
platform encoding: UTF-8OS name: "linux", version: "4.4.0-96-generic", arch: 
"amd64", family: "unix"
Site looks good, with a trivial Checkstyle issue added in this release 
(ByteOrderUtils.java, line 42 is missing a Javadoc comment), but no blocker 
IMO. Other reports look good. There are some cobertura build errors in the 
console with IBM JVM 8, but the reports still work fine, with no errors.
Did not have time to check signatures. Everything else looking good.
[ X ] +1 Release these artifacts

Thanks for preparing this release.
Bruno

  From: Benedikt Ritter 
 To: Commons Developers List  
 Sent: Sunday, 1 October 2017 5:00 AM
 Subject: [VOTE] Release Apache Commons IO 2.6 based on RC1
   
Hello,

we have fixed quite a few bugs and added some nice new features since Apache 
Commons IO 2.5 was released, so I would like to release Apache Commons IO 2.6 
based on RC1.

Commons IO 2.6 RC1 is available for review here: 
https://dist.apache.org/repos/dist/dev/commons/io/commons-io-2.6-RC1 (svn 
revision 22054)

The tag is here: 
https://git-wip-us.apache.org/repos/asf?p=commons-io.git;a=tag;h=fabd0a40735c664d56f04915ea8d7efcdcff319b

Commit ID the tag points at: 79e236e0508c43519a7ff7868e8d48883628b6e4

Maven Artifacts: 
https://repository.apache.org/content/repositories/orgapachecommons-1270

These are the Maven artifacts and their hashes:

/commons-io/commons-io/2.6/commons-io-2.6-test-sources.jar.asc
(SHA1: 54c3042e2b950be96df68825e0889ba5b79189fb)
/commons-io/commons-io/2.6/commons-io-2.6.pom.asc
(SHA1: 988f223b4653ebfef0948480588269551cc0be20)
/commons-io/commons-io/2.6/commons-io-2.6-tests.jar.asc
(SHA1: f33d781c4094f9073f6f8e68177e2921eea9bef9)
/commons-io/commons-io/2.6/commons-io-2.6.pom
(SHA1: ecfafbe3b00367c7f5af85ce7b0d5280185b04bc)
/commons-io/commons-io/2.6/commons-io-2.6.jar.asc
(SHA1: 063958192131b0a9fde210b8689be6bb17e00cfa)
/commons-io/commons-io/2.6/commons-io-2.6-test-sources.jar
(SHA1: 4d3a2e96fc18e1b36072d95f0fe5ad619fdf0298)
/commons-io/commons-io/2.6/commons-io-2.6-javadoc.jar
(SHA1: c5c3a79a913d3a1b72269dafb50cadccff2a21f9)
/commons-io/commons-io/2.6/commons-io-2.6-sources.jar
(SHA1: 4bd49983c052672d77d0ae7b1acebcbf8d722b53)
/commons-io/commons-io/2.6/commons-io-2.6-tests.jar
(SHA1: c6779917952b18cf7de73d114b955528fc6efc95)
/commons-io/commons-io/2.6/commons-io-2.6.jar
(SHA1: 251d45c4adffe1ad8013be29e5d3d0642d7d25f1)
/commons-io/commons-io/2.6/commons-io-2.6-javadoc.jar.asc
(SHA1: 2e8f429f3465ee2c4d4a924f6c8baae6291f2edf)
/commons-io/commons-io/2.6/commons-io-2.6-sources.jar.asc
(SHA1: 26960e0113cf4621d0a4fec21dc358c231e5ae88)

I have tested this with JDK 7, JDK 8 and JDK 9 using Maven 3.5.0.

Details of changes since 2.5 are in the release notes:
  
https://dist.apache.org/repos/dist/dev/commons/io/commons-io-2.6-RC1/RELEASE-NOTES.txt
  http://home.apache.org/~britter/commons/commons-io-2.6-RC1/changes-report.html

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

Clirr Report (compared to 2.5):
  http://home.apache.org/~britter/commons/commons-io-2.6-RC1//clirr-report.html

RAT Report:
  http://home.apache.org/~britter/commons/commons-io-2.6-RC1/rat-report.html

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

Please review the release candidate and vote. This vote will close no sooner 
that 72 hours from now, i.e. sometime after 18:00 CEST (UTC+2) 03-October 2017

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

Thanks!

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

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

2017-10-01 Thread Pascal Schumacher 

Sorry, the md5/sha1 output part should be:

>md5sum -c commons-io-2.6-src.zip.md5
md5sum: commons-io-2.6-src.zip.md5: no properly formatted MD5 checksum 
lines found


>sha1sum -c commons-io-2.6-src.zip.sha1
sha1sum: commons-io-2.6-src.zip.sha1: no properly formatted SHA1 
checksum lines found


Am 01.10.2017 um 12:54 schrieb Pascal Schumacher:

+1

Build (mvn test apache-rat:check clirr:check javadoc:javadoc) from zip 
and tar.gz successful.


One checkstyle error.

Three findbugs errors, two look like they were already part of 
previous versions.


PGP Signature checks successful.

I was not able to check md5 and sha1 (probably doing it wrong):

>sha1sum -c commons-io-2.6-src.zip.md5
sha1sum: commons-io-2.6-src.zip.md5: no properly formatted SHA1 
checksum lines found


>sha1sum -c commons-io-2.6-src.zip.sha1
sha1sum: commons-io-2.6-src.zip.sha1: no properly formatted SHA1 
checksum lines found


Thanks,
Pascal

Am 30.09.2017 um 18:00 schrieb Benedikt Ritter:

Hello,

we have fixed quite a few bugs and added some nice new features since 
Apache Commons IO 2.5 was released, so I would like to release Apache 
Commons IO 2.6 based on RC1.


Commons IO 2.6 RC1 is available for review 
here:https://dist.apache.org/repos/dist/dev/commons/io/commons-io-2.6-RC1 
(svn revision 22054)


The tag is 
here:https://git-wip-us.apache.org/repos/asf?p=commons-io.git;a=tag;h=fabd0a40735c664d56f04915ea8d7efcdcff319b


Commit ID the tag points at: 79e236e0508c43519a7ff7868e8d48883628b6e4

Maven 
Artifacts:https://repository.apache.org/content/repositories/orgapachecommons-1270


These are the Maven artifacts and their hashes:

/commons-io/commons-io/2.6/commons-io-2.6-test-sources.jar.asc
(SHA1: 54c3042e2b950be96df68825e0889ba5b79189fb)
/commons-io/commons-io/2.6/commons-io-2.6.pom.asc
(SHA1: 988f223b4653ebfef0948480588269551cc0be20)
/commons-io/commons-io/2.6/commons-io-2.6-tests.jar.asc
(SHA1: f33d781c4094f9073f6f8e68177e2921eea9bef9)
/commons-io/commons-io/2.6/commons-io-2.6.pom
(SHA1: ecfafbe3b00367c7f5af85ce7b0d5280185b04bc)
/commons-io/commons-io/2.6/commons-io-2.6.jar.asc
(SHA1: 063958192131b0a9fde210b8689be6bb17e00cfa)
/commons-io/commons-io/2.6/commons-io-2.6-test-sources.jar
(SHA1: 4d3a2e96fc18e1b36072d95f0fe5ad619fdf0298)
/commons-io/commons-io/2.6/commons-io-2.6-javadoc.jar
(SHA1: c5c3a79a913d3a1b72269dafb50cadccff2a21f9)
/commons-io/commons-io/2.6/commons-io-2.6-sources.jar
(SHA1: 4bd49983c052672d77d0ae7b1acebcbf8d722b53)
/commons-io/commons-io/2.6/commons-io-2.6-tests.jar
(SHA1: c6779917952b18cf7de73d114b955528fc6efc95)
/commons-io/commons-io/2.6/commons-io-2.6.jar
(SHA1: 251d45c4adffe1ad8013be29e5d3d0642d7d25f1)
/commons-io/commons-io/2.6/commons-io-2.6-javadoc.jar.asc
(SHA1: 2e8f429f3465ee2c4d4a924f6c8baae6291f2edf)
/commons-io/commons-io/2.6/commons-io-2.6-sources.jar.asc
(SHA1: 26960e0113cf4621d0a4fec21dc358c231e5ae88)

I have tested this with JDK 7, JDK 8 and JDK 9 using Maven 3.5.0.

Details of changes since 2.5 are in the release notes:
https://dist.apache.org/repos/dist/dev/commons/io/commons-io-2.6-RC1/RELEASE-NOTES.txt
http://home.apache.org/~britter/commons/commons-io-2.6-RC1/changes-report.html

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


Clirr Report (compared to 2.5):
http://home.apache.org/~britter/commons/commons-io-2.6-RC1//clirr-report.html

RAT Report:
http://home.apache.org/~britter/commons/commons-io-2.6-RC1/rat-report.html

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

Please review the release candidate and vote. This vote will close no 
sooner that 72 hours from now, i.e. sometime after 18:00 CEST (UTC+2) 
03-October 2017


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

Thanks!

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







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

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

2017-10-01 Thread Pascal Schumacher 

+1

Build (mvn test apache-rat:check clirr:check javadoc:javadoc) from zip 
and tar.gz successful.


One checkstyle error.

Three findbugs errors, two look like they were already part of previous 
versions.


PGP Signature checks successful.

I was not able to check md5 and sha1 (probably doing it wrong):

>sha1sum -c commons-io-2.6-src.zip.md5
sha1sum: commons-io-2.6-src.zip.md5: no properly formatted SHA1 checksum 
lines found


>sha1sum -c commons-io-2.6-src.zip.sha1
sha1sum: commons-io-2.6-src.zip.sha1: no properly formatted SHA1 
checksum lines found


Thanks,
Pascal

Am 30.09.2017 um 18:00 schrieb Benedikt Ritter:

Hello,

we have fixed quite a few bugs and added some nice new features since Apache 
Commons IO 2.5 was released, so I would like to release Apache Commons IO 2.6 
based on RC1.

Commons IO 2.6 RC1 is available for review 
here:https://dist.apache.org/repos/dist/dev/commons/io/commons-io-2.6-RC1  (svn 
revision 22054)

The tag is 
here:https://git-wip-us.apache.org/repos/asf?p=commons-io.git;a=tag;h=fabd0a40735c664d56f04915ea8d7efcdcff319b

Commit ID the tag points at: 79e236e0508c43519a7ff7868e8d48883628b6e4

Maven 
Artifacts:https://repository.apache.org/content/repositories/orgapachecommons-1270

These are the Maven artifacts and their hashes:

/commons-io/commons-io/2.6/commons-io-2.6-test-sources.jar.asc
(SHA1: 54c3042e2b950be96df68825e0889ba5b79189fb)
/commons-io/commons-io/2.6/commons-io-2.6.pom.asc
(SHA1: 988f223b4653ebfef0948480588269551cc0be20)
/commons-io/commons-io/2.6/commons-io-2.6-tests.jar.asc
(SHA1: f33d781c4094f9073f6f8e68177e2921eea9bef9)
/commons-io/commons-io/2.6/commons-io-2.6.pom
(SHA1: ecfafbe3b00367c7f5af85ce7b0d5280185b04bc)
/commons-io/commons-io/2.6/commons-io-2.6.jar.asc
(SHA1: 063958192131b0a9fde210b8689be6bb17e00cfa)
/commons-io/commons-io/2.6/commons-io-2.6-test-sources.jar
(SHA1: 4d3a2e96fc18e1b36072d95f0fe5ad619fdf0298)
/commons-io/commons-io/2.6/commons-io-2.6-javadoc.jar
(SHA1: c5c3a79a913d3a1b72269dafb50cadccff2a21f9)
/commons-io/commons-io/2.6/commons-io-2.6-sources.jar
(SHA1: 4bd49983c052672d77d0ae7b1acebcbf8d722b53)
/commons-io/commons-io/2.6/commons-io-2.6-tests.jar
(SHA1: c6779917952b18cf7de73d114b955528fc6efc95)
/commons-io/commons-io/2.6/commons-io-2.6.jar
(SHA1: 251d45c4adffe1ad8013be29e5d3d0642d7d25f1)
/commons-io/commons-io/2.6/commons-io-2.6-javadoc.jar.asc
(SHA1: 2e8f429f3465ee2c4d4a924f6c8baae6291f2edf)
/commons-io/commons-io/2.6/commons-io-2.6-sources.jar.asc
(SHA1: 26960e0113cf4621d0a4fec21dc358c231e5ae88)

I have tested this with JDK 7, JDK 8 and JDK 9 using Maven 3.5.0.

Details of changes since 2.5 are in the release notes:
   
https://dist.apache.org/repos/dist/dev/commons/io/commons-io-2.6-RC1/RELEASE-NOTES.txt
   
http://home.apache.org/~britter/commons/commons-io-2.6-RC1/changes-report.html

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


Clirr Report (compared to 2.5):
   http://home.apache.org/~britter/commons/commons-io-2.6-RC1//clirr-report.html

RAT Report:
   http://home.apache.org/~britter/commons/commons-io-2.6-RC1/rat-report.html

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

Please review the release candidate and vote. This vote will close no sooner 
that 72 hours from now, i.e. sometime after 18:00 CEST (UTC+2) 03-October 2017

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

Thanks!

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

Re: [LOGGING] Release with Java 9 Module support

2017-10-01 Thread Stefan Bodewig 
On 2017-10-01, Benedikt Ritter wrote:

> So what options are we left with?
> - Do nothing -> logging can’t be used as a Java 9 module
> - Drop api and adapters -> users have to change their dependencies and get 
> more code than they want

- only add the automatic module name to commons-logging and release api
and adapter as they are.

I think that's been suggested before. That way people who want to
consume logging as a Java9 module can do so (and maybe need to adapt
their dependency) while all others can keep doing what they've done
before.

Stefan

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

Re: [LOGGING] Release with Java 9 Module support

2017-10-01 Thread Benedikt Ritter 

> Am 01.10.2017 um 11:48 schrieb sebb :
> 
> On 1 October 2017 at 10:08, Pascal Schumacher  
> wrote:
>> Looks like commons-logging-api is used by some popular projects (Hibernate,
>> Hadoop, Camel):
>> 
>> http://www.mvnrepository.com/artifact/commons-logging/commons-logging-api/usages
>> 
>> but I guess they can easily switch to commons-logging.
> 
> Not sure I agree with that.
> 
> The purpose of the api jar is to define the API only without bringing
> in the rest of the code.
> Potentially having the implementation as well could cause issues.
> 
>> Commons-logging-adatper seem to be very rarely used:
>> 
>> http://www.mvnrepository.com/artifact/commons-logging/commons-logging-adapters/usages
>> 
>> As I understand it there is no other (realistic) choice than dropping the
>> api and the adpater jars, so +1 from me.
> 
> The split into API and implementation seems to me to be a
> well-established pattern, so if Maven or Java 9 cannot support that
> then it is Maven or Java 9 that needs to be fixed.

I don’t think that is going to happen :-)

So what options are we left with?
- Do nothing -> logging can’t be used as a Java 9 module
- Drop api and adapters -> users have to change their dependencies and get more 
code than they want

Anything else?

Benedikt

> 
>> Cheers,
>> Pascal
>> 
>> 
>> Am 01.10.2017 um 10:25 schrieb Benedikt Ritter:
>>> 
>>> Okay, so we agree to drop the api and adapters jars from the build and the
>>> distribution? If that is the case, I think we are ready to release this.
>>> 
>>> Benedikt
>>> 
>>> Gary Gregory  schrieb am So. 1. Okt. 2017 um
>>> 03:39:
>>> 
 On Sep 30, 2017 11:24, "Ralph Goers"  wrote:
 
 Looking at the build script it appears that both the api and adapters
 modules contain a subset of what is in commons-logging.jar. I have no
 idea
 why this is but all three of them cannot be modularized. I would suggest
 only modularizing commons-logging.jar and ignoring the other two.
 
 
 Makes sense to me.
 
 Gary
 
 
 Ralph
 
> On Sep 30, 2017, at 1:28 AM, Benedikt Ritter  wrote:
> 
> 
>> Am 26.09.2017 um 23:34 schrieb Stephen Colebourne  
> :
>> 
>> The contents of pom.xml look OK. I can't seem to browse to see if you
>> changed anything else in that commit.
>> 
>> I would suggest being extra cautious when releasing, as a newer
>> version of maven may have changed some of the config, and you don't
>> want to release the two extra jars to maven central. (In fact, why not
>> just delete their creation in pom.xml ?)
> 
> They are part of our standard distribution (I don’t know why) [1]. In
 
 fact I saw commons-logging-api.jar fly by last time I build my Spring
 Boot
 project. So it seems that those additional artifacts are still in use.
> 
> I don’t know how well this plays with Automatic-Module-Name. If I
 
 understand correctly only one jar can have org.apache.common.logging.
> 
> Benedikt
> 
> [1] http://commons.apache.org/proper/commons-logging/guide.
 
 html#Jars_Included_in_the_Standard_Distribution
>> 
>> Stephen
>> 
>> On 26 September 2017 at 22:05, Benedikt Ritter 
 
 wrote:
 
 Am 26.09.2017 um 22:54 schrieb Stephen Colebourne <
 
 scolebou...@joda.org
> 
> :
 
 On 26 September 2017 at 18:48, Jörg Schaible 
 
 wrote:
> 
> AFAICS we have only commons-logging. The other artifacts have not
 
 been part
> 
> of any release in the last decade.
 
 Simple then!
>>> 
>>> Please review revision 1809785. The build still creates all those
>>> jars,
 
 the Automatic-Module-Name header is added to commons-logging.jar
 MANIFEST.MF with value org.apache.commons.logging.
>>> 
>>> Regards,
>>> Benedikt
>>> 
 Stephen
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org
 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 
 
 
 -
 To unsubscribe,

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

2017-10-01 Thread Benedikt Ritter 
Hello Gary,

- signatures are good
- Release notes look good
- Website looks good

With Java 7 and Java 8 I get these test failures:

Results :

Failed tests:
  ZipFileObjectTestCase.testReadingFilesInZipFile:98->readAndAssert:61 
zip:file:///var/folders/r3/mg882fyn5553f6wdhfb_6m7cgn/T/ZipFileObjectTestCase7763728418042728238.zip!/read-xml-tests/file1.xml
 expected:<..." encoding="UTF-8"?>[
foo1]
> but was:<..." encoding="UTF-8"?>[
]Root1>foo1
>
  
ZipFileObjectTestCase.testReadingOneAfterClosingAnotherFile:133->readAndAssert:61
 
zip:file:///var/folders/r3/mg882fyn5553f6wdhfb_6m7cgn/T/ZipFileObjectTestCase3559195487083894265.zip!/read-xml-tests/file1.xml
 expected:<..." encoding="UTF-8"?>[
foo1]
> but was:<..." encoding="UTF-8"?>[
]Root1>foo1
>
  
ZipFileObjectTestCase.testReadingOneAfterClosingAnotherStream:155->resolveReadAssert:110->readAndAssert:61
 
zip:file:///var/folders/r3/mg882fyn5553f6wdhfb_6m7cgn/T/ZipFileObjectTestCase1120083930847510889.zip!/read-xml-tests/file2.xml
 expected:<..." encoding="UTF-8"?>[
foo2]
> but was:<..." encoding="UTF-8"?>[
]Root2>foo2
>

Tests run: 2341, Failures: 3, Errors: 0, Skipped: 4

On Java 9 I get four test errors in addition:

Tests in error:
org.apache.commons.vfs2.impl.test.VfsClassLoaderTests.testLoadClass(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests)
  Run 1: PASS
  Run 2: PASS
  Run 3: PASS
  Run 4: PASS
  Run 5: PASS
  Run 6: 
VfsClassLoaderTests>AbstractProviderTestCase.runTest:190->testLoadClass:61 » 
ClassNotFound
  Run 7: 
VfsClassLoaderTests>AbstractProviderTestCase.runTest:190->testLoadClass:61 » 
ClassNotFound
  Run 8: PASS
  Run 9: PASS
  Run 10: PASS
  Run 11: PASS
  Run 12: PASS
  Run 13: PASS
  Run 14: PASS
  Run 15: PASS
  Run 16: PASS
  Run 17: PASS
  Run 18: PASS
  Run 19: PASS
  Run 20: PASS
  Run 21: PASS
  Run 22: PASS
  Run 23: PASS
  Run 24: PASS
  Run 25: PASS

org.apache.commons.vfs2.impl.test.VfsClassLoaderTests.testSealing(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests)
  Run 1: PASS
  Run 2: PASS
  Run 3: PASS
  Run 4: PASS
  Run 5: PASS
  Run 6: 
VfsClassLoaderTests>AbstractProviderTestCase.runTest:190->testSealing:88 » 
ClassNotFound
  Run 7: 
VfsClassLoaderTests>AbstractProviderTestCase.runTest:190->testSealing:88 » 
ClassNotFound
  Run 8: PASS
  Run 9: PASS
  Run 10: PASS
  Run 11: PASS
  Run 12: PASS
  Run 13: PASS
  Run 14: PASS
  Run 15: PASS
  Run 16: PASS
  Run 17: PASS
  Run 18: PASS
  Run 19: PASS
  Run 20: PASS
  Run 21: PASS
  Run 22: PASS
  Run 23: PASS
  Run 24: PASS
  Run 25: PASS

org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTest.org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTest
  Run 1: HdfsFileProviderTest.setUp:91 » ExceptionInInitializer
  Run 2: HdfsFileProviderTest.tearDown:135 NullPointer

  
HdfsFileProviderTestCase$HdfsProviderTestSuite>AbstractTestSuite.run:137->setUp:98
 » NoClassDefFound

I building with:

~ > mvn -version
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=128m; 
support was removed in 8.0
Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 
2017-04-03T21:39:06+02:00)
Maven home: /usr/local/Cellar/maven/3.5.0/libexec
Java version: 1.8.0_144, vendor: Oracle Corporation
Java home: /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.12.6", arch: "x86_64", family: "mac"

So I’m -1 on this release.

Benedikt

> Am 23.09.2017 um 18:43 schrieb Gary Gregory :
> 
> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons VFS 2.1 was released, so I would like to release
> Apache Commons VFS 2.2.
> 
> Apache Commons VFS 2.2 RC1 is available for review here:
>https://dist.apache.org/repos/dist/dev/commons/vfs/ (svn revision 21925)
>Get it: svn co https://dist.apache.org/repos/dist/dev/commons/vfs/
> 
> The tag is here:
> 
> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.2-rc1/
> (svn revision 1809435)
>N.B. the SVN revision is required because SVN tags are not immutable.
>Get it: svn co
> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.2-rc1/
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/service/local/repositories/orgapachecommons-1268/content/org/apache/commons/commons-vfs2-distribution/2.2/
> 
> These are the artifacts and their SHA1 hashes:
> 
> /org/apache/commons/commons-vfs2-distribution/2.2/commons-vfs2-distribution-2.2-src.tar.gz
> (SHA1: 212a069b5b1534686b68fe35a6984920d9413fde)
> /org/apache/commons/commons-vfs2-distribution/2.2/commons-vfs2-distribution-2.2-bin.zip.asc
> (SHA1: aac456496d4af37a1d1912b8348b4701cf337c85)
> /org/apache/commons/commons-vfs2-distribution/2.2/commons-vfs2-distribution-2.2.pom
> (SHA1: d8053a146c0d7e4b9cf649e8d6a0aff680dc3946)
> /org/apache/commons/commons-vfs2-distribution/2.2/commons-vfs2-distribution-2.2-src.zip.asc
> (SHA1: dbdddf332fc7929672c

Re: [LOGGING] Release with Java 9 Module support

2017-10-01 Thread sebb 
On 1 October 2017 at 10:08, Pascal Schumacher  wrote:
> Looks like commons-logging-api is used by some popular projects (Hibernate,
> Hadoop, Camel):
>
> http://www.mvnrepository.com/artifact/commons-logging/commons-logging-api/usages
>
> but I guess they can easily switch to commons-logging.

Not sure I agree with that.

The purpose of the api jar is to define the API only without bringing
in the rest of the code.
Potentially having the implementation as well could cause issues.

> Commons-logging-adatper seem to be very rarely used:
>
> http://www.mvnrepository.com/artifact/commons-logging/commons-logging-adapters/usages
>
> As I understand it there is no other (realistic) choice than dropping the
> api and the adpater jars, so +1 from me.

The split into API and implementation seems to me to be a
well-established pattern, so if Maven or Java 9 cannot support that
then it is Maven or Java 9 that needs to be fixed.

> Cheers,
> Pascal
>
>
> Am 01.10.2017 um 10:25 schrieb Benedikt Ritter:
>>
>> Okay, so we agree to drop the api and adapters jars from the build and the
>> distribution? If that is the case, I think we are ready to release this.
>>
>> Benedikt
>>
>> Gary Gregory  schrieb am So. 1. Okt. 2017 um
>> 03:39:
>>
>>> On Sep 30, 2017 11:24, "Ralph Goers"  wrote:
>>>
>>> Looking at the build script it appears that both the api and adapters
>>> modules contain a subset of what is in commons-logging.jar. I have no
>>> idea
>>> why this is but all three of them cannot be modularized. I would suggest
>>> only modularizing commons-logging.jar and ignoring the other two.
>>>
>>>
>>> Makes sense to me.
>>>
>>> Gary
>>>
>>>
>>> Ralph
>>>
 On Sep 30, 2017, at 1:28 AM, Benedikt Ritter  wrote:


> Am 26.09.2017 um 23:34 schrieb Stephen Colebourne >>>
 :
>
> The contents of pom.xml look OK. I can't seem to browse to see if you
> changed anything else in that commit.
>
> I would suggest being extra cautious when releasing, as a newer
> version of maven may have changed some of the config, and you don't
> want to release the two extra jars to maven central. (In fact, why not
> just delete their creation in pom.xml ?)

 They are part of our standard distribution (I don’t know why) [1]. In
>>>
>>> fact I saw commons-logging-api.jar fly by last time I build my Spring
>>> Boot
>>> project. So it seems that those additional artifacts are still in use.

 I don’t know how well this plays with Automatic-Module-Name. If I
>>>
>>> understand correctly only one jar can have org.apache.common.logging.

 Benedikt

 [1] http://commons.apache.org/proper/commons-logging/guide.
>>>
>>> html#Jars_Included_in_the_Standard_Distribution
>
> Stephen
>
> On 26 September 2017 at 22:05, Benedikt Ritter 
>>>
>>> wrote:
>>>
>>> Am 26.09.2017 um 22:54 schrieb Stephen Colebourne <
>>>
>>> scolebou...@joda.org

 :
>>>
>>> On 26 September 2017 at 18:48, Jörg Schaible 
>>>
>>> wrote:

 AFAICS we have only commons-logging. The other artifacts have not
>>>
>>> been part

 of any release in the last decade.
>>>
>>> Simple then!
>>
>> Please review revision 1809785. The build still creates all those
>> jars,
>>>
>>> the Automatic-Module-Name header is added to commons-logging.jar
>>> MANIFEST.MF with value org.apache.commons.logging.
>>
>> Regards,
>> Benedikt
>>
>>> Stephen
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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


>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>
>
> -
> 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: [LOGGING] Release with Java 9 Module support

2017-10-01 Thread Pascal Schumacher 
Looks like commons-logging-api is used by some popular projects 
(Hibernate, Hadoop, Camel):


http://www.mvnrepository.com/artifact/commons-logging/commons-logging-api/usages

but I guess they can easily switch to commons-logging.

Commons-logging-adatper seem to be very rarely used:

http://www.mvnrepository.com/artifact/commons-logging/commons-logging-adapters/usages

As I understand it there is no other (realistic) choice than dropping 
the api and the adpater jars, so +1 from me.


Cheers,
Pascal

Am 01.10.2017 um 10:25 schrieb Benedikt Ritter:

Okay, so we agree to drop the api and adapters jars from the build and the
distribution? If that is the case, I think we are ready to release this.

Benedikt

Gary Gregory  schrieb am So. 1. Okt. 2017 um 03:39:


On Sep 30, 2017 11:24, "Ralph Goers"  wrote:

Looking at the build script it appears that both the api and adapters
modules contain a subset of what is in commons-logging.jar. I have no idea
why this is but all three of them cannot be modularized. I would suggest
only modularizing commons-logging.jar and ignoring the other two.


Makes sense to me.

Gary


Ralph


On Sep 30, 2017, at 1:28 AM, Benedikt Ritter  wrote:



Am 26.09.2017 um 23:34 schrieb Stephen Colebourne 
:

The contents of pom.xml look OK. I can't seem to browse to see if you
changed anything else in that commit.

I would suggest being extra cautious when releasing, as a newer
version of maven may have changed some of the config, and you don't
want to release the two extra jars to maven central. (In fact, why not
just delete their creation in pom.xml ?)

They are part of our standard distribution (I don’t know why) [1]. In

fact I saw commons-logging-api.jar fly by last time I build my Spring Boot
project. So it seems that those additional artifacts are still in use.

I don’t know how well this plays with Automatic-Module-Name. If I

understand correctly only one jar can have org.apache.common.logging.

Benedikt

[1] http://commons.apache.org/proper/commons-logging/guide.

html#Jars_Included_in_the_Standard_Distribution

Stephen

On 26 September 2017 at 22:05, Benedikt Ritter 

wrote:

Am 26.09.2017 um 22:54 schrieb Stephen Colebourne <

scolebou...@joda.org

:

On 26 September 2017 at 18:48, Jörg Schaible 

wrote:

AFAICS we have only commons-logging. The other artifacts have not

been part

of any release in the last decade.

Simple then!

Please review revision 1809785. The build still creates all those jars,

the Automatic-Module-Name header is added to commons-logging.jar
MANIFEST.MF with value org.apache.commons.logging.

Regards,
Benedikt


Stephen

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



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


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



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





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




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

Re: [LOGGING] Release with Java 9 Module support

2017-10-01 Thread Benedikt Ritter 
Okay, so we agree to drop the api and adapters jars from the build and the
distribution? If that is the case, I think we are ready to release this.

Benedikt

Gary Gregory  schrieb am So. 1. Okt. 2017 um 03:39:

> On Sep 30, 2017 11:24, "Ralph Goers"  wrote:
>
> Looking at the build script it appears that both the api and adapters
> modules contain a subset of what is in commons-logging.jar. I have no idea
> why this is but all three of them cannot be modularized. I would suggest
> only modularizing commons-logging.jar and ignoring the other two.
>
>
> Makes sense to me.
>
> Gary
>
>
> Ralph
>
> > On Sep 30, 2017, at 1:28 AM, Benedikt Ritter  wrote:
> >
> >
> >> Am 26.09.2017 um 23:34 schrieb Stephen Colebourne  >:
> >>
> >> The contents of pom.xml look OK. I can't seem to browse to see if you
> >> changed anything else in that commit.
> >>
> >> I would suggest being extra cautious when releasing, as a newer
> >> version of maven may have changed some of the config, and you don't
> >> want to release the two extra jars to maven central. (In fact, why not
> >> just delete their creation in pom.xml ?)
> >
> > They are part of our standard distribution (I don’t know why) [1]. In
> fact I saw commons-logging-api.jar fly by last time I build my Spring Boot
> project. So it seems that those additional artifacts are still in use.
> >
> > I don’t know how well this plays with Automatic-Module-Name. If I
> understand correctly only one jar can have org.apache.common.logging.
> >
> > Benedikt
> >
> > [1] http://commons.apache.org/proper/commons-logging/guide.
> html#Jars_Included_in_the_Standard_Distribution
> >
> >> Stephen
> >>
> >> On 26 September 2017 at 22:05, Benedikt Ritter 
> wrote:
> >>>
>  Am 26.09.2017 um 22:54 schrieb Stephen Colebourne <
> scolebou...@joda.org
> >:
> 
>  On 26 September 2017 at 18:48, Jörg Schaible 
> wrote:
> > AFAICS we have only commons-logging. The other artifacts have not
> been part
> > of any release in the last decade.
> 
>  Simple then!
> >>>
> >>> Please review revision 1809785. The build still creates all those jars,
> the Automatic-Module-Name header is added to commons-logging.jar
> MANIFEST.MF with value org.apache.commons.logging.
> >>>
> >>> Regards,
> >>> Benedikt
> >>>
>  Stephen
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>  For additional commands, e-mail: dev-h...@commons.apache.org
> 
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>