Re: [VFS] WIP specific release instructions

[sebb]

On 5 May 2016 at 05:49, Josh Elser  wrote:
>
>
> sebb wrote:
>>
>> Have a look at the scripts in
>>
>> http://svn.apache.org/viewvc/commons/scripts/
>>
>> I used those for VALIDATOR and NET.
>
>
> Cool. Thanks for sharing. It would be good if the generic commons release
> documents referenced these if they are expected to be re-used by other
> commons projects' RMs.

They are brand new, and possibly still needing some tweaks.
They don't work wit Git.

>> On 4 May 2016 at 04:43, Josh Elser  wrote:
>>>
>>> Here's what I've been doing. The generic instructions are woefully
>>> incomplete (before someone chimes in again - no, not just because "VFS is
>>> a
>>> multi-module project"). I think I have this on point for rc1, so I'm
>>> writing
>>> it down here before I forget (we can figure out where it *should* go
>>> later).
>>>
>>> rc0 only:
>>> # Make the branch
>>> $ svn cp trunk branches/VFS-XXX
>>> $ cd branches/VFS-XXX
>>> # Set the proper versions
>>> $ mvn release:prepare
>>
>>
>> We use a tag not a branch, but perhaps that is what the release plugin
>> does.
>> In which case I assume the branch is taken to avoid mangling trunk?
>
>
> release:prepare doesn't do the tagging (this is what release:perform does).
> All it's really doing are some pre-condition checks and version updates.

OK

> TBQH, I don't have any idea how the maven-release-plugin and SVN are
> remotely useful for the ASF's vote-then-promote process.

I agree.
It's just wrong that trunk is updated before the release succeeds.
However using a temporary branch would solve that.

> That said, it's ok if I don't get it. This is what worked for me and I'm
> happy with it. If there's something obvious I could have done differently,
> great.
>
>>> ---
>>>
>>> # Or just set it to your JDK6 installation -- this works on OSX
>>> $ export JAVA_HOME=$(/usr/libexec/java_home -v1.6)
>>>
>>> # Where ${asf.username} for me is "elserj"
>>> $ mvn clean package -Duser.name=${asf.username}
>>
>>
>> No need to use package if using CP40
>
>
> What are you using instead of `package` to build the code...

mvn deploy

>>
>>> # Set back to 1.7 because my 1.6 installation has trouble deploying to
>>> nexus
>>> $ export JAVA_HOME=$(/usr/libexec/java_home -v1.7)
>>
>>
>> So does mine; in which case use -Pjava-1.6 below.
>>
>>> $ mvn deploy -Prelease -Duser.name=${asf.username}
>>>
>>> # This is what could be consolidated via one invocation of `mvn site`
>>> $ mvn site:site site:stage
>>>
>>> # Move back to the root SVN repo
>>> $ cd ../..
>>> $ svn cp branches/VFS-XXX tags/commons-vfs-project-XXX-rcN
>>
>>
>> Isn't that what the release plugin does?
>>
>> You might find
>>
>> http://svn.apache.org/viewvc/commons/scripts/create_RC_tag.sh
>>
>> easier to use - it does it all for you without needing to create a
>> temporary branch.
>
>
> Cool. I didn't find these from the generic commons release document.

They are very new.

>>> --
>>>
>>> Things not covered above:
>>>
>>> * Copying artifacts (tarballs/zips, xsums, and sigs) into
>>> dist.a.o/dev/commons/... (building md5/sha1 files)
>>> * Closing staging repo in Nexus
>>
>>
>> That can be done using Nexus2DistDev.sh
>
>
> Again, great. It would have been good to know about these beforehand.

They did not exist then...

>>
>>> --
>>>
>>> Some things that could still be improved that I didn't fix:
>>>
>>> * Artifacts in dist/target are renamed when they're installed/deployed,
>>> but
>>> not in the local directory. Should do a rename of the file on disk so
>>> that
>>> what is on the RM's computer matches what is in their m2 repo and ASF
>>> nexus.
>>
>>
>> Or ignore the local copies and use Nexus2DistDev.sh which copies the
>> bin/src artifacts from Nexus and deploys to dist/dev and can remove
>> them from Nexus before closing the staging repo.
>>
>> AFAIK only the deploy directory (i.e. Nexus) has the hashes.
>>
>>> * `mvn site` which invokes site:site and site:stage automatically (which
>>> would make for a more natural build process -- `mvn deploy` would build
>>> the
>>> site automatically)
>>
>>
>> I don't follow that.
>
>
> `mvn site` is invoking the "site" maven lifecycle phase. "mvn site:site` and
> `mvn site:stage` are invoking executions on the maven-site-plugin. These are
> two distinct kinds of actions. We can configure the maven-site-plugin
> (and/or other necessary tasks) to run at the 'site' lifecycle phase for a
> more 'natural' process.
>

I see.

I meant I did not see why 'mvn deploy ' would/should create the site.

>>
>>> Again, for now, this is just for my benefit. When this is all over, I'll
>>> try
>>> to add this all to the website. Please point out anything wrong/missing.
>>> Thanks.
>>>
>>> - Josh
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>
>> -
>> To unsubscribe

RE: [CRYPTO] Discuss to proceed the alpha release for Commons Crypto

[Sun, Dapeng]

I'm agreed. I think we can prepare the first release.

Regards
Dapeng

-Original Message-
From: Chen, Haifeng [mailto:haifeng.c...@intel.com] 
Sent: Thursday, May 05, 2016 11:21 AM
To: Commons Developers List
Subject: RE: [CRYPTO] Discuss to proceed the alpha release for Commons Crypto

Sorry for the typo in the second paragraph.

Hi,
After weeks of collaborated work from the community, the renaming, building, 
API refactoring and documentation are almost done.
Much thanks to the Commons community for all your support.

The community folks proposed to go with an alpha release if we want sooner. So 
I suggest we can proceed the alpha release now.
Please feel free to share your opinion.

If there is no objection, we will proceed to prepare the release artifacts and 
send out the release VOTE to the community when ready.

Regards,
Haifeng


From: Chen, Haifeng
Sent: Thursday, May 5, 2016 11:18 AM
To: Commons Developers List 
Subject: [CRYPTO] Discuss to proceed the alpha release for Commons Crypto

Hi,
After weeks of collaborated work from the community, the renaming, building, 
API refactoring and documentation are almost done.
Much thanks to the Commons community for all your support.

The community folks to prepare an alpha release if we want sooner. So I suggest 
we can proceed the alpha release now.
Please feel free to share your opinion.

If there is no objection, we will proceed to prepare the release artifacts and 
send out the release VOTE to the community when ready.

Regards,
Haifeng

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

RE: [CRYPTO] Discuss to proceed the alpha release for Commons Crypto

[Xu, Cheng A]

+1 for moving forwards the alpha release

-Original Message-
From: Sun, Dapeng [mailto:dapeng@intel.com] 
Sent: Thursday, May 5, 2016 4:01 PM
To: Commons Developers List 
Subject: RE: [CRYPTO] Discuss to proceed the alpha release for Commons Crypto

I'm agreed. I think we can prepare the first release.

Regards
Dapeng

-Original Message-
From: Chen, Haifeng [mailto:haifeng.c...@intel.com] 
Sent: Thursday, May 05, 2016 11:21 AM
To: Commons Developers List
Subject: RE: [CRYPTO] Discuss to proceed the alpha release for Commons Crypto

Sorry for the typo in the second paragraph.

Hi,
After weeks of collaborated work from the community, the renaming, building, 
API refactoring and documentation are almost done.
Much thanks to the Commons community for all your support.

The community folks proposed to go with an alpha release if we want sooner. So 
I suggest we can proceed the alpha release now.
Please feel free to share your opinion.

If there is no objection, we will proceed to prepare the release artifacts and 
send out the release VOTE to the community when ready.

Regards,
Haifeng


From: Chen, Haifeng
Sent: Thursday, May 5, 2016 11:18 AM
To: Commons Developers List 
Subject: [CRYPTO] Discuss to proceed the alpha release for Commons Crypto

Hi,
After weeks of collaborated work from the community, the renaming, building, 
API refactoring and documentation are almost done.
Much thanks to the Commons community for all your support.

The community folks to prepare an alpha release if we want sooner. So I suggest 
we can proceed the alpha release now.
Please feel free to share your opinion.

If there is no objection, we will proceed to prepare the release artifacts and 
send out the release VOTE to the community when ready.

Regards,
Haifeng

-
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: [CRYPTO] Discuss to proceed the alpha release for Commons Crypto

[Benedikt Ritter]

A release as soon as possible would be great. However, as Stian has pointed
out there may be a problem with US law [1]. This should be resolved before
the first release. I've created CRYPTO-54 [2] for tracking this.

Regards,
Benedikt

[1] http://markmail.org/message/4at6msgqdxq4g4h6
[2] https://issues.apache.org/jira/browse/CRYPTO-54

Xu, Cheng A  schrieb am Do., 5. Mai 2016 um 10:03 Uhr:

> +1 for moving forwards the alpha release
>
> -Original Message-
> From: Sun, Dapeng [mailto:dapeng@intel.com]
> Sent: Thursday, May 5, 2016 4:01 PM
> To: Commons Developers List 
> Subject: RE: [CRYPTO] Discuss to proceed the alpha release for Commons
> Crypto
>
> I'm agreed. I think we can prepare the first release.
>
> Regards
> Dapeng
>
> -Original Message-
> From: Chen, Haifeng [mailto:haifeng.c...@intel.com]
> Sent: Thursday, May 05, 2016 11:21 AM
> To: Commons Developers List
> Subject: RE: [CRYPTO] Discuss to proceed the alpha release for Commons
> Crypto
>
> Sorry for the typo in the second paragraph.
>
> Hi,
> After weeks of collaborated work from the community, the renaming,
> building, API refactoring and documentation are almost done.
> Much thanks to the Commons community for all your support.
>
> The community folks proposed to go with an alpha release if we want
> sooner. So I suggest we can proceed the alpha release now.
> Please feel free to share your opinion.
>
> If there is no objection, we will proceed to prepare the release artifacts
> and send out the release VOTE to the community when ready.
>
> Regards,
> Haifeng
>
>
> From: Chen, Haifeng
> Sent: Thursday, May 5, 2016 11:18 AM
> To: Commons Developers List 
> Subject: [CRYPTO] Discuss to proceed the alpha release for Commons Crypto
>
> Hi,
> After weeks of collaborated work from the community, the renaming,
> building, API refactoring and documentation are almost done.
> Much thanks to the Commons community for all your support.
>
> The community folks to prepare an alpha release if we want sooner. So I
> suggest we can proceed the alpha release now.
> Please feel free to share your opinion.
>
> If there is no objection, we will proceed to prepare the release artifacts
> and send out the release VOTE to the community when ready.
>
> Regards,
> Haifeng
>
> -
> 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
>
>

Maven Central slow to get new releases (was: [ANN] Apache Commons IO 2.5 Released)

[sebb]

The same has happened with Commons NET.

10 hours and still not available from Maven Central.

According to the issue this is supposed to have been fixed ...

I've updated the issue (but cannot re-open it).

S.
P.S. Even if this is fixed, we should still wait 12-24 hours after
publication to allow ASF mirrors to catch up.

On 22 April 2016 at 12:39, Benson Margulies  wrote:
> https://issues.sonatype.org/browse/MVNCENTRAL-1060
>
> On Fri, Apr 22, 2016 at 7:36 AM, Kristian Rosenvold
>  wrote:
>> Looks like something is amiss with the central sync, the artifacts are at
>> https://repository.apache.org/content/groups/public/commons-io/commons-io/
>>
>> You probably need to file an issue with mvncentral.
>>
>> While you're at that, you can request in the same issue that all of the
>> "commons" artifacts be set at the new and improved central-synch schedule,
>> which reduces the classic 4 hour delay to just a few minutes.
>
> -
> 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: Maven Central slow to get new releases (was: [ANN] Apache Commons IO 2.5 Released)

[Benedikt Ritter]

sebb  schrieb am Do., 5. Mai 2016 um 11:02 Uhr:

> The same has happened with Commons NET.
>
> 10 hours and still not available from Maven Central.
>
> According to the issue this is supposed to have been fixed ...
>
> I've updated the issue (but cannot re-open it).
>

Thank you for the update!


>
> S.
> P.S. Even if this is fixed, we should still wait 12-24 hours after
> publication to allow ASF mirrors to catch up.
>
> On 22 April 2016 at 12:39, Benson Margulies  wrote:
> > https://issues.sonatype.org/browse/MVNCENTRAL-1060
> >
> > On Fri, Apr 22, 2016 at 7:36 AM, Kristian Rosenvold
> >  wrote:
> >> Looks like something is amiss with the central sync, the artifacts are
> at
> >>
> https://repository.apache.org/content/groups/public/commons-io/commons-io/
> >>
> >> You probably need to file an issue with mvncentral.
> >>
> >> While you're at that, you can request in the same issue that all of the
> >> "commons" artifacts be set at the new and improved central-synch
> schedule,
> >> which reduces the classic 4 hour delay to just a few minutes.
> >
> > -
> > 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: US Export classification & ECCN registration for encryption in commons?

[Benedikt Ritter]

Hi,

Stian Soiland-Reyes  schrieb am Mi., 4. Mai 2016 um
14:35 Uhr:

> Hi,
>
> Sorry for spotting this..
>
>
> Apache Commons Crypto  is not listed on
> http://www.apache.org/licenses/exports/ - does it need to be?  (One
> would assume so..)
>
> Also it was raised that Commons VFS depends on Bouncy Castle/Apache
> Mina/Jetty/SSHD/Hadoop/jsch and has encryption binding for AES128 -
> perhaps that also needs to be listed and registered?
>

Thank you for pointing this out. I've reported this as
https://issues.apache.org/jira/browse/CRYPTO-54. I'm not involved in VFS,
but I've seen that the discussion about that has already started on the
vote for VFS 2.0 rc1.

Benedikt


>
>
> We only have listed:
>
> Commons Compress
> Commons OpenPGP
>
>
> See guidance on
> http://www.apache.org/dev/crypto.html
>
>
> BTW - I've raised https://issues.apache.org/jira/browse/LEGAL-250 to
> see if merely using a listed source as a Maven  means you
> also are classified - or if you would need to also bundle the
> dependency's binary (which I think we don't do).
>
>
>
> --
> Stian Soiland-Reyes
> Apache Taverna (incubating), Apache Commons RDF (incubating)
> http://orcid.org/-0001-9842-9718
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VFS] WIP specific release instructions

[Benedikt Ritter]

Hello Josh,

It's really great how much effort you're putting into this release. Thank
you for that!

Benedikt

sebb  schrieb am Do., 5. Mai 2016 um 09:57 Uhr:

> On 5 May 2016 at 05:49, Josh Elser  wrote:
> >
> >
> > sebb wrote:
> >>
> >> Have a look at the scripts in
> >>
> >> http://svn.apache.org/viewvc/commons/scripts/
> >>
> >> I used those for VALIDATOR and NET.
> >
> >
> > Cool. Thanks for sharing. It would be good if the generic commons release
> > documents referenced these if they are expected to be re-used by other
> > commons projects' RMs.
>
> They are brand new, and possibly still needing some tweaks.
> They don't work wit Git.
>
> >> On 4 May 2016 at 04:43, Josh Elser  wrote:
> >>>
> >>> Here's what I've been doing. The generic instructions are woefully
> >>> incomplete (before someone chimes in again - no, not just because "VFS
> is
> >>> a
> >>> multi-module project"). I think I have this on point for rc1, so I'm
> >>> writing
> >>> it down here before I forget (we can figure out where it *should* go
> >>> later).
> >>>
> >>> rc0 only:
> >>> # Make the branch
> >>> $ svn cp trunk branches/VFS-XXX
> >>> $ cd branches/VFS-XXX
> >>> # Set the proper versions
> >>> $ mvn release:prepare
> >>
> >>
> >> We use a tag not a branch, but perhaps that is what the release plugin
> >> does.
> >> In which case I assume the branch is taken to avoid mangling trunk?
> >
> >
> > release:prepare doesn't do the tagging (this is what release:perform
> does).
> > All it's really doing are some pre-condition checks and version updates.
>
> OK
>
> > TBQH, I don't have any idea how the maven-release-plugin and SVN are
> > remotely useful for the ASF's vote-then-promote process.
>
> I agree.
> It's just wrong that trunk is updated before the release succeeds.
> However using a temporary branch would solve that.
>
> > That said, it's ok if I don't get it. This is what worked for me and I'm
> > happy with it. If there's something obvious I could have done
> differently,
> > great.
> >
> >>> ---
> >>>
> >>> # Or just set it to your JDK6 installation -- this works on OSX
> >>> $ export JAVA_HOME=$(/usr/libexec/java_home -v1.6)
> >>>
> >>> # Where ${asf.username} for me is "elserj"
> >>> $ mvn clean package -Duser.name=${asf.username}
> >>
> >>
> >> No need to use package if using CP40
> >
> >
> > What are you using instead of `package` to build the code...
>
> mvn deploy
>
> >>
> >>> # Set back to 1.7 because my 1.6 installation has trouble deploying to
> >>> nexus
> >>> $ export JAVA_HOME=$(/usr/libexec/java_home -v1.7)
> >>
> >>
> >> So does mine; in which case use -Pjava-1.6 below.
> >>
> >>> $ mvn deploy -Prelease -Duser.name=${asf.username}
> >>>
> >>> # This is what could be consolidated via one invocation of `mvn site`
> >>> $ mvn site:site site:stage
> >>>
> >>> # Move back to the root SVN repo
> >>> $ cd ../..
> >>> $ svn cp branches/VFS-XXX tags/commons-vfs-project-XXX-rcN
> >>
> >>
> >> Isn't that what the release plugin does?
> >>
> >> You might find
> >>
> >> http://svn.apache.org/viewvc/commons/scripts/create_RC_tag.sh
> >>
> >> easier to use - it does it all for you without needing to create a
> >> temporary branch.
> >
> >
> > Cool. I didn't find these from the generic commons release document.
>
> They are very new.
>
> >>> --
> >>>
> >>> Things not covered above:
> >>>
> >>> * Copying artifacts (tarballs/zips, xsums, and sigs) into
> >>> dist.a.o/dev/commons/... (building md5/sha1 files)
> >>> * Closing staging repo in Nexus
> >>
> >>
> >> That can be done using Nexus2DistDev.sh
> >
> >
> > Again, great. It would have been good to know about these beforehand.
>
> They did not exist then...
>
> >>
> >>> --
> >>>
> >>> Some things that could still be improved that I didn't fix:
> >>>
> >>> * Artifacts in dist/target are renamed when they're installed/deployed,
> >>> but
> >>> not in the local directory. Should do a rename of the file on disk so
> >>> that
> >>> what is on the RM's computer matches what is in their m2 repo and ASF
> >>> nexus.
> >>
> >>
> >> Or ignore the local copies and use Nexus2DistDev.sh which copies the
> >> bin/src artifacts from Nexus and deploys to dist/dev and can remove
> >> them from Nexus before closing the staging repo.
> >>
> >> AFAIK only the deploy directory (i.e. Nexus) has the hashes.
> >>
> >>> * `mvn site` which invokes site:site and site:stage automatically
> (which
> >>> would make for a more natural build process -- `mvn deploy` would build
> >>> the
> >>> site automatically)
> >>
> >>
> >> I don't follow that.
> >
> >
> > `mvn site` is invoking the "site" maven lifecycle phase. "mvn site:site`
> and
> > `mvn site:stage` are invoking executions on the maven-site-plugin. These
> are
> > two distinct kinds of actions. We can configure the maven-site-plugin
> > (and/or other necessary tasks) to run at the 'site' lifecycle phase for a
> > more 'natural' process.
> >
>
> I see.
>
> I meant I did not see why 'mvn deploy ' would/should create the site.
>
> >>
> >>> Agai

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Stian Soiland-Reyes]

Raised as https://issues.apache.org/jira/browse/VFS-604

I'll investigate a bit with the return values to see if VFS claims the
setting of permissions succeeded.

noexec is a bit weird.. you are allowed to SET the executable bit
(e.g. it would be correctly tar-ed up with exec flag), it just doesn't
have the effect if trying to exec it.


stain@biggie:/tmp$ echo '#!/bin/cat' > hello
stain@biggie:/tmp$ chmod 755 hello

stain@biggie:/tmp$ ./hello
-bash: ./hello: Permission denied

stain@biggie:/tmp$ ls -al hello
-rwxr-xr-x 1 stain stain 11 May  5 10:16 hello



On 4 May 2016 at 19:53, Bernd Eckenfels  wrote:
> Thanks Stian!
>
> Do you plan to report the noexec issue? If not let me know and I will
> file one.
>
> I thought we already had one but I cant find it.
>
> I will do some windows tests and then vote.
>
> Gruss
> Bernd
>
>  Am Wed, 4 May 2016 13:28:54 +0100
> schrieb Stian Soiland-Reyes :
>
>> +1 (non-binding)
>>
>> +1 signatures
>> +1 hashes
>> +1 LICENSE, NOTICE
>> 0 README.md says 2.0
>> 0 Extra README.txt (confusing)
>> +1 RELEASE-NOTES.txt
>> +1 mvn apache-rat:check
>> +1 maven repository signatures/hashes
>> +1 maven repository *distribution* matches dist/
>> 0 mvn clean install OK (but 1 test fails on tmpfs)
>> +1 target/*jar matches binaries
>> +1 source matches svn tag (minus sandbox/ :-) )
>> +1 Dependency licenses OK
>> -1 Unclassified use of encryption libraries Bouncy Castle/Apache
>> Mina/SSHD/Hadoop/jsch/Jetty (plus some AES128 in DefaultCryptor) - but
>> Commons VFS is not classified on
>> http://www.apache.org/licenses/exports/
>>
>> I won't take a stand on the US Export classification requirement as
>> https://issues.apache.org/jira/browse/LEGAL-250 has not been resolved
>> yet.
>>
>>
>> I get this test error (because my /tmp is mounted with noexec):
>>
>> Tests run: 90, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 4.259
>> sec <<< FAILURE! - in
>> org.apache.commons.vfs2.provider.local.test.LocalProviderTestCase
>> testExecutable(org.apache.commons.vfs2.test.PermissionsTests)  Time
>> elapsed: 0.011 sec  <<< FAILURE!
>> java.lang.AssertionError
>> at org.junit.Assert.fail(Assert.java:86)
>> at org.junit.Assert.assertTrue(Assert.java:41)
>> at org.junit.Assert.assertTrue(Assert.java:52)
>> at
>> org.apache.commons.vfs2.test.PermissionsTests.testExecutable(PermissionsTests.java:70)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498) at
>> org.apache.commons.vfs2.test.AbstractProviderTestCase.runTest(AbstractProviderTestCase.java:218)
>> at junit.framework.TestCase.runBare(TestCase.java:141) at
>> junit.framework.TestResult$1.protect(TestResult.java:122) at
>> junit.framework.TestResult.runProtected(TestResult.java:142) at
>> junit.framework.TestResult.run(TestResult.java:125) at
>> junit.framework.TestCase.run(TestCase.java:129) at
>> junit.framework.TestSuite.runTest(TestSuite.java:252) at
>> junit.framework.TestSuite.run(TestSuite.java:247) at
>> junit.extensions.TestDecorator.basicRun(TestDecorator.java:23) at
>> org.apache.commons.vfs2.test.AbstractTestSuite$1.protect(AbstractTestSuite.java:149)
>> at junit.framework.TestResult.runProtected(TestResult.java:142) at
>> org.apache.commons.vfs2.test.AbstractTestSuite.run(AbstractTestSuite.java:154)
>>
>> Building from /var/tmp worked.
>>
>> I won't fail because of this - I'm probably special still using tmpfs
>> :)   (And adding conditional testing would mean using the same APIs or
>> requivalent Java 7 NIO files APIs to see if executable bit is
>> supported).
>>
>>
>> Checked with:
>>
>> stain@biggie:/tmp/vfs/source/commons-vfs-2.1$ mvn -v
>> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
>> 2015-11-10T16:41:47+00:00)
>> Maven home: /home/stain/software/maven
>> Java version: 1.8.0_72-internal, vendor: Oracle Corporation
>> Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
>> Default locale: en_GB, platform encoding: UTF-8
>> OS name: "linux", version: "3.16.0-67-generic", arch: "amd64",
>> family: "unix"
>>
>> On 4 May 2016 at 04:43, Josh Elser  wrote:
>> > All,
>> >
>> > Please consider the following for Apache Commons VFS2 version 2.1
>> > (rc1).
>> >
>> > Maven repository:
>> > https://repository.apache.org/content/repositories/orgapachecommons-1163
>> > Artifacts: https://dist.apache.org/repos/dist/dev/commons/vfs/
>> > r13511
>> >
>> > MD5  commons-vfs-distribution-2.1-bin.tar.gz
>> > 1192914d1ba6f8ca3a2a688feeff602c
>> > SHA1 commons-vfs-distribution-2.1-bin.tar.gz
>> > 285097f1db6cbc9d76ae5bb3adf66a315344a864
>> > MD5  commons-vfs-distribution-2.1-src.tar.gz
>> > 0646187562302a7dcfbddb93204fc9eb
>> > SHA1 commons-vfs-distribution-2.1-src.tar.gz
>> > 24bab87fd4049b9389acd1b6e272f405630aeb25
>> > MD5  commons-vfs-distribution-2.1-bin.zip
>> > 3785874aa

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Stian Soiland-Reyes]

Test dependency should be fine. The SSHD and JSch integration is
however probably not OK without classification.


I think integrating with "encryption functionality" (without bundling)
is sufficient to become an "encryption item":

http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201605.mbox/%3CD35026DE.692DB%25aharui%40adobe.com%3E

https://www.bis.doc.gov/index.php/policy-guidance/encryption/identifying-encryption-items


Let's try to sort this in the separate thread:
http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3CCAB917R%2BuGHPiOUUq_F48n3-m-nKdgrgndcBkmpmA%3DS1H3Ngs5Q%40mail.gmail.com%3E

It could be that Apache's pages about this is out of date.

On 4 May 2016 at 18:50, Jörg Schaible  wrote:
> Hi Stian,
>
> Stian Soiland-Reyes wrote:
>
>
> [snip]
>
>> -1 Unclassified use of encryption libraries Bouncy Castle/Apache
>> Mina/SSHD/Hadoop/jsch/Jetty (plus some AES128 in DefaultCryptor) - but
>> Commons VFS is not classified on
>> http://www.apache.org/licenses/exports/
>
>
> Sorry, but I fail to see the problem. BC is used as test dependency only and
> it is nowhere part of our deliveries or used in our code. AES128 is part of
> the Java runtime.
>
> Cheers,
> Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

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

Re: US Export classification & ECCN registration for encryption in commons?

[sebb]

Also note that there is a TSU Exception, EAR 740.13(e) - Publicly
available encryption source code - which the dev/crypto.html page says
applies to the ASF.

I think we need to wait for guidance from Legal.

On 5 May 2016 at 10:04, Benedikt Ritter  wrote:
> Hi,
>
> Stian Soiland-Reyes  schrieb am Mi., 4. Mai 2016 um
> 14:35 Uhr:
>
>> Hi,
>>
>> Sorry for spotting this..
>>
>>
>> Apache Commons Crypto  is not listed on
>> http://www.apache.org/licenses/exports/ - does it need to be?  (One
>> would assume so..)
>>
>> Also it was raised that Commons VFS depends on Bouncy Castle/Apache
>> Mina/Jetty/SSHD/Hadoop/jsch and has encryption binding for AES128 -
>> perhaps that also needs to be listed and registered?
>>
>
> Thank you for pointing this out. I've reported this as
> https://issues.apache.org/jira/browse/CRYPTO-54. I'm not involved in VFS,
> but I've seen that the discussion about that has already started on the
> vote for VFS 2.0 rc1.
>
> Benedikt
>
>
>>
>>
>> We only have listed:
>>
>> Commons Compress
>> Commons OpenPGP
>>
>>
>> See guidance on
>> http://www.apache.org/dev/crypto.html
>>
>>
>> BTW - I've raised https://issues.apache.org/jira/browse/LEGAL-250 to
>> see if merely using a listed source as a Maven  means you
>> also are classified - or if you would need to also bundle the
>> dependency's binary (which I think we don't do).
>>
>>
>>
>> --
>> Stian Soiland-Reyes
>> Apache Taverna (incubating), Apache Commons RDF (incubating)
>> http://orcid.org/-0001-9842-9718
>>
>> -
>> 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] Apache Commons VFS 2.1 rc1

[Stian Soiland-Reyes]

> [ERROR] Failed to execute goal on project commons-vfs2: Could not resolve
> dependencies for project org.apache.commons:commons-vfs2:jar:2.1: Could not
> find artifact jdk.tools:jdk.tools:jar:1.6 at specified path /opt/oracle-jdk-
> bin-1.9.0.0_beta116/../lib/tools.jar -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR]   mvn  -rf :commons-vfs2
> = %< ==
>
> The reason is an invalid (transitive) system dependency on tools.jar of
> Hadoop which is no longer present in Java 9.

hadoop-common:test-jar pulls in:

http://central.maven.org/maven2/org/apache/hadoop/hadoop-annotations/2.6.0/hadoop-annotations-2.6.0.pom

With two different profiles, the os.linux profile activates for me as
well, as the activation here is "Not a mac".


The newer Hadoop 2.7.1 seems to have fixed to these activations.

http://central.maven.org/maven2/org/apache/hadoop/hadoop-annotations/2.7.1/hadoop-annotations-2.7.1.pom

(Hadoop 2.7 presumably no longer works on JDK6)


Could you try changing all the Hadoop 2.6.0 dependencies in pom.xml to
2.7.1 and see if JDK9 is happy then?

(We can always exclude it tools.jar in the test dependency, I don't
see how it's needed for our tests)

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

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Stian Soiland-Reyes]

"EC AlgorithmParameters not available" seems to be a OpenJDK bug
because Elastic Curves relies on the sunec native library -
http://armoredbarista.blogspot.co.uk/2013/10/how-to-use-ecc-with-openjdk.html


Presumably this would also fail in those JDKs?

URL url = new java.net.URL("https://www.google.com/images/logos/ps_logo2.png";);
url.openConnection();


We can modify https/test/GetContentInfoFunctionalTest to not rely on
fetching https://www.google.com/images/logos/ps_logo2.png - this
sounds a bit fragile to me anyway - for how long would that file
remain available?

If we need to do an external test, then we should use say
https://www.apache.org/licenses/LICENSE-2.0.txt

Obviously if INFRA changes the SSL configuration there to also request
Elastic Curves, then the test could still fail.


Tracked as https://issues.apache.org/jira/browse/VFS-605
and fix committed on trunk to instead test against
https://www.apache.org/licenses/LICENSE-2.0.tx

Could you verify if trunk builds on icedtea-bin-3.0.0 and IBM JDK?


On 4 May 2016 at 23:39, Jörg Schaible  wrote:
> Hi,
>
> I've tried to build the release from the source tarball using my compiler
> zoo.
>
> Passes:
>  - Sun JDK 1.6
>  - IcedTea/OpenJDK 6
>  - Oracle JDK 1.7
>  - IcedTea/OpenJDK 7
>  - Oracle JDK 1.8
>
> Tests fail with IBM JDKs 1.6 and 1.7, IcedTea/OpenJDK 3 and Java 9:
>
> = %< ==
> $ mvn-3.2 -version
> Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1;
> 2014-12-14T18:29:23+01:00)
> Maven home: /usr/share/maven-bin-3.2
> Java version: 1.6.0, vendor: IBM Corporation
> Java home: /opt/ibm-jdk-bin-1.6.0.9_p2/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.6-gentoo", arch: "amd64", family: "unix"
> = %< ==
> Failed tests:
> org.apache.commons.vfs2.impl.test.VfsClassLoaderTests.testGetResourcesJARs(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests)
>   Run 1: PASS
>   Run 2: PASS
>   Run 3: PASS
>   Run 4: PASS
>   Run 5: PASS
>   Run 6: PASS
>   Run 7: PASS
>   Run 8: PASS
>   Run 9: VfsClassLoaderTests>AbstractProviderTestCase.runTest:218-
>>testGetResourcesJARs:154 First resource must refer to nested.jar but was
> jar:file:/opt/ibm-jdk-
> bin-1.6.0.9_p2/jre/lib/amd64/default/jclSC160/vm.jar!/META-INF/MANIFEST.MF
>   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
> = %< ==
> $ mvn -version
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> 2015-11-10T17:41:47+01:00)
> Maven home: /usr/share/maven-bin-3.3
> Java version: 1.7.0, vendor: IBM Corporation
> Java home: /opt/ibm-jdk-bin-1.7.0.5/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.6-gentoo", arch: "amd64", family: "unix"
> = %< ==
> Failed tests:
> org.apache.commons.vfs2.impl.test.VfsClassLoaderTests.testGetResourcesJARs(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests)
>   Run 1: PASS
>   Run 2: PASS
>   Run 3: PASS
>   Run 4: PASS
>   Run 5: PASS
>   Run 6: PASS
>   Run 7: PASS
>   Run 8: PASS
>   Run 9: VfsClassLoaderTests>AbstractProviderTestCase.runTest:218-
>>testGetResourcesJARs:154 First resource must refer to nested.jar but was
> jar:file:/opt/ibm-jdk-
> bin-1.7.0.5/jre/lib/amd64/compressedrefs/jclSC170/vm.jar!/META-
> INF/MANIFEST.MF
>   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
> = %< ==
> $ mvn -version
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> 2015-11-10T17:41:47+01:00)
> Maven home: /usr/share/maven-bin-3.3
> Java version: 1.8.0_77, vendor: Oracle Corporation
> Java home: /opt/icedtea-bin-3.0.0/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.6-gentoo", arch: "amd64", family: "unix"
> = %< ==
> Tests in error:
>   GetContentInfoFunctionalTest.testGoogle:76 » FileSystem Unknown message
> with code "java.lang.RuntimeException:
> java.security.NoSuchAlgorithmException: EC AlgorithmParameters not
> available".
> at
> org.apache.commons.vfs2.provider.http.HttpFileContentInfoFactory.create(HttpFileContentInfoFactory.java:51)
> at
> org.apache.commons.vfs2.provider.DefaultFileContent.getContentInfo(DefaultFileContent.java:806)
> at
> org.apache.commons.vfs2.provider.https.test.GetContentInfoFunctionalTest.testGoogle(GetContentInfoFunctionalTest.java:76)
> at sun.reflect.NativeMetho

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Jörg Schaible]

Hi Stian,

Stian Soiland-Reyes wrote:

>> [ERROR] Failed to execute goal on project commons-vfs2: Could not resolve
>> dependencies for project org.apache.commons:commons-vfs2:jar:2.1: Could
>> not find artifact jdk.tools:jdk.tools:jar:1.6 at specified path
>> /opt/oracle-jdk- bin-1.9.0.0_beta116/../lib/tools.jar -> [Help 1]
>> [ERROR]
>> [ERROR] To see the full stack trace of the errors, re-run Maven with the
>> [-e
>> switch.
>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>> [ERROR]
>> [ERROR] For more information about the errors and possible solutions,
>> [please
>> read the following articles:
>> [ERROR] [Help 1]
>> 
http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
>> [ERROR]
>> [ERROR] After correcting the problems, you can resume the build with the
>> command
>> [ERROR]   mvn  -rf :commons-vfs2
>> = %< ==
>>
>> The reason is an invalid (transitive) system dependency on tools.jar of
>> Hadoop which is no longer present in Java 9.
> 
> hadoop-common:test-jar pulls in:
> 
> http://central.maven.org/maven2/org/apache/hadoop/hadoop-annotations/2.6.0/hadoop-annotations-2.6.0.pom
> 
> With two different profiles, the os.linux profile activates for me as
> well, as the activation here is "Not a mac".
> 
> 
> The newer Hadoop 2.7.1 seems to have fixed to these activations.
> 
> http://central.maven.org/maven2/org/apache/hadoop/hadoop-annotations/2.7.1/hadoop-annotations-2.7.1.pom
> 
> (Hadoop 2.7 presumably no longer works on JDK6)
> 
> 
> Could you try changing all the Hadoop 2.6.0 dependencies in pom.xml to
> 2.7.1 and see if JDK9 is happy then?
> 
> (We can always exclude it tools.jar in the test dependency, I don't
> see how it's needed for our tests)

After finally upgrading all four (!) Hadoop versions in the parent (we 
should introduce a property for the Hadoop version), Oracle JDK 8 passes 
again. However, Java 9 fails still with the jar plugin (and an ignored 
ClassCastExceptions in the tests caused by Jetty):

 %< =
$ mvn -version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
2015-11-10T17:41:47+01:00)
Maven home: /usr/share/maven-bin-3.3
Java version: 9-ea, vendor: Oracle Corporation
Java home: /opt/oracle-jdk-bin-1.9.0.0_beta116
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.6-gentoo", arch: "amd64", family: "unix"
 %< =
Tests run: 84, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 30.141 sec 
- in org.apache.commons.vfs2.provider.ftps.test.FtpsProviderExplicitTestCase
Running org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase
2016-05-05 12:37:16,660 [main] ERROR: unavailable
java.lang.ClassCastException: 
jdk.internal.loader.ClassLoaders$AppClassLoader (in module: java.base) 
cannot be cast to java.net.URLClassLoader (in module: java.base)
at 
org.apache.jasper.compiler.JspRuntimeContext.(JspRuntimeContext.java:174)
at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:150)
at 
org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:431)
at 
org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:263)
at 
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at 
org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:643)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
at 
org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1234)
at 
org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
at 
org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:460)
at 
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at 
org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
at 
org.mortbay.jetty.handler.RequestLogHandler.doStart(RequestLogHandler.java:115)
at 
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at 
org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
at org.mortbay.jetty.Server.doStart(Server.java:222)
at 
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at 
org.apache.commons.vfs2.provider.webdav.test.JackrabbitMain.run(JackrabbitMain.java:264)
at 
org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase.startJackrabbit(WebdavProviderTestCase.java:270)
at 
org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase.setUpClass(WebdavProviderTestCase.java:247)
at 
org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase.access$100(WebdavProviderTestCase.java:55)
at 
org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase$1.setUp(WebdavProviderTestCase.java:282)
  

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Jörg Schaible]

Hi Stian,

Stian Soiland-Reyes wrote:

> "EC AlgorithmParameters not available" seems to be a OpenJDK bug
> because Elastic Curves relies on the sunec native library -
> http://armoredbarista.blogspot.co.uk/2013/10/how-to-use-ecc-with-openjdk.html
> 
> 
> Presumably this would also fail in those JDKs?
> 
> URL url = new
> java.net.URL("https://www.google.com/images/logos/ps_logo2.png";);
> url.openConnection();
> 
> 
> We can modify https/test/GetContentInfoFunctionalTest to not rely on
> fetching https://www.google.com/images/logos/ps_logo2.png - this
> sounds a bit fragile to me anyway - for how long would that file
> remain available?
> 
> If we need to do an external test, then we should use say
> https://www.apache.org/licenses/LICENSE-2.0.txt
> 
> Obviously if INFRA changes the SSL configuration there to also request
> Elastic Curves, then the test could still fail.
> 
> 
> Tracked as https://issues.apache.org/jira/browse/VFS-605
> and fix committed on trunk to instead test against
> https://www.apache.org/licenses/LICENSE-2.0.tx
> 
> Could you verify if trunk builds on icedtea-bin-3.0.0 and IBM JDK?

Icedtea 3 builds fine now, but the IBM JDKs still fail with the same errors. 
To me it looks like the test simply makes wrong assumptions about the 
content of the classloader.

Cheers,
Jörg


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

Re: [VFS] WIP specific release instructions

[ecki]

Hello,

BTW: I would use "mvn verify" instead of "mvn package" (I am  not sure what has 
changed for CP40)

(And yes the release plugin and the commons procedure for releases is a match 
in hell ,)

Gruss
Bernd
-- 
http://bernd.eckenfels.net

-Original Message-
From: Josh Elser 
To: Commons Developers List 
Sent: Do., 05 Mai 2016 6:49
Subject: Re: [VFS] WIP specific release instructions



sebb wrote:
> Have a look at the scripts in
>
> http://svn.apache.org/viewvc/commons/scripts/
>
> I used those for VALIDATOR and NET.

Cool. Thanks for sharing. It would be good if the generic commons 
release documents referenced these if they are expected to be re-used by 
other commons projects' RMs.

> On 4 May 2016 at 04:43, Josh Elser  wrote:
>> Here's what I've been doing. The generic instructions are woefully
>> incomplete (before someone chimes in again - no, not just because "VFS is a
>> multi-module project"). I think I have this on point for rc1, so I'm writing
>> it down here before I forget (we can figure out where it *should* go later).
>>
>> rc0 only:
>> # Make the branch
>> $ svn cp trunk branches/VFS-XXX
>> $ cd branches/VFS-XXX
>> # Set the proper versions
>> $ mvn release:prepare
>
> We use a tag not a branch, but perhaps that is what the release plugin does.
> In which case I assume the branch is taken to avoid mangling trunk?

release:prepare doesn't do the tagging (this is what release:perform 
does). All it's really doing are some pre-condition checks and version 
updates. TBQH, I don't have any idea how the maven-release-plugin and 
SVN are remotely useful for the ASF's vote-then-promote process.

That said, it's ok if I don't get it. This is what worked for me and I'm 
happy with it. If there's something obvious I could have done 
differently, great.

>> ---
>>
>> # Or just set it to your JDK6 installation -- this works on OSX
>> $ export JAVA_HOME=$(/usr/libexec/java_home -v1.6)
>>
>> # Where ${asf.username} for me is "elserj"
>> $ mvn clean package -Duser.name=${asf.username}
>
> No need to use package if using CP40

What are you using instead of `package` to build the code...

>
>> # Set back to 1.7 because my 1.6 installation has trouble deploying to nexus
>> $ export JAVA_HOME=$(/usr/libexec/java_home -v1.7)
>
> So does mine; in which case use -Pjava-1.6 below.
>
>> $ mvn deploy -Prelease -Duser.name=${asf.username}
>>
>> # This is what could be consolidated via one invocation of `mvn site`
>> $ mvn site:site site:stage
>>
>> # Move back to the root SVN repo
>> $ cd ../..
>> $ svn cp branches/VFS-XXX tags/commons-vfs-project-XXX-rcN
>
> Isn't that what the release plugin does?
>
> You might find
>
> http://svn.apache.org/viewvc/commons/scripts/create_RC_tag.sh
>
> easier to use - it does it all for you without needing to create a
> temporary branch.

Cool. I didn't find these from the generic commons release document.

>> --
>>
>> Things not covered above:
>>
>> * Copying artifacts (tarballs/zips, xsums, and sigs) into
>> dist.a.o/dev/commons/... (building md5/sha1 files)
>> * Closing staging repo in Nexus
>
> That can be done using Nexus2DistDev.sh

Again, great. It would have been good to know about these beforehand.

>
>> --
>>
>> Some things that could still be improved that I didn't fix:
>>
>> * Artifacts in dist/target are renamed when they're installed/deployed, but
>> not in the local directory. Should do a rename of the file on disk so that
>> what is on the RM's computer matches what is in their m2 repo and ASF nexus.
>
> Or ignore the local copies and use Nexus2DistDev.sh which copies the
> bin/src artifacts from Nexus and deploys to dist/dev and can remove
> them from Nexus before closing the staging repo.
>
> AFAIK only the deploy directory (i.e. Nexus) has the hashes.
>
>> * `mvn site` which invokes site:site and site:stage automatically (which
>> would make for a more natural build process -- `mvn deploy` would build the
>> site automatically)
>
> I don't follow that.

`mvn site` is invoking the "site" maven lifecycle phase. "mvn site:site` 
and `mvn site:stage` are invoking executions on the maven-site-plugin. 
These are two distinct kinds of actions. We can configure the 
maven-site-plugin (and/or other necessary tasks) to run at the 'site' 
lifecycle phase for a more 'natural' process.

>
>> Again, for now, this is just for my benefit. When this is all over, I'll try
>> to add this all to the website. Please point out anything wrong/missing.
>> Thanks.
>>
>> - Josh
>>
>> -
>> 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-unsub

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Stian Soiland-Reyes]

Thanks, I've added ${hadoop.version} so it's easier to upgrade in the
future, and also committed the  of tools.jar


I think the maven-jar-maven JDK9 issue is due to
https://issues.apache.org/jira/browse/MJAR-206
https://issues.apache.org/jira/browse/MJAR-205

so you would need to wait for maven-jar-plugin 3.0.0



Not sure about the JspRuntimeContext class cast exception..

jdk.internal.loader.ClassLoaders$AppClassLoader (in module: java.base)
cannot be cast to java.net.URLClassLoader

sounds like a bit naive casting by Jasper.  Perhaps we would then also
need to force a newer version - this is PRETTY old:

[INFO] |  +- tomcat:jasper-compiler:jar:5.5.23:test
[INFO] |  +- tomcat:jasper-runtime:jar:5.5.23:test

(This version is also coming in as a Hadoop test dependency)

Fixed in Tomcat 8.0.0 at least:

https://github.com/apache/tomcat/blob/TOMCAT_8_0_0/java/org/apache/jasper/compiler/JspRuntimeContext.java#L403


On 5 May 2016 at 11:49, Jörg Schaible  wrote:
> Hi Stian,
>
> Stian Soiland-Reyes wrote:
>
>>> [ERROR] Failed to execute goal on project commons-vfs2: Could not resolve
>>> dependencies for project org.apache.commons:commons-vfs2:jar:2.1: Could
>>> not find artifact jdk.tools:jdk.tools:jar:1.6 at specified path
>>> /opt/oracle-jdk- bin-1.9.0.0_beta116/../lib/tools.jar -> [Help 1]
>>> [ERROR]
>>> [ERROR] To see the full stack trace of the errors, re-run Maven with the
>>> [-e
>>> switch.
>>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>>> [ERROR]
>>> [ERROR] For more information about the errors and possible solutions,
>>> [please
>>> read the following articles:
>>> [ERROR] [Help 1]
>>>
> http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
>>> [ERROR]
>>> [ERROR] After correcting the problems, you can resume the build with the
>>> command
>>> [ERROR]   mvn  -rf :commons-vfs2
>>> = %< ==
>>>
>>> The reason is an invalid (transitive) system dependency on tools.jar of
>>> Hadoop which is no longer present in Java 9.
>>
>> hadoop-common:test-jar pulls in:
>>
>> http://central.maven.org/maven2/org/apache/hadoop/hadoop-annotations/2.6.0/hadoop-annotations-2.6.0.pom
>>
>> With two different profiles, the os.linux profile activates for me as
>> well, as the activation here is "Not a mac".
>>
>>
>> The newer Hadoop 2.7.1 seems to have fixed to these activations.
>>
>> http://central.maven.org/maven2/org/apache/hadoop/hadoop-annotations/2.7.1/hadoop-annotations-2.7.1.pom
>>
>> (Hadoop 2.7 presumably no longer works on JDK6)
>>
>>
>> Could you try changing all the Hadoop 2.6.0 dependencies in pom.xml to
>> 2.7.1 and see if JDK9 is happy then?
>>
>> (We can always exclude it tools.jar in the test dependency, I don't
>> see how it's needed for our tests)
>
> After finally upgrading all four (!) Hadoop versions in the parent (we
> should introduce a property for the Hadoop version), Oracle JDK 8 passes
> again. However, Java 9 fails still with the jar plugin (and an ignored
> ClassCastExceptions in the tests caused by Jetty):
>
>  %< =
> $ mvn -version
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> 2015-11-10T17:41:47+01:00)
> Maven home: /usr/share/maven-bin-3.3
> Java version: 9-ea, vendor: Oracle Corporation
> Java home: /opt/oracle-jdk-bin-1.9.0.0_beta116
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.6-gentoo", arch: "amd64", family: "unix"
>  %< =
> Tests run: 84, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 30.141 sec
> - in org.apache.commons.vfs2.provider.ftps.test.FtpsProviderExplicitTestCase
> Running org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase
> 2016-05-05 12:37:16,660 [main] ERROR: unavailable
> java.lang.ClassCastException:
> jdk.internal.loader.ClassLoaders$AppClassLoader (in module: java.base)
> cannot be cast to java.net.URLClassLoader (in module: java.base)
> at
> org.apache.jasper.compiler.JspRuntimeContext.(JspRuntimeContext.java:174)
> at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:150)
> at
> org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:431)
> at
> org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:263)
> at
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> at
> org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:643)
> at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
> at
> org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1234)
> at
> org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
> at
> org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:460)
> at
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> at
> o

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Stian Soiland-Reyes]

No, it shouldn't matter the class loader content to do a normal https
connection, should it?  Or do you consider that optional support from
the JDK? In that case the tests would need to test for https
capability first and ignore themselves if the JDK doesn't support SSL.

Is this the latest IBM JDK patch release..?

On 5 May 2016 at 12:05, Jörg Schaible  wrote:
> Hi Stian,
>
> Stian Soiland-Reyes wrote:
>
>> "EC AlgorithmParameters not available" seems to be a OpenJDK bug
>> because Elastic Curves relies on the sunec native library -
>> http://armoredbarista.blogspot.co.uk/2013/10/how-to-use-ecc-with-openjdk.html
>>
>>
>> Presumably this would also fail in those JDKs?
>>
>> URL url = new
>> java.net.URL("https://www.google.com/images/logos/ps_logo2.png";);
>> url.openConnection();
>>
>>
>> We can modify https/test/GetContentInfoFunctionalTest to not rely on
>> fetching https://www.google.com/images/logos/ps_logo2.png - this
>> sounds a bit fragile to me anyway - for how long would that file
>> remain available?
>>
>> If we need to do an external test, then we should use say
>> https://www.apache.org/licenses/LICENSE-2.0.txt
>>
>> Obviously if INFRA changes the SSL configuration there to also request
>> Elastic Curves, then the test could still fail.
>>
>>
>> Tracked as https://issues.apache.org/jira/browse/VFS-605
>> and fix committed on trunk to instead test against
>> https://www.apache.org/licenses/LICENSE-2.0.tx
>>
>> Could you verify if trunk builds on icedtea-bin-3.0.0 and IBM JDK?
>
> Icedtea 3 builds fine now, but the IBM JDKs still fail with the same errors.
> To me it looks like the test simply makes wrong assumptions about the
> content of the classloader.
>
> Cheers,
> Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

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

Re: [VFS] WIP specific release instructions

[sebb]

On 5 May 2016 at 12:22,   wrote:
> Hello,
>
> BTW: I would use "mvn verify" instead of "mvn package" (I am  not sure what 
> has changed for CP40)

CP40 changed the assembly plugin to run in the verify phase so it can
pick up any additional jars added to the package phase by component
poms.
[It's not possible to ensure the assembly plugin runs at the very end
of the assembly phase - see COMMONSSITE-87]

Releases should be generated using

mvn deploy -Prelease

'mvn package' should still work for generating jars.

> (And yes the release plugin and the commons procedure for releases is a match 
> in hell ,)

Not just Commons.
Any project which allows multiple RCs for the same release is affected.
The plugin works best where failed releases are abandoned and the
version bumped for the next RC.
It does not play well with retries.

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

> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
>
> -Original Message-
> From: Josh Elser 
> To: Commons Developers List 
> Sent: Do., 05 Mai 2016 6:49
> Subject: Re: [VFS] WIP specific release instructions
>
>
>
> sebb wrote:
>> Have a look at the scripts in
>>
>> http://svn.apache.org/viewvc/commons/scripts/
>>
>> I used those for VALIDATOR and NET.
>
> Cool. Thanks for sharing. It would be good if the generic commons
> release documents referenced these if they are expected to be re-used by
> other commons projects' RMs.
>
>> On 4 May 2016 at 04:43, Josh Elser  wrote:
>>> Here's what I've been doing. The generic instructions are woefully
>>> incomplete (before someone chimes in again - no, not just because "VFS is a
>>> multi-module project"). I think I have this on point for rc1, so I'm writing
>>> it down here before I forget (we can figure out where it *should* go later).
>>>
>>> rc0 only:
>>> # Make the branch
>>> $ svn cp trunk branches/VFS-XXX
>>> $ cd branches/VFS-XXX
>>> # Set the proper versions
>>> $ mvn release:prepare
>>
>> We use a tag not a branch, but perhaps that is what the release plugin does.
>> In which case I assume the branch is taken to avoid mangling trunk?
>
> release:prepare doesn't do the tagging (this is what release:perform
> does). All it's really doing are some pre-condition checks and version
> updates. TBQH, I don't have any idea how the maven-release-plugin and
> SVN are remotely useful for the ASF's vote-then-promote process.
>
> That said, it's ok if I don't get it. This is what worked for me and I'm
> happy with it. If there's something obvious I could have done
> differently, great.
>
>>> ---
>>>
>>> # Or just set it to your JDK6 installation -- this works on OSX
>>> $ export JAVA_HOME=$(/usr/libexec/java_home -v1.6)
>>>
>>> # Where ${asf.username} for me is "elserj"
>>> $ mvn clean package -Duser.name=${asf.username}
>>
>> No need to use package if using CP40
>
> What are you using instead of `package` to build the code...
>
>>
>>> # Set back to 1.7 because my 1.6 installation has trouble deploying to nexus
>>> $ export JAVA_HOME=$(/usr/libexec/java_home -v1.7)
>>
>> So does mine; in which case use -Pjava-1.6 below.
>>
>>> $ mvn deploy -Prelease -Duser.name=${asf.username}
>>>
>>> # This is what could be consolidated via one invocation of `mvn site`
>>> $ mvn site:site site:stage
>>>
>>> # Move back to the root SVN repo
>>> $ cd ../..
>>> $ svn cp branches/VFS-XXX tags/commons-vfs-project-XXX-rcN
>>
>> Isn't that what the release plugin does?
>>
>> You might find
>>
>> http://svn.apache.org/viewvc/commons/scripts/create_RC_tag.sh
>>
>> easier to use - it does it all for you without needing to create a
>> temporary branch.
>
> Cool. I didn't find these from the generic commons release document.
>
>>> --
>>>
>>> Things not covered above:
>>>
>>> * Copying artifacts (tarballs/zips, xsums, and sigs) into
>>> dist.a.o/dev/commons/... (building md5/sha1 files)
>>> * Closing staging repo in Nexus
>>
>> That can be done using Nexus2DistDev.sh
>
> Again, great. It would have been good to know about these beforehand.
>
>>
>>> --
>>>
>>> Some things that could still be improved that I didn't fix:
>>>
>>> * Artifacts in dist/target are renamed when they're installed/deployed, but
>>> not in the local directory. Should do a rename of the file on disk so that
>>> what is on the RM's computer matches what is in their m2 repo and ASF nexus.
>>
>> Or ignore the local copies and use Nexus2DistDev.sh which copies the
>> bin/src artifacts from Nexus and deploys to dist/dev and can remove
>> them from Nexus before closing the staging repo.
>>
>> AFAIK only the deploy directory (i.e. Nexus) has the hashes.
>>
>>> * `mvn site` which invokes site:site and site:stage automatically (which
>>> would make for a more natural build process -- `mvn deploy` would build the
>>> site automatically)
>>
>> I don't follow that.
>
> `mvn site` is invoking the "site" maven lifecycle phase. "mvn site:site`
> and `mvn site:stage` are invoking executions on the maven-site-plugin.
> These are two distinct kinds of act

Re: [VFS] WIP specific release instructions

[Benedikt Ritter]

sebb  schrieb am Do., 5. Mai 2016 um 13:55 Uhr:

> On 5 May 2016 at 12:22,   wrote:
> > Hello,
> >
> > BTW: I would use "mvn verify" instead of "mvn package" (I am  not sure
> what has changed for CP40)
>
> CP40 changed the assembly plugin to run in the verify phase so it can
> pick up any additional jars added to the package phase by component
> poms.
> [It's not possible to ensure the assembly plugin runs at the very end
> of the assembly phase - see COMMONSSITE-87]
>
> Releases should be generated using
>
> mvn deploy -Prelease
>
> 'mvn package' should still work for generating jars.
>
> > (And yes the release plugin and the commons procedure for releases is a
> match in hell ,)
>
> Not just Commons.
> Any project which allows multiple RCs for the same release is affected.
> The plugin works best where failed releases are abandoned and the
> version bumped for the next RC.
> It does not play well with retries.
>

I wonder how the maven-release-plugin team does this. Don't they run into
the same problems?


>
> [1] https://issues.apache.org/jira/browse/COMMONSSITE-87
>
> > Gruss
> > Bernd
> > --
> > http://bernd.eckenfels.net
> >
> > -Original Message-
> > From: Josh Elser 
> > To: Commons Developers List 
> > Sent: Do., 05 Mai 2016 6:49
> > Subject: Re: [VFS] WIP specific release instructions
> >
> >
> >
> > sebb wrote:
> >> Have a look at the scripts in
> >>
> >> http://svn.apache.org/viewvc/commons/scripts/
> >>
> >> I used those for VALIDATOR and NET.
> >
> > Cool. Thanks for sharing. It would be good if the generic commons
> > release documents referenced these if they are expected to be re-used by
> > other commons projects' RMs.
> >
> >> On 4 May 2016 at 04:43, Josh Elser  wrote:
> >>> Here's what I've been doing. The generic instructions are woefully
> >>> incomplete (before someone chimes in again - no, not just because "VFS
> is a
> >>> multi-module project"). I think I have this on point for rc1, so I'm
> writing
> >>> it down here before I forget (we can figure out where it *should* go
> later).
> >>>
> >>> rc0 only:
> >>> # Make the branch
> >>> $ svn cp trunk branches/VFS-XXX
> >>> $ cd branches/VFS-XXX
> >>> # Set the proper versions
> >>> $ mvn release:prepare
> >>
> >> We use a tag not a branch, but perhaps that is what the release plugin
> does.
> >> In which case I assume the branch is taken to avoid mangling trunk?
> >
> > release:prepare doesn't do the tagging (this is what release:perform
> > does). All it's really doing are some pre-condition checks and version
> > updates. TBQH, I don't have any idea how the maven-release-plugin and
> > SVN are remotely useful for the ASF's vote-then-promote process.
> >
> > That said, it's ok if I don't get it. This is what worked for me and I'm
> > happy with it. If there's something obvious I could have done
> > differently, great.
> >
> >>> ---
> >>>
> >>> # Or just set it to your JDK6 installation -- this works on OSX
> >>> $ export JAVA_HOME=$(/usr/libexec/java_home -v1.6)
> >>>
> >>> # Where ${asf.username} for me is "elserj"
> >>> $ mvn clean package -Duser.name=${asf.username}
> >>
> >> No need to use package if using CP40
> >
> > What are you using instead of `package` to build the code...
> >
> >>
> >>> # Set back to 1.7 because my 1.6 installation has trouble deploying to
> nexus
> >>> $ export JAVA_HOME=$(/usr/libexec/java_home -v1.7)
> >>
> >> So does mine; in which case use -Pjava-1.6 below.
> >>
> >>> $ mvn deploy -Prelease -Duser.name=${asf.username}
> >>>
> >>> # This is what could be consolidated via one invocation of `mvn site`
> >>> $ mvn site:site site:stage
> >>>
> >>> # Move back to the root SVN repo
> >>> $ cd ../..
> >>> $ svn cp branches/VFS-XXX tags/commons-vfs-project-XXX-rcN
> >>
> >> Isn't that what the release plugin does?
> >>
> >> You might find
> >>
> >> http://svn.apache.org/viewvc/commons/scripts/create_RC_tag.sh
> >>
> >> easier to use - it does it all for you without needing to create a
> >> temporary branch.
> >
> > Cool. I didn't find these from the generic commons release document.
> >
> >>> --
> >>>
> >>> Things not covered above:
> >>>
> >>> * Copying artifacts (tarballs/zips, xsums, and sigs) into
> >>> dist.a.o/dev/commons/... (building md5/sha1 files)
> >>> * Closing staging repo in Nexus
> >>
> >> That can be done using Nexus2DistDev.sh
> >
> > Again, great. It would have been good to know about these beforehand.
> >
> >>
> >>> --
> >>>
> >>> Some things that could still be improved that I didn't fix:
> >>>
> >>> * Artifacts in dist/target are renamed when they're
> installed/deployed, but
> >>> not in the local directory. Should do a rename of the file on disk so
> that
> >>> what is on the RM's computer matches what is in their m2 repo and ASF
> nexus.
> >>
> >> Or ignore the local copies and use Nexus2DistDev.sh which copies the
> >> bin/src artifacts from Nexus and deploys to dist/dev and can remove
> >> them from Nexus before closing the staging repo.
> >>
> >> AFAIK only the deploy dire

Re: [VFS] WIP specific release instructions

[sebb]

On 5 May 2016 at 13:29, Benedikt Ritter  wrote:
> sebb  schrieb am Do., 5. Mai 2016 um 13:55 Uhr:
>
>> On 5 May 2016 at 12:22,   wrote:
>> > Hello,
>> >
>> > BTW: I would use "mvn verify" instead of "mvn package" (I am  not sure
>> what has changed for CP40)
>>
>> CP40 changed the assembly plugin to run in the verify phase so it can
>> pick up any additional jars added to the package phase by component
>> poms.
>> [It's not possible to ensure the assembly plugin runs at the very end
>> of the assembly phase - see COMMONSSITE-87]
>>
>> Releases should be generated using
>>
>> mvn deploy -Prelease
>>
>> 'mvn package' should still work for generating jars.
>>
>> > (And yes the release plugin and the commons procedure for releases is a
>> match in hell ,)
>>
>> Not just Commons.
>> Any project which allows multiple RCs for the same release is affected.
>> The plugin works best where failed releases are abandoned and the
>> version bumped for the next RC.
>> It does not play well with retries.
>>
>
> I wonder how the maven-release-plugin team does this. Don't they run into
> the same problems?
>

The problems I can remember are:
- trunk is unconditionally updated to the next SNAPSHOT version.
This causes problems for components using CI builds (which may not be
the case for them).

- if an RC fails, trunk has to be reverted.
Since RC failures are quite common,  the process should be designed accordingly.
Subsequent CI builds will use an earlier SNAPSHOT version, which is confusing.

- does it create an immutable tag? I cannot work out from the docs
whether it appends RCn to the tag or not.
If not, then redoing a failed release as the next RC will require
deleting and recreating the tag, or abandoning that release version
and starting again with the next version number.
If it does create an RC tag, what name does it use for the SCM URLs?

- the local trunk workspace contains status files which need to be
preseved until the process is complete.


>>
>> [1] https://issues.apache.org/jira/browse/COMMONSSITE-87
>>
>> > Gruss
>> > Bernd
>> > --
>> > http://bernd.eckenfels.net
>> >
>> > -Original Message-
>> > From: Josh Elser 
>> > To: Commons Developers List 
>> > Sent: Do., 05 Mai 2016 6:49
>> > Subject: Re: [VFS] WIP specific release instructions
>> >
>> >
>> >
>> > sebb wrote:
>> >> Have a look at the scripts in
>> >>
>> >> http://svn.apache.org/viewvc/commons/scripts/
>> >>
>> >> I used those for VALIDATOR and NET.
>> >
>> > Cool. Thanks for sharing. It would be good if the generic commons
>> > release documents referenced these if they are expected to be re-used by
>> > other commons projects' RMs.
>> >
>> >> On 4 May 2016 at 04:43, Josh Elser  wrote:
>> >>> Here's what I've been doing. The generic instructions are woefully
>> >>> incomplete (before someone chimes in again - no, not just because "VFS
>> is a
>> >>> multi-module project"). I think I have this on point for rc1, so I'm
>> writing
>> >>> it down here before I forget (we can figure out where it *should* go
>> later).
>> >>>
>> >>> rc0 only:
>> >>> # Make the branch
>> >>> $ svn cp trunk branches/VFS-XXX
>> >>> $ cd branches/VFS-XXX
>> >>> # Set the proper versions
>> >>> $ mvn release:prepare
>> >>
>> >> We use a tag not a branch, but perhaps that is what the release plugin
>> does.
>> >> In which case I assume the branch is taken to avoid mangling trunk?
>> >
>> > release:prepare doesn't do the tagging (this is what release:perform
>> > does). All it's really doing are some pre-condition checks and version
>> > updates. TBQH, I don't have any idea how the maven-release-plugin and
>> > SVN are remotely useful for the ASF's vote-then-promote process.
>> >
>> > That said, it's ok if I don't get it. This is what worked for me and I'm
>> > happy with it. If there's something obvious I could have done
>> > differently, great.
>> >
>> >>> ---
>> >>>
>> >>> # Or just set it to your JDK6 installation -- this works on OSX
>> >>> $ export JAVA_HOME=$(/usr/libexec/java_home -v1.6)
>> >>>
>> >>> # Where ${asf.username} for me is "elserj"
>> >>> $ mvn clean package -Duser.name=${asf.username}
>> >>
>> >> No need to use package if using CP40
>> >
>> > What are you using instead of `package` to build the code...
>> >
>> >>
>> >>> # Set back to 1.7 because my 1.6 installation has trouble deploying to
>> nexus
>> >>> $ export JAVA_HOME=$(/usr/libexec/java_home -v1.7)
>> >>
>> >> So does mine; in which case use -Pjava-1.6 below.
>> >>
>> >>> $ mvn deploy -Prelease -Duser.name=${asf.username}
>> >>>
>> >>> # This is what could be consolidated via one invocation of `mvn site`
>> >>> $ mvn site:site site:stage
>> >>>
>> >>> # Move back to the root SVN repo
>> >>> $ cd ../..
>> >>> $ svn cp branches/VFS-XXX tags/commons-vfs-project-XXX-rcN
>> >>
>> >> Isn't that what the release plugin does?
>> >>
>> >> You might find
>> >>
>> >> http://svn.apache.org/viewvc/commons/scripts/create_RC_tag.sh
>> >>
>> >> easier to use - it does it all for you without needing to cre

Re: Maven Central slow to get new releases (was: [ANN] Apache Commons IO 2.5 Released)

[sebb]

The NET jars have finally arrived in Maven Central.

However they had to do a manual sync. and CDN flush, so it's not clear
when(if) the files would have arrived without manual intervention.


On 5 May 2016 at 10:03, Benedikt Ritter  wrote:
> sebb  schrieb am Do., 5. Mai 2016 um 11:02 Uhr:
>
>> The same has happened with Commons NET.
>>
>> 10 hours and still not available from Maven Central.
>>
>> According to the issue this is supposed to have been fixed ...
>>
>> I've updated the issue (but cannot re-open it).
>>
>
> Thank you for the update!
>
>
>>
>> S.
>> P.S. Even if this is fixed, we should still wait 12-24 hours after
>> publication to allow ASF mirrors to catch up.
>>
>> On 22 April 2016 at 12:39, Benson Margulies  wrote:
>> > https://issues.sonatype.org/browse/MVNCENTRAL-1060
>> >
>> > On Fri, Apr 22, 2016 at 7:36 AM, Kristian Rosenvold
>> >  wrote:
>> >> Looks like something is amiss with the central sync, the artifacts are
>> at
>> >>
>> https://repository.apache.org/content/groups/public/commons-io/commons-io/
>> >>
>> >> You probably need to file an issue with mvncentral.
>> >>
>> >> While you're at that, you can request in the same issue that all of the
>> >> "commons" artifacts be set at the new and improved central-synch
>> schedule,
>> >> which reduces the classic 4 hour delay to just a few minutes.
>> >
>> > -
>> > 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] Apache Commons VFS 2.1 rc1

[Ralph Goers]

Remember, as the release manager you get to decide whether any of this stuff is 
a blocker to the release. I can tell you for sure that VFS 2.0 wasn’t verified 
against this many different Java implementations and versions. Of course, the 
more testing the better!

I will try to inspect the release and vote on it this evening.

Ralph

> On May 4, 2016, at 9:43 PM, Josh Elser  wrote:
> 
> Thanks for investigating and sharing your findings, Jörg!
> 
> I guess commons-vfs has some room for improvement on IBM JDKs. I have been 
> using Oracle JDK6/7 here locally which has been fine. I think this would be 
> great to investigate further for future releases.
> 
> Jörg Schaible wrote:
>> Hi,
>> 
>> I've tried to build the release from the source tarball using my compiler
>> zoo.
>> 
>> Passes:
>>  - Sun JDK 1.6
>>  - IcedTea/OpenJDK 6
>>  - Oracle JDK 1.7
>>  - IcedTea/OpenJDK 7
>>  - Oracle JDK 1.8
>> 
>> Tests fail with IBM JDKs 1.6 and 1.7, IcedTea/OpenJDK 3 and Java 9:
>> 
>> = %<  ==
>> $ mvn-3.2 -version
>> Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1;
>> 2014-12-14T18:29:23+01:00)
>> Maven home: /usr/share/maven-bin-3.2
>> Java version: 1.6.0, vendor: IBM Corporation
>> Java home: /opt/ibm-jdk-bin-1.6.0.9_p2/jre
>> Default locale: en_US, platform encoding: UTF-8
>> OS name: "linux", version: "4.4.6-gentoo", arch: "amd64", family: "unix"
>> = %<  ==
>> Failed tests:
>> org.apache.commons.vfs2.impl.test.VfsClassLoaderTests.testGetResourcesJARs(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests)
>>   Run 1: PASS
>>   Run 2: PASS
>>   Run 3: PASS
>>   Run 4: PASS
>>   Run 5: PASS
>>   Run 6: PASS
>>   Run 7: PASS
>>   Run 8: PASS
>>   Run 9: VfsClassLoaderTests>AbstractProviderTestCase.runTest:218-
>>> testGetResourcesJARs:154 First resource must refer to nested.jar but was
>> jar:file:/opt/ibm-jdk-
>> bin-1.6.0.9_p2/jre/lib/amd64/default/jclSC160/vm.jar!/META-INF/MANIFEST.MF
>>   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
>> = %<  ==
>> $ mvn -version
>> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
>> 2015-11-10T17:41:47+01:00)
>> Maven home: /usr/share/maven-bin-3.3
>> Java version: 1.7.0, vendor: IBM Corporation
>> Java home: /opt/ibm-jdk-bin-1.7.0.5/jre
>> Default locale: en_US, platform encoding: UTF-8
>> OS name: "linux", version: "4.4.6-gentoo", arch: "amd64", family: "unix"
>> = %<  ==
>> Failed tests:
>> org.apache.commons.vfs2.impl.test.VfsClassLoaderTests.testGetResourcesJARs(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests)
>>   Run 1: PASS
>>   Run 2: PASS
>>   Run 3: PASS
>>   Run 4: PASS
>>   Run 5: PASS
>>   Run 6: PASS
>>   Run 7: PASS
>>   Run 8: PASS
>>   Run 9: VfsClassLoaderTests>AbstractProviderTestCase.runTest:218-
>>> testGetResourcesJARs:154 First resource must refer to nested.jar but was
>> jar:file:/opt/ibm-jdk-
>> bin-1.7.0.5/jre/lib/amd64/compressedrefs/jclSC170/vm.jar!/META-
>> INF/MANIFEST.MF
>>   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
>> = %<  ==
>> $ mvn -version
>> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
>> 2015-11-10T17:41:47+01:00)
>> Maven home: /usr/share/maven-bin-3.3
>> Java version: 1.8.0_77, vendor: Oracle Corporation
>> Java home: /opt/icedtea-bin-3.0.0/jre
>> Default locale: en_US, platform encoding: UTF-8
>> OS name: "linux", version: "4.4.6-gentoo", arch: "amd64", family: "unix"
>> = %<  ==
>> Tests in error:
>>   GetContentInfoFunctionalTest.testGoogle:76 » FileSystem Unknown message
>> with code "java.lang.RuntimeException:
>> java.security.NoSuchAlgorithmException: EC AlgorithmParameters not
>> available".
>> at
>> org.apache.commons.vfs2.provider.http.HttpFileContentInfoFactory.create(HttpFileContentInfoFactory.java:51)
>> at
>> org.apache.commons.vfs2.provider.DefaultFileContent.getContentInfo(DefaultFileContent.java:806)
>> at
>> org.apache.commons.vfs2.provider.https.test.GetContentInfoFunctionalTest.testGoogle(GetContentInfoFunctionalTest.java:76)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.

[ANNOUNCE] Apache Commons NET 3.5 released

[sebb]

The Apache Commons team are pleased to announce the release of
Commons Net version 3.5.

This is a bug fix release. All users are encouraged to upgrade to 3.5.

For details of the fixes and new features please see:

http://www.apache.org/dist/commons/net/RELEASE-NOTES.txt

[These are also included with the binary and source archives]

The changes are also available at:
http://commons.apache.org/net/changes-report.html

Binary and source archives are available from:

http://commons.apache.org/proper/commons-net/download_net.cgi

Please see the Apache Commons Net website for full details:

http://commons.apache.org/net/

The Maven coordinates are:

commons-net
commons-net
3.5

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

Re: [VFS] WIP specific release instructions

[Ralph Goers]

I really don’t know why you are making such a big deal about this.  I’ve been 
using the maven release plugin to release Log4j 2 for several years. That build 
was created based on the VFS 2.0 release process that also used the maven 
release plugin.  As I have said several times, releasing VFS is a lot harder 
than the rest of Commons because almost all are single module projects. Log4j 2 
has a ton of modules and doesn’t have any significant problems that can’t 
easily be dealt with.

The process Josh documented for the 2.release seems a bit more complicated than 
what I did for 2.0, but if it works for him, great.

Ralph


> On May 5, 2016, at 6:41 AM, sebb  wrote:
> 
> On 5 May 2016 at 13:29, Benedikt Ritter  > wrote:
>> sebb  schrieb am Do., 5. Mai 2016 um 13:55 Uhr:
>> 
>>> On 5 May 2016 at 12:22,   wrote:
 Hello,
 
 BTW: I would use "mvn verify" instead of "mvn package" (I am  not sure
>>> what has changed for CP40)
>>> 
>>> CP40 changed the assembly plugin to run in the verify phase so it can
>>> pick up any additional jars added to the package phase by component
>>> poms.
>>> [It's not possible to ensure the assembly plugin runs at the very end
>>> of the assembly phase - see COMMONSSITE-87]
>>> 
>>> Releases should be generated using
>>> 
>>> mvn deploy -Prelease
>>> 
>>> 'mvn package' should still work for generating jars.
>>> 
 (And yes the release plugin and the commons procedure for releases is a
>>> match in hell ,)
>>> 
>>> Not just Commons.
>>> Any project which allows multiple RCs for the same release is affected.
>>> The plugin works best where failed releases are abandoned and the
>>> version bumped for the next RC.
>>> It does not play well with retries.
>>> 
>> 
>> I wonder how the maven-release-plugin team does this. Don't they run into
>> the same problems?
>> 
> 
> The problems I can remember are:
> - trunk is unconditionally updated to the next SNAPSHOT version.
> This causes problems for components using CI builds (which may not be
> the case for them).
> 
> - if an RC fails, trunk has to be reverted.
> Since RC failures are quite common,  the process should be designed 
> accordingly.
> Subsequent CI builds will use an earlier SNAPSHOT version, which is confusing.
> 
> - does it create an immutable tag? I cannot work out from the docs
> whether it appends RCn to the tag or not.
> If not, then redoing a failed release as the next RC will require
> deleting and recreating the tag, or abandoning that release version
> and starting again with the next version number.
> If it does create an RC tag, what name does it use for the SCM URLs?
> 
> - the local trunk workspace contains status files which need to be
> preseved until the process is complete.
> 
> 
>>> 
>>> [1] https://issues.apache.org/jira/browse/COMMONSSITE-87
>>> 
 Gruss
 Bernd
 --
 http://bernd.eckenfels.net
 
 -Original Message-
 From: Josh Elser 
 To: Commons Developers List 
 Sent: Do., 05 Mai 2016 6:49
 Subject: Re: [VFS] WIP specific release instructions
 
 
 
 sebb wrote:
> Have a look at the scripts in
> 
> http://svn.apache.org/viewvc/commons/scripts/
> 
> I used those for VALIDATOR and NET.
 
 Cool. Thanks for sharing. It would be good if the generic commons
 release documents referenced these if they are expected to be re-used by
 other commons projects' RMs.
 
> On 4 May 2016 at 04:43, Josh Elser  wrote:
>> Here's what I've been doing. The generic instructions are woefully
>> incomplete (before someone chimes in again - no, not just because "VFS
>>> is a
>> multi-module project"). I think I have this on point for rc1, so I'm
>>> writing
>> it down here before I forget (we can figure out where it *should* go
>>> later).
>> 
>> rc0 only:
>> # Make the branch
>> $ svn cp trunk branches/VFS-XXX
>> $ cd branches/VFS-XXX
>> # Set the proper versions
>> $ mvn release:prepare
> 
> We use a tag not a branch, but perhaps that is what the release plugin
>>> does.
> In which case I assume the branch is taken to avoid mangling trunk?
 
 release:prepare doesn't do the tagging (this is what release:perform
 does). All it's really doing are some pre-condition checks and version
 updates. TBQH, I don't have any idea how the maven-release-plugin and
 SVN are remotely useful for the ASF's vote-then-promote process.
 
 That said, it's ok if I don't get it. This is what worked for me and I'm
 happy with it. If there's something obvious I could have done
 differently, great.
 
>> ---
>> 
>> # Or just set it to your JDK6 installation -- this works on OSX
>> $ export JAVA_HOME=$(/usr/libexec/java_home -v1.6)
>> 
>> # Where ${asf.username} for me is "elserj"
>> $ mvn clean package -Duser.name=${asf.username}
> 
> No need to use package if using CP40
 
>>

Re: [VFS] WIP specific release instructions

[sebb]

On 5 May 2016 at 17:08, Ralph Goers  wrote:
> I really don’t know why you are making such a big deal about this.

Because it's important that tags are immutable, and to to a lesser
degree to avoid creating spurious snapshot builds.

> I’ve been using the maven release plugin to release Log4j 2 for several 
> years. That build was created based on the VFS 2.0 release process that also 
> used the maven release plugin.  As I have said several times, releasing VFS 
> is a lot harder than the rest of Commons because almost all are single module 
> projects. Log4j 2 has a ton of modules and doesn’t have any significant 
> problems that can’t easily be dealt with.

However the Log4j tags have not been immutable.

Both 2.0.1 and 2.0.2 were updated after initial creation.

And the 2.0-beta8 tag was created and deleted several times.
There are other instances of mutable tags.

This means it may be tricky to demonstrate that the final tag
corresponds with what was actually voted on.

It also looks like 2.0 was created from trunk rather than either of the RCs.
As it happens, that vote passed first time so there was no need to recreate 2.0.
What would you have done if that vote had failed?


> The process Josh documented for the 2.release seems a bit more complicated 
> than what I did for 2.0, but if it works for him, great.
>
> Ralph
>
>
>> On May 5, 2016, at 6:41 AM, sebb  wrote:
>>
>> On 5 May 2016 at 13:29, Benedikt Ritter > > wrote:
>>> sebb  schrieb am Do., 5. Mai 2016 um 13:55 Uhr:
>>>
 On 5 May 2016 at 12:22,   wrote:
> Hello,
>
> BTW: I would use "mvn verify" instead of "mvn package" (I am  not sure
 what has changed for CP40)

 CP40 changed the assembly plugin to run in the verify phase so it can
 pick up any additional jars added to the package phase by component
 poms.
 [It's not possible to ensure the assembly plugin runs at the very end
 of the assembly phase - see COMMONSSITE-87]

 Releases should be generated using

 mvn deploy -Prelease

 'mvn package' should still work for generating jars.

> (And yes the release plugin and the commons procedure for releases is a
 match in hell ,)

 Not just Commons.
 Any project which allows multiple RCs for the same release is affected.
 The plugin works best where failed releases are abandoned and the
 version bumped for the next RC.
 It does not play well with retries.

>>>
>>> I wonder how the maven-release-plugin team does this. Don't they run into
>>> the same problems?
>>>
>>
>> The problems I can remember are:
>> - trunk is unconditionally updated to the next SNAPSHOT version.
>> This causes problems for components using CI builds (which may not be
>> the case for them).
>>
>> - if an RC fails, trunk has to be reverted.
>> Since RC failures are quite common,  the process should be designed 
>> accordingly.
>> Subsequent CI builds will use an earlier SNAPSHOT version, which is 
>> confusing.
>>
>> - does it create an immutable tag? I cannot work out from the docs
>> whether it appends RCn to the tag or not.
>> If not, then redoing a failed release as the next RC will require
>> deleting and recreating the tag, or abandoning that release version
>> and starting again with the next version number.
>> If it does create an RC tag, what name does it use for the SCM URLs?
>>
>> - the local trunk workspace contains status files which need to be
>> preseved until the process is complete.
>>
>>

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

> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
>
> -Original Message-
> From: Josh Elser 
> To: Commons Developers List 
> Sent: Do., 05 Mai 2016 6:49
> Subject: Re: [VFS] WIP specific release instructions
>
>
>
> sebb wrote:
>> Have a look at the scripts in
>>
>> http://svn.apache.org/viewvc/commons/scripts/
>>
>> I used those for VALIDATOR and NET.
>
> Cool. Thanks for sharing. It would be good if the generic commons
> release documents referenced these if they are expected to be re-used by
> other commons projects' RMs.
>
>> On 4 May 2016 at 04:43, Josh Elser  wrote:
>>> Here's what I've been doing. The generic instructions are woefully
>>> incomplete (before someone chimes in again - no, not just because "VFS
 is a
>>> multi-module project"). I think I have this on point for rc1, so I'm
 writing
>>> it down here before I forget (we can figure out where it *should* go
 later).
>>>
>>> rc0 only:
>>> # Make the branch
>>> $ svn cp trunk branches/VFS-XXX
>>> $ cd branches/VFS-XXX
>>> # Set the proper versions
>>> $ mvn release:prepare
>>
>> We use a tag not a branch, but perhaps that is what the release plugin
 does.
>> In which case I assume the branch is taken to avoid mangling trunk?
>
>

Re: [VFS] WIP specific release instructions

[Josh Elser]

sebb wrote:

On 5 May 2016 at 17:08, Ralph Goers  wrote:

>  I really don’t know why you are making such a big deal about this.


Because it's important that tags are immutable, and to to a lesser
degree to avoid creating spurious snapshot builds.



Yeah, it's ultimately so that I avoid having to constantly revert 
commits that I make as go (that release:perform would do). Makes me 
appreciate some more of the semantics of Git (but ignore that I said 
that before I spur a real religious debate ;))


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

Re: [VFS] WIP specific release instructions

[Josh Elser]

sebb wrote:

On 5 May 2016 at 05:49, Josh Elser  wrote:


sebb wrote:

Have a look at the scripts in

http://svn.apache.org/viewvc/commons/scripts/

I used those for VALIDATOR and NET.


Cool. Thanks for sharing. It would be good if the generic commons release
documents referenced these if they are expected to be re-used by other
commons projects' RMs.


They are brand new, and possibly still needing some tweaks.
They don't work wit Git.


Gotcha. Makes sense. Thanks for bringing them up.




---

# Or just set it to your JDK6 installation -- this works on OSX
$ export JAVA_HOME=$(/usr/libexec/java_home -v1.6)

# Where ${asf.username} for me is "elserj"
$ mvn clean package -Duser.name=${asf.username}


No need to use package if using CP40


What are you using instead of `package` to build the code...


mvn deploy



Oh ok. I understand what you meant now. A package is still running, 
you're just not explicitly invoking it.



--

Some things that could still be improved that I didn't fix:

* Artifacts in dist/target are renamed when they're installed/deployed,
but
not in the local directory. Should do a rename of the file on disk so
that
what is on the RM's computer matches what is in their m2 repo and ASF
nexus.


Or ignore the local copies and use Nexus2DistDev.sh which copies the
bin/src artifacts from Nexus and deploys to dist/dev and can remove
them from Nexus before closing the staging repo.

AFAIK only the deploy directory (i.e. Nexus) has the hashes.


* `mvn site` which invokes site:site and site:stage automatically (which
would make for a more natural build process -- `mvn deploy` would build
the
site automatically)


I don't follow that.


`mvn site` is invoking the "site" maven lifecycle phase. "mvn site:site` and
`mvn site:stage` are invoking executions on the maven-site-plugin. These are
two distinct kinds of actions. We can configure the maven-site-plugin
(and/or other necessary tasks) to run at the 'site' lifecycle phase for a
more 'natural' process.



I see.

I meant I did not see why 'mvn deploy ' would/should create the site.


Ah, ok. (with some steps omitted) The lifecycle phases are: package -> 
verify -> install -> site -> deploy. Running a deploy also implies that 
the site is built.



Again, for now, this is just for my benefit. When this is all over, I'll
try
to add this all to the website. Please point out anything wrong/missing.
Thanks.



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

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Josh Elser]

Stian Soiland-Reyes wrote:

"EC AlgorithmParameters not available" seems to be a OpenJDK bug
because Elastic Curves relies on the sunec native library -
http://armoredbarista.blogspot.co.uk/2013/10/how-to-use-ecc-with-openjdk.html


Presumably this would also fail in those JDKs?

URL url = new java.net.URL("https://www.google.com/images/logos/ps_logo2.png";);
url.openConnection();


We can modify https/test/GetContentInfoFunctionalTest to not rely on
fetching https://www.google.com/images/logos/ps_logo2.png - this
sounds a bit fragile to me anyway - for how long would that file
remain available?


There was a test that I @Ignored because it was doing the same thing 
(reaching out to the internet, for some file/endpoint which no longer 
exists). See VFS-600.


I see you already pushed a fix for it too! Awesome :)


If we need to do an external test, then we should use say
https://www.apache.org/licenses/LICENSE-2.0.txt

Obviously if INFRA changes the SSL configuration there to also request
Elastic Curves, then the test could still fail.


Tracked as https://issues.apache.org/jira/browse/VFS-605
and fix committed on trunk to instead test against
https://www.apache.org/licenses/LICENSE-2.0.tx

Could you verify if trunk builds on icedtea-bin-3.0.0 and IBM JDK?


On 4 May 2016 at 23:39, Jörg Schaible  wrote:

Hi,

I've tried to build the release from the source tarball using my compiler
zoo.

Passes:
  - Sun JDK 1.6
  - IcedTea/OpenJDK 6
  - Oracle JDK 1.7
  - IcedTea/OpenJDK 7
  - Oracle JDK 1.8

Tests fail with IBM JDKs 1.6 and 1.7, IcedTea/OpenJDK 3 and Java 9:

= %<  ==
$ mvn-3.2 -version
Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1;
2014-12-14T18:29:23+01:00)
Maven home: /usr/share/maven-bin-3.2
Java version: 1.6.0, vendor: IBM Corporation
Java home: /opt/ibm-jdk-bin-1.6.0.9_p2/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.6-gentoo", arch: "amd64", family: "unix"
= %<  ==
Failed tests:
org.apache.commons.vfs2.impl.test.VfsClassLoaderTests.testGetResourcesJARs(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests)
   Run 1: PASS
   Run 2: PASS
   Run 3: PASS
   Run 4: PASS
   Run 5: PASS
   Run 6: PASS
   Run 7: PASS
   Run 8: PASS
   Run 9: VfsClassLoaderTests>AbstractProviderTestCase.runTest:218-

testGetResourcesJARs:154 First resource must refer to nested.jar but was

jar:file:/opt/ibm-jdk-
bin-1.6.0.9_p2/jre/lib/amd64/default/jclSC160/vm.jar!/META-INF/MANIFEST.MF
   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
= %<  ==
$ mvn -version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T17:41:47+01:00)
Maven home: /usr/share/maven-bin-3.3
Java version: 1.7.0, vendor: IBM Corporation
Java home: /opt/ibm-jdk-bin-1.7.0.5/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.6-gentoo", arch: "amd64", family: "unix"
= %<  ==
Failed tests:
org.apache.commons.vfs2.impl.test.VfsClassLoaderTests.testGetResourcesJARs(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests)
   Run 1: PASS
   Run 2: PASS
   Run 3: PASS
   Run 4: PASS
   Run 5: PASS
   Run 6: PASS
   Run 7: PASS
   Run 8: PASS
   Run 9: VfsClassLoaderTests>AbstractProviderTestCase.runTest:218-

testGetResourcesJARs:154 First resource must refer to nested.jar but was

jar:file:/opt/ibm-jdk-
bin-1.7.0.5/jre/lib/amd64/compressedrefs/jclSC170/vm.jar!/META-
INF/MANIFEST.MF
   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
= %<  ==
$ mvn -version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T17:41:47+01:00)
Maven home: /usr/share/maven-bin-3.3
Java version: 1.8.0_77, vendor: Oracle Corporation
Java home: /opt/icedtea-bin-3.0.0/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.6-gentoo", arch: "amd64", family: "unix"
= %<  ==
Tests in error:
   GetContentInfoFunctionalTest.testGoogle:76 » FileSystem Unknown message
with code "java.lang.RuntimeException:
java.security.NoSuchAlgorithmException: EC AlgorithmParameters not
available".
 at
org.apache.commons.vfs2.provider.http.HttpFileContentInfoFactory.create(HttpFileContentInfoFactory.java:51)
 at
org.apache.commons.vfs2.provider.DefaultFileContent.getContentInfo(DefaultFileContent.java:806)
 at
org.apache.commons.vfs2.provider.https.test.GetContentInfoFunct

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Josh Elser]

Oh, well then! No pressure :)

I'll have to find some time to re-read all of the conversation between 
Jörg and Stian, but my initial reaction is the same as what you were 
implying: compatibility across more JVMs would be great, but shouldn't 
block this 2.1 release.


The other points seem to be "nice to have"'s, but please bring it to my 
attention is my quick glance missed something that is really bad.


Ralph Goers wrote:

Remember, as the release manager you get to decide whether any of this stuff is 
a blocker to the release. I can tell you for sure that VFS 2.0 wasn’t verified 
against this many different Java implementations and versions. Of course, the 
more testing the better!

I will try to inspect the release and vote on it this evening.

Ralph


On May 4, 2016, at 9:43 PM, Josh Elser  wrote:

Thanks for investigating and sharing your findings, Jörg!

I guess commons-vfs has some room for improvement on IBM JDKs. I have been 
using Oracle JDK6/7 here locally which has been fine. I think this would be 
great to investigate further for future releases.

Jörg Schaible wrote:

Hi,

I've tried to build the release from the source tarball using my compiler
zoo.

Passes:
  - Sun JDK 1.6
  - IcedTea/OpenJDK 6
  - Oracle JDK 1.7
  - IcedTea/OpenJDK 7
  - Oracle JDK 1.8

Tests fail with IBM JDKs 1.6 and 1.7, IcedTea/OpenJDK 3 and Java 9:

= %<   ==
$ mvn-3.2 -version
Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1;
2014-12-14T18:29:23+01:00)
Maven home: /usr/share/maven-bin-3.2
Java version: 1.6.0, vendor: IBM Corporation
Java home: /opt/ibm-jdk-bin-1.6.0.9_p2/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.6-gentoo", arch: "amd64", family: "unix"
= %<   ==
Failed tests:
org.apache.commons.vfs2.impl.test.VfsClassLoaderTests.testGetResourcesJARs(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests)
   Run 1: PASS
   Run 2: PASS
   Run 3: PASS
   Run 4: PASS
   Run 5: PASS
   Run 6: PASS
   Run 7: PASS
   Run 8: PASS
   Run 9: VfsClassLoaderTests>AbstractProviderTestCase.runTest:218-

testGetResourcesJARs:154 First resource must refer to nested.jar but was

jar:file:/opt/ibm-jdk-
bin-1.6.0.9_p2/jre/lib/amd64/default/jclSC160/vm.jar!/META-INF/MANIFEST.MF
   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
= %<   ==
$ mvn -version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T17:41:47+01:00)
Maven home: /usr/share/maven-bin-3.3
Java version: 1.7.0, vendor: IBM Corporation
Java home: /opt/ibm-jdk-bin-1.7.0.5/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.6-gentoo", arch: "amd64", family: "unix"
= %<   ==
Failed tests:
org.apache.commons.vfs2.impl.test.VfsClassLoaderTests.testGetResourcesJARs(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests)
   Run 1: PASS
   Run 2: PASS
   Run 3: PASS
   Run 4: PASS
   Run 5: PASS
   Run 6: PASS
   Run 7: PASS
   Run 8: PASS
   Run 9: VfsClassLoaderTests>AbstractProviderTestCase.runTest:218-

testGetResourcesJARs:154 First resource must refer to nested.jar but was

jar:file:/opt/ibm-jdk-
bin-1.7.0.5/jre/lib/amd64/compressedrefs/jclSC170/vm.jar!/META-
INF/MANIFEST.MF
   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
= %<   ==
$ mvn -version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T17:41:47+01:00)
Maven home: /usr/share/maven-bin-3.3
Java version: 1.8.0_77, vendor: Oracle Corporation
Java home: /opt/icedtea-bin-3.0.0/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.6-gentoo", arch: "amd64", family: "unix"
= %<   ==
Tests in error:
   GetContentInfoFunctionalTest.testGoogle:76 » FileSystem Unknown message
with code "java.lang.RuntimeException:
java.security.NoSuchAlgorithmException: EC AlgorithmParameters not
available".
 at
org.apache.commons.vfs2.provider.http.HttpFileContentInfoFactory.create(HttpFileContentInfoFactory.java:51)
 at
org.apache.commons.vfs2.provider.DefaultFileContent.getContentInfo(DefaultFileContent.java:806)
 at
org.apache.commons.vfs2.provider.https.test.GetContentInfoFunctionalTest.testGoogle(GetContentInfoFunctionalTest.java:76)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62

How to upload component site to home.apache.org for release vote?

[Benedikt Ritter]

Hi,

how do you upload a component site to home.apache.org? people.apache.org
hat ssh access. I always uploaded a tar via scp and then logged in via ssh
for unpacking. home.apache.org does not have ssh access. What tools do you
use to upload the component site?

Benedikt

Re: [VALIDATOR] CheckDigit implementation for German identity cards?

[Benedikt Ritter]

Benedikt Ritter  schrieb am Di., 3. Mai 2016 um
22:49 Uhr:

> Hello,
>
> I have the need for a validator implementation that can check German
> identity card numbers. It's pretty simple to implement something like this
> using ModulusCheckDigit. Now I'm wondering whether this would be a good
> addition for [validator]. It is specific to German identity cards, but
> maybe we could start an idcard package which contains routine for different
> country identity cards.
>
> If this doesn't belong into [validator] I'll probably publish it via my
> github account :-)
>

A CheckDigit implementation for German identity card numbers would look
like this: https://gist.github.com/britter/ff959c42cab142a828247ce0673f6215


>
> Best regards,
> Benedikt
>
>

Re: [VALIDATOR] CheckDigit implementation for German identity cards?

[Gary Gregory]

I wonder if we should have packages for various country codes like
o.a.c.validator.de ? Then this class would go in there.

Gary

On Thu, May 5, 2016 at 12:46 PM, Benedikt Ritter  wrote:

> Benedikt Ritter  schrieb am Di., 3. Mai 2016 um
> 22:49 Uhr:
>
> > Hello,
> >
> > I have the need for a validator implementation that can check German
> > identity card numbers. It's pretty simple to implement something like
> this
> > using ModulusCheckDigit. Now I'm wondering whether this would be a good
> > addition for [validator]. It is specific to German identity cards, but
> > maybe we could start an idcard package which contains routine for
> different
> > country identity cards.
> >
> > If this doesn't belong into [validator] I'll probably publish it via my
> > github account :-)
> >
>
> A CheckDigit implementation for German identity card numbers would look
> like this:
> https://gist.github.com/britter/ff959c42cab142a828247ce0673f6215
>
>
> >
> > Best regards,
> > Benedikt
> >
> >
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: How to upload component site to home.apache.org for release vote?

[Matt Sicker]

You can use sftp or maybe eve sshfs from fuse (available on Linux and Mac
OS X, maybe Windows?).

On 5 May 2016 at 14:33, Benedikt Ritter  wrote:

> Hi,
>
> how do you upload a component site to home.apache.org? people.apache.org
> hat ssh access. I always uploaded a tar via scp and then logged in via ssh
> for unpacking. home.apache.org does not have ssh access. What tools do you
> use to upload the component site?
>
> Benedikt
>



-- 
Matt Sicker 

Re: [LANG] Failing tests

[Benedikt Ritter]

Benedikt Ritter  schrieb am Mo., 2. Mai 2016 um
12:44 Uhr:

> I'm building with:
>
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> 2015-11-10T17:41:47+01:00)
> Maven home: /usr/local/Cellar/maven/3.3.9/libexec
> Java version: 1.8.0_65, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_65.jdk/Contents/Home/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.11.4", arch: "x86_64", family: "mac"
>
> I'll have more time to investigate this evening.
>

It works on builds.apache.org so I think it has something to do with my
local setup.


>
> Benedikt
>
> Chas Honton  schrieb am Mo., 2. Mai 2016 um 08:24 Uhr:
>
>> The line number makes it look like the  Parameterized values are not
>> being properly set by junit. Is it possible that we're using a new parent
>> Pom that doesn't fully configure junit plugin version?  What version of
>> maven are you using?
>>
>> I just successfully built from tip on a Mac using maven 3.3.9 and Java
>> 1.8.0_92.
>>
>> Chas
>>
>> > On May 1, 2016, at 12:20 PM, sebb  wrote:
>> >
>> >> On 1 May 2016 at 19:32, Benedikt Ritter  wrote:
>> >> Hi,
>> >>
>> >> when building a clean checkout of Commons LANG, I get a lot of failing
>> >> tests:
>> >
>> > OS?
>> > Java?
>> >
>> >> Tests in error:
>> >>  FastDateFormat_ParserTest>FastDateParserTest.testTzParses:265 »
>> >> NullPointer
>> >>  FastDateParserSDFTest.testLowerCasePP:149->checkParsePosition:195 »
>> >> NullPointer
>> >>  FastDateParserSDFTest.testLowerCasePP:149->checkParsePosition:195 »
>> >> NullPointer
>> >>  FastDateParserSDFTest.testLowerCasePP:149->checkParsePosition:195 »
>> >> NullPointer
>> >>  FastDateParserSDFTest.testLowerCasePP:149->checkParsePosition:195 »
>> >> NullPointer
>> >>  FastDateParserSDFTest.testLowerCasePP:149->checkParsePosition:195 »
>> >> NullPointer
>> >>  FastDateParserSDFTest.testLowerCasePP:149->checkParsePosition:195 »
>> >> NullPointer
>> >>  FastDateParserSDFTest.testLowerCasePP:149->checkParsePosition:195 »
>> >> NullPointer
>> >>  FastDateParserSDFTest.testLowerCasePP:149->checkParsePosition:195 »
>> >> NullPointer
>> >>  FastDateParserSDFTest.testLowerCase:144->checkParse:155 » NullPointer
>> >>  FastDateParserSDFTest.testLowerCase:144->checkParse:155 » NullPointer
>> >>  FastDateParserSDFTest.testLowerCase:144->checkParse:155 » NullPointer
>> >>  FastDateParserSDFTest.testLowerCase:144->checkParse:155 » NullPointer
>> >>  FastDateParserSDFTest.testLowerCase:144->checkParse:155 » NullPointer
>> >>  FastDateParserSDFTest.testLowerCase:144->checkParse:155 » NullPointer
>> >>  FastDateParserSDFTest.testLowerCase:144->checkParse:155 » NullPointer
>> >>  FastDateParserSDFTest.testLowerCase:144->checkParse:155 » NullPointer
>> >>  FastDateParserSDFTest.testOriginalPP:129->checkParsePosition:195 »
>> >> NullPointer
>> >>  FastDateParserSDFTest.testOriginalPP:129->checkParsePosition:195 »
>> >> NullPointer
>> >>  FastDateParserSDFTest.testOriginalPP:129->checkParsePosition:195 »
>> >> NullPointer
>> >>  FastDateParserSDFTest.testOriginalPP:129->checkParsePosition:195 »
>> >> NullPointer
>> >>  FastDateParserSDFTest.testOriginalPP:129->checkParsePosition:195 »
>> >> NullPointer
>> >>  FastDateParserSDFTest.testOriginalPP:129->checkParsePosition:195 »
>> >> NullPointer
>> >>  FastDateParserSDFTest.testOriginalPP:129->checkParsePosition:195 »
>> >> NullPointer
>> >>  FastDateParserSDFTest.testOriginalPP:129->checkParsePosition:195 »
>> >> NullPointer
>> >>  FastDateParserSDFTest.testOriginal:124->checkParse:155 » NullPointer
>> >>  FastDateParserSDFTest.testOriginal:124->checkParse:155 » NullPointer
>> >>  FastDateParserSDFTest.testOriginal:124->checkParse:155 » NullPointer
>> >>  FastDateParserSDFTest.testOriginal:124->checkParse:155 » NullPointer
>> >>  FastDateParserSDFTest.testOriginal:124->checkParse:155 » NullPointer
>> >>  FastDateParserSDFTest.testOriginal:124->checkParse:155 » NullPointer
>> >>  FastDateParserSDFTest.testOriginal:124->checkParse:155 » NullPointer
>> >>  FastDateParserSDFTest.testOriginal:124->checkParse:155 » NullPointer
>> >>  FastDateParserSDFTest.testUpperCasePP:139->checkParsePosition:195 »
>> >> NullPointer
>> >>  FastDateParserSDFTest.testUpperCasePP:139->checkParsePosition:195 »
>> >> NullPointer
>> >>  FastDateParserSDFTest.testUpperCasePP:139->checkParsePosition:195 »
>> >> NullPointer
>> >>  FastDateParserSDFTest.testUpperCasePP:139->checkParsePosition:195 »
>> >> NullPointer
>> >>  FastDateParserSDFTest.testUpperCasePP:139->checkParsePosition:195 »
>> >> NullPointer
>> >>  FastDateParserSDFTest.testUpperCasePP:139->checkParsePosition:195 »
>> >> NullPointer
>> >>  FastDateParserSDFTest.testUpperCasePP:139->checkParsePosition:195 »
>> >> NullPointer
>> >>  FastDateParserSDFTest.testUpperCasePP:139->checkParsePosition:195 »
>> >> NullPointer
>> >>  FastDateParserSDFTest.testUpperCase:134->checkParse:155 » NullPointer
>> >>  FastDateParserSDFTest.testUpperCase:134->checkParse:155 » 

Re: How to upload component site to home.apache.org for release vote?

[Benedikt Ritter]

Hello Matt,

Matt Sicker  schrieb am Do., 5. Mai 2016 um 21:54 Uhr:

> You can use sftp or maybe eve sshfs from fuse (available on Linux and Mac
> OS X, maybe Windows?).
>

I'm giving FileZilla a try. That should do the trick :-)

Thank you!


>
> On 5 May 2016 at 14:33, Benedikt Ritter  wrote:
>
> > Hi,
> >
> > how do you upload a component site to home.apache.org? people.apache.org
> > hat ssh access. I always uploaded a tar via scp and then logged in via
> ssh
> > for unpacking. home.apache.org does not have ssh access. What tools do
> you
> > use to upload the component site?
> >
> > Benedikt
> >
>
>
>
> --
> Matt Sicker 
>

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Jörg Schaible]

Hi Stian,

Stian Soiland-Reyes wrote:

> No, it shouldn't matter the class loader content to do a normal https
> connection, should it? Or do you consider that optional support from
> the JDK? In that case the tests would need to test for https
> capability first and ignore themselves if the JDK doesn't support SSL.

What has HTTPS to do with the failing 
VfsClassLoaderTests.testGetResourcesJARs for the IBM JDKs?

> Is this the latest IBM JDK patch release..?

No, I don't think so ...

Cheers,
Jörg


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

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Jörg Schaible]

Hi Ralph,

Ralph Goers wrote:

> Remember, as the release manager you get to decide whether any of this
> stuff is a blocker to the release. I can tell you for sure that VFS 2.0
> wasn’t verified against this many different Java implementations and
> versions.

Well, you're wrong: 
http://article.gmane.org/gmane.comp.jakarta.commons.devel/116497

> Of course, the more testing the better!

Of course, Java 8 and 9 did not exist, but we dropped support for JHDK 5 now 
;-)

Cheers,
Jörg


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

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Jörg Schaible]

Hi Josh,

Josh Elser wrote:

> Oh, well then! No pressure :)
> 
> I'll have to find some time to re-read all of the conversation between
> Jörg and Stian, but my initial reaction is the same as what you were
> implying: compatibility across more JVMs would be great, but shouldn't
> block this 2.1 release.

This depends always on the nature of a problem. Therefore I did not make any 
vote for now. Currently it looks like you're right and thanks to Stian the 
problems are covered in trunk on top (sole the problem with the IBM JDKs).

> The other points seem to be "nice to have"'s, but please bring it to my
> attention is my quick glance missed something that is really bad.

Cheers,
Jörg


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

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Jörg Schaible]

Hi Stian,

Stian Soiland-Reyes wrote:

> Thanks, I've added ${hadoop.version} so it's easier to upgrade in the
> future, and also committed the  of tools.jar
> 
> 
> I think the maven-jar-maven JDK9 issue is due to
> https://issues.apache.org/jira/browse/MJAR-206
> https://issues.apache.org/jira/browse/MJAR-205
> 
> so you would need to wait for maven-jar-plugin 3.0.0

I faced the same problem when I tested the release for commons-net earlier 
this week. At least there's nothing to blame for vfs.

> Not sure about the JspRuntimeContext class cast exception..
> 
> jdk.internal.loader.ClassLoaders$AppClassLoader (in module: java.base)
> cannot be cast to java.net.URLClassLoader
> 
> sounds like a bit naive casting by Jasper.  Perhaps we would then also
> need to force a newer version - this is PRETTY old:
> 
> [INFO] |  +- tomcat:jasper-compiler:jar:5.5.23:test
> [INFO] |  +- tomcat:jasper-runtime:jar:5.5.23:test
> 
> (This version is also coming in as a Hadoop test dependency)
> 
> Fixed in Tomcat 8.0.0 at least:
> 
> 
https://github.com/apache/tomcat/blob/TOMCAT_8_0_0/java/org/apache/jasper/compiler/JspRuntimeContext.java#L403
>

Fine. Again, we cannot blame vfs. I was just a bit astonished when I saw the 
stack trace on the console and later on Maven claimed a successful build.

Cheers,
Jörg



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

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Jörg Schaible]

Jörg Schaible wrote:

> Hi Josh,
> 
> Josh Elser wrote:
> 
>> Oh, well then! No pressure :)
>> 
>> I'll have to find some time to re-read all of the conversation between
>> Jörg and Stian, but my initial reaction is the same as what you were
>> implying: compatibility across more JVMs would be great, but shouldn't
>> block this 2.1 release.

Just an additional remark: Compatibility across more JVMs *is* an issue, 
since there are platforms where you have no other choice (IBM AIX, Mac, most 
Linux distributions use OpenJDK by default).

> This depends always on the nature of a problem. Therefore I did not make
> any vote for now. Currently it looks like you're right and thanks to Stian
> the problems are covered in trunk on top (sole the problem with the IBM
> JDKs).
> 
>> The other points seem to be "nice to have"'s, but please bring it to my
>> attention is my quick glance missed something that is really bad.
> 
> Cheers,
> Jörg



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

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Josh Elser]

Jörg Schaible wrote:

Jörg Schaible wrote:


>  Hi Josh,
>
>  Josh Elser wrote:
>

>>  Oh, well then! No pressure:)
>>
>>  I'll have to find some time to re-read all of the conversation between
>>  Jörg and Stian, but my initial reaction is the same as what you were
>>  implying: compatibility across more JVMs would be great, but shouldn't
>>  block this 2.1 release.


Just an additional remark: Compatibility across more JVMs*is*  an issue,
since there are platforms where you have no other choice (IBM AIX, Mac, most
Linux distributions use OpenJDK by default).



Is 2.1's compatibility across JVMs worse than 2.0's was? What are the 
guarantees put forth by those involved with commons-vfs for 
compatibility WRT JVMs?


I'm not nit-picking JVM support -- I'm nit-picking it's severity to 
block v2.1 for being released.


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

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Gary Gregory]

If the RM is willing, there is always the RERO route and getting a 2.1.1
out next to address JRE/JVM compat. issues if those are fixable at all from
VFS in a not too hacky manner.

Gary
On May 5, 2016 5:41 PM, "Josh Elser"  wrote:

> Jörg Schaible wrote:
>
>> Jörg Schaible wrote:
>>
>> >  Hi Josh,
>>> >
>>> >  Josh Elser wrote:
>>> >
>>>
 >>  Oh, well then! No pressure:)
 >>
 >>  I'll have to find some time to re-read all of the conversation
 between
 >>  Jörg and Stian, but my initial reaction is the same as what you were
 >>  implying: compatibility across more JVMs would be great, but
 shouldn't
 >>  block this 2.1 release.

>>>
>> Just an additional remark: Compatibility across more JVMs*is*  an issue,
>> since there are platforms where you have no other choice (IBM AIX, Mac,
>> most
>> Linux distributions use OpenJDK by default).
>>
>>
> Is 2.1's compatibility across JVMs worse than 2.0's was? What are the
> guarantees put forth by those involved with commons-vfs for compatibility
> WRT JVMs?
>
> I'm not nit-picking JVM support -- I'm nit-picking it's severity to block
> v2.1 for being released.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Ralph Goers]

Wow, I have no recollection of that email. But I have read a lot of emails over 
the last 6 years.

Ralph

> On May 5, 2016, at 3:05 PM, Jörg Schaible  wrote:
> 
> Hi Ralph,
> 
> Ralph Goers wrote:
> 
>> Remember, as the release manager you get to decide whether any of this
>> stuff is a blocker to the release. I can tell you for sure that VFS 2.0
>> wasn’t verified against this many different Java implementations and
>> versions.
> 
> Well, you're wrong: 
> http://article.gmane.org/gmane.comp.jakarta.commons.devel/116497
> 
>> Of course, the more testing the better!
> 
> Of course, Java 8 and 9 did not exist, but we dropped support for JHDK 5 now 
> ;-)
> 
> Cheers,
> Jörg
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 



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

Re: [VFS] WIP specific release instructions

[Ralph Goers]

We have never deleted a tag once a vote passed.  Now that tags are immutable we 
are using rcn tags and then creating a release tag when the vote passes. But we 
are still just using the release plugin.

Ralph

> On May 5, 2016, at 9:49 AM, sebb  wrote:
> 
> On 5 May 2016 at 17:08, Ralph Goers  > wrote:
>> I really don’t know why you are making such a big deal about this.
> 
> Because it's important that tags are immutable, and to to a lesser
> degree to avoid creating spurious snapshot builds.
> 
>> I’ve been using the maven release plugin to release Log4j 2 for several 
>> years. That build was created based on the VFS 2.0 release process that also 
>> used the maven release plugin.  As I have said several times, releasing VFS 
>> is a lot harder than the rest of Commons because almost all are single 
>> module projects. Log4j 2 has a ton of modules and doesn’t have any 
>> significant problems that can’t easily be dealt with.
> 
> However the Log4j tags have not been immutable.
> 
> Both 2.0.1 and 2.0.2 were updated after initial creation.
> 
> And the 2.0-beta8 tag was created and deleted several times.
> There are other instances of mutable tags.
> 
> This means it may be tricky to demonstrate that the final tag
> corresponds with what was actually voted on.
> 
> It also looks like 2.0 was created from trunk rather than either of the RCs.
> As it happens, that vote passed first time so there was no need to recreate 
> 2.0.
> What would you have done if that vote had failed?
> 
> 
>> The process Josh documented for the 2.release seems a bit more complicated 
>> than what I did for 2.0, but if it works for him, great.
>> 
>> Ralph
>> 
>> 
>>> On May 5, 2016, at 6:41 AM, sebb >> > wrote:
>>> 
>>> On 5 May 2016 at 13:29, Benedikt Ritter >>  >> >> wrote:
 sebb  schrieb am Do., 5. Mai 2016 um 13:55 Uhr:
 
> On 5 May 2016 at 12:22,   wrote:
>> Hello,
>> 
>> BTW: I would use "mvn verify" instead of "mvn package" (I am  not sure
> what has changed for CP40)
> 
> CP40 changed the assembly plugin to run in the verify phase so it can
> pick up any additional jars added to the package phase by component
> poms.
> [It's not possible to ensure the assembly plugin runs at the very end
> of the assembly phase - see COMMONSSITE-87]
> 
> Releases should be generated using
> 
> mvn deploy -Prelease
> 
> 'mvn package' should still work for generating jars.
> 
>> (And yes the release plugin and the commons procedure for releases is a
> match in hell ,)
> 
> Not just Commons.
> Any project which allows multiple RCs for the same release is affected.
> The plugin works best where failed releases are abandoned and the
> version bumped for the next RC.
> It does not play well with retries.
> 
 
 I wonder how the maven-release-plugin team does this. Don't they run into
 the same problems?
 
>>> 
>>> The problems I can remember are:
>>> - trunk is unconditionally updated to the next SNAPSHOT version.
>>> This causes problems for components using CI builds (which may not be
>>> the case for them).
>>> 
>>> - if an RC fails, trunk has to be reverted.
>>> Since RC failures are quite common,  the process should be designed 
>>> accordingly.
>>> Subsequent CI builds will use an earlier SNAPSHOT version, which is 
>>> confusing.
>>> 
>>> - does it create an immutable tag? I cannot work out from the docs
>>> whether it appends RCn to the tag or not.
>>> If not, then redoing a failed release as the next RC will require
>>> deleting and recreating the tag, or abandoning that release version
>>> and starting again with the next version number.
>>> If it does create an RC tag, what name does it use for the SCM URLs?
>>> 
>>> - the local trunk workspace contains status files which need to be
>>> preseved until the process is complete.
>>> 
>>> 
> 
> [1] https://issues.apache.org/jira/browse/COMMONSSITE-87
> 
>> Gruss
>> Bernd
>> --
>> http://bernd.eckenfels.net
>> 
>> -Original Message-
>> From: Josh Elser 
>> To: Commons Developers List 
>> Sent: Do., 05 Mai 2016 6:49
>> Subject: Re: [VFS] WIP specific release instructions
>> 
>> 
>> 
>> sebb wrote:
>>> Have a look at the scripts in
>>> 
>>> http://svn.apache.org/viewvc/commons/scripts/
>>> 
>>> I used those for VALIDATOR and NET.
>> 
>> Cool. Thanks for sharing. It would be good if the generic commons
>> release documents referenced these if they are expected to be re-used by
>> other commons projects' RMs.
>> 
>>> On 4 May 2016 at 04:43, Josh Elser  wrote:
 Here's what I've been doing. The generic instructions are woefully
 incomplete (before someone chimes in again - no, not just beca

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Jörg Schaible]

Hi Josh,

Josh Elser wrote:

> Jörg Schaible wrote:
>> Jörg Schaible wrote:
>>
>>> >  Hi Josh,
>>> >
>>> >  Josh Elser wrote:
>>> >
 >>  Oh, well then! No pressure:)
 >>
 >>  I'll have to find some time to re-read all of the conversation
 >>  between Jörg and Stian, but my initial reaction is the same as what
 >>  you were implying: compatibility across more JVMs would be great,
 >>  but shouldn't block this 2.1 release.
>>
>> Just an additional remark: Compatibility across more JVMs*is*  an issue,
>> since there are platforms where you have no other choice (IBM AIX, Mac,
>> most Linux distributions use OpenJDK by default).
>>
> 
> Is 2.1's compatibility across JVMs worse than 2.0's was?

It passed last time. We have now new JDKs though and don't support the Java 
5 ones anymore and have some new tests.

> What are the
> guarantees put forth by those involved with commons-vfs for
> compatibility WRT JVMs?

If issues are reported we already identified as problem with the JDK, we can 
simply relax and give an appropriate pointer. This is e.g. the case for 
commons-io where the IBM JDKs fail with UTF-16LE.

> I'm not nit-picking JVM support -- I'm nit-picking it's severity to
> block v2.1 for being released.

As said, I do not block it, but for *my* vote, I want to know, why some JDKs 
fail.

Cheers,
Jörg


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