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
1192914d
+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
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 pro
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 si
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:
= %< =
TE] Apache Commons VFS 2.1 rc1
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/OpenJ
e...@zusammenkunft.net wrote:
> Hello,
>
> Java 9 is not supported (only 8)
The build with Java 9 is a heads-up. However, vfs 2.0 was release when Java
7 was one month old ...
> , for the other problems I am not sure, do
> you consider that an blocker?
This depends actually on the cause. Curr
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 tr
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
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.
> [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]
> [ER
"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
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/.
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 JD
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-ja
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
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
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 j
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
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 do
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.g
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 r
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/br
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 grea
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 acr
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,
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
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 r
On May 6, 2016 2:45 AM, "Jörg Schaible" wrote:
>
> 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-re
Well, we've already passed the 3day vote window and have no binding votes.
**PMC, please vote.**
(Thanks to Stian for the nonbinding vote)
Consider the vote extended another 48hrs.
On May 3, 2016 11:43 PM, "Josh Elser" wrote:
> All,
>
> Please consider the following for Apache Commons VFS2 vers
Sorry, quite busy this week, I'll try to take a look later today or this
weekend.
Gary
On May 6, 2016 7:24 AM, "Josh Elser" wrote:
> Well, we've already passed the 3day vote window and have no binding votes.
> **PMC, please vote.**
>
> (Thanks to Stian for the nonbinding vote)
>
> Consider the v
Thanks Gary! Will keep an eye out.
Gary Gregory wrote:
Sorry, quite busy this week, I'll try to take a look later today or this
weekend.
Gary
On May 6, 2016 7:24 AM, "Josh Elser" wrote:
Well, we've already passed the 3day vote window and have no binding votes.
**PMC, please vote.**
(Thanks
I am recording here what I've found and tested (no VOTE yet):
Minor:
[INFO] --- maven-bundle-plugin:3.0.1:manifest (bundle-manifest) @
commons-vfs2-project ---
[WARN] Ignoring project type pom - supportedProjectTypes = [jar, bundle]
Plain wrong but not a blocker IMO (could be hacked post release
Gary Gregory wrote:
Some of the versions of jars in this page are out of date.
Why not refer to the generated page:
https://home.apache.org/~elserj/commons/commons-vfs-2.1/dependency-management.html
from the "About" page and other places if any?
+1
Jörg Schaible wrote:
> 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 a
Hello Josh,
thank you for pushing this release. Sorry I haven't voted yet. I will have
time tomorrow morning to have a look.
Benedikt
Josh Elser schrieb am Fr., 6. Mai 2016 um 16:24 Uhr:
> Well, we've already passed the 3day vote window and have no binding votes.
> **PMC, please vote.**
>
> (T
Please note that I'm requesting one more RC.
For details, see the thread "[VFS] BC breaks in VFS 2.1 RC1" starting here
http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3CCACZkXPy2R2m-95yme4J8ZbRQVtj%3DHaEZ7LncR7aU_QYAVt3UCA%40mail.gmail.com%3E
Thank you,
Gary
On Sun, May 8, 20
Thanks Benedikt for stating you'll vote. I look forward to it.
Greg, thanks again for making the time here and I see that you have
requested a new RC, but I do not wish to honor it unless you commit to
writing a patch with the changes you want to make in a very quick
timeframe (a day or two).
Also, Gary, please cast a vote of -1 if that is your opinion. Requesting
action without a vote doesn't actually help anyone (especially because
release votes are decided by a majority). I do not plan on closing this
vote until we actually get some votes.
**PMC, yet again, we've exceeded the vo
-1 to pick up the latest from trunk in a new RC.
Gary
On Sun, May 8, 2016 at 5:35 PM, Josh Elser wrote:
> Also, Gary, please cast a vote of -1 if that is your opinion. Requesting
> action without a vote doesn't actually help anyone (especially because
> release votes are decided by a majority).
Hello Josh,
first of all: Thank you for RMing VFS 2.1! Sorry it took me so long, but
I'm about to go on vacation and you know how that is... :o)
Here are my observations:
- The staging repo contains a lot of stuff which is not needed (bin and src
archives, examples). Not a blocker for me.
- The
Benedikt Ritter schrieb am Mo., 9. Mai 2016 um
21:03 Uhr:
> Hello Josh,
>
> first of all: Thank you for RMing VFS 2.1! Sorry it took me so long, but
> I'm about to go on vacation and you know how that is... :o)
>
> Here are my observations:
>
> - The staging repo contains a lot of stuff which is
Benedikt Ritter wrote:
- The name is different from Release 1.0. It has been vfs-1.0, no it is
> commons-vfs-project-2.1. I think we should stick with the convention
> established with v1.0.
>
I've looked at the tag names again. It looks completely mixed up. We have:
vfs-1.0/
commons-vfs2-pr
Well, this seems to have officially been stalled after 2 binding votes
(which is super disheartening).
1, +1
1, -1
1, non-binding +1.
Thank you Gary, Stian, and Benedikt for finding the time to vote!
I guess I'll pull in Gary's changes and hope we can get the minimum
binding votes for the nex
Don't despair, I plan on being +1 for the next RC :-)
Gary
On Tue, May 10, 2016 at 7:38 PM, Josh Elser wrote:
> Well, this seems to have officially been stalled after 2 binding votes
> (which is super disheartening).
>
> 1, +1
> 1, -1
> 1, non-binding +1.
>
> Thank you Gary, Stian, and Benedikt
Please ensure that the changes description and therefore RN contain
details of why we think the Clirr errors are not BC errors.
I don't have time just now, but I may be able to update them later today.
On 11 May 2016 at 05:06, Gary Gregory wrote:
> Don't despair, I plan on being +1 for the next
Well, I'd ask that you tell me what you think is wrong in what currently
exists. I did what you asked for rc1 already, but apparently you still
find it insufficient?
sebb wrote:
Please ensure that the changes description and therefore RN contain
details of why we think the Clirr errors are not
On 11 May 2016 at 15:49, Josh Elser wrote:
> Well, I'd ask that you tell me what you think is wrong in what currently
> exists. I did what you asked for rc1 already, but apparently you still find
> it insufficient?
The RN section which mentioned the compatibility issues was buried at
the end of a
sebb wrote:
On 11 May 2016 at 15:49, Josh Elser wrote:
> Well, I'd ask that you tell me what you think is wrong in what currently
> exists. I did what you asked for rc1 already, but apparently you still find
> it insufficient?
The RN section which mentioned the compatibility issues was b
49 matches
Mail list logo
