Re: [VOTE] Apache Commons VFS 2.1 rc1

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.

Re: [VOTE] Apache Commons VFS 2.1 rc1

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" <els...@apache.org> wrote: > Jörg Schaible wrote: >

Re: [VOTE] Apache Commons VFS 2.1 rc1

e 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

Re: [VOTE] Apache Commons VFS 2.1 rc1

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

Re: [VOTE] Apache Commons VFS 2.1 rc1

ssues.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 JspRunti

Re: [VOTE] Apache Commons VFS 2.1 rc1

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

Re: [VOTE] Apache Commons VFS 2.1 rc1

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

Re: [VOTE] Apache Commons VFS 2.1 rc1

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

Re: [VOTE] Apache Commons VFS 2.1 rc1

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’

Re: [VOTE] Apache Commons VFS 2.1 rc1

hat 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 shoul

Re: [VFS] WIP specific release instructions

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

Re: [VFS] WIP specific release instructions

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

Re: [VFS] WIP specific release instructions

aven 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

Re: [VFS] WIP specific release instructions

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

Re: [VOTE] Apache Commons VFS 2.1 rc1

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

Re: [VFS] WIP specific release instructions

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 &

Re: [VFS] WIP specific release instructions

s? > > [1] https://issues.apache.org/jira/browse/COMMONSSITE-87 > > > Gruss > > Bernd > > -- > > http://bernd.eckenfels.net > > > > -Original Message- > > From: Josh Elser <els...@apache.org> > > To: Commons Developers List <

Re: [VFS] WIP specific release instructions

retries. [1] https://issues.apache.org/jira/browse/COMMONSSITE-87 > Gruss > Bernd > -- > http://bernd.eckenfels.net > > -Original Message- > From: Josh Elser <els...@apache.org> > To: Commons Developers List <dev@commons.apache.org> > Sent: Do., 0

Re: [VOTE] Apache Commons VFS 2.1 rc1

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 a

Re: [VOTE] Apache Commons VFS 2.1 rc1

essorImpl.java:62) > at > jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base@9- > ea/DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(java.base@9- > ea/Constructor.java:453) > at > com.google.inject.inte

Re: [VFS] WIP specific release instructions

rom: Josh Elser <els...@apache.org> To: Commons Developers List <dev@commons.apache.org> 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

Re: [VOTE] Apache Commons VFS 2.1 rc1

uration 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 o

Re: [VOTE] Apache Commons VFS 2.1 rc1

t org.codehaus.plexus.archiver.zip.AbstractZipArchiver.(AbstractZipArchiver.java:116) ... 89 more %< = BTW; I get same results if I keep the Hadoop version and simply exclude jdk.tools:jdk.tools from the test-jar artifact of Hadoop. So it seems that VFS 2.1 can basically run on Java 9. 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

f 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 t

Re: [VOTE] Apache Commons VFS 2.1 rc1

> [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] >

Re: [VOTE] Apache Commons VFS 2.1 rc1

ncryption 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 onl

Re: [VOTE] Apache Commons VFS 2.1 rc1

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

Re: [VFS] WIP specific release instructions

.org> 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 po

Re: [VFS] WIP specific release instructions

els...@apache.org> 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,

Re: [VFS] WIP specific release instructions

' RMs. On 4 May 2016 at 04:43, Josh Elser<els...@apache.org> 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

Re: [VOTE] Apache Commons VFS 2.1 rc1

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

Re: [VOTE] Apache Commons VFS 2.1 rc1

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 actual

Re: [VOTE] Apache Commons VFS 2.1 rc1

016 0:39 Subject: Re: [VOTE] 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/Open

Re: [VOTE] Apache Commons VFS 2.1 rc1

version: "4.4.6-gentoo", arch: "amd64", family: "unix" = %< ====== $ mcp -Danimal.sniffer.skip [INFO] Scanning for projects... [INFO] ---- [INFO] Reactor Build Order: [INFO] [INFO] Apa

Re: [VOTE] Apache Commons VFS 2.1 rc1

; 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

Re: [VFS] WIP specific release instructions

mes 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 &g

Re: [VOTE] Apache Commons VFS 2.1 rc1

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

Re: [VFS] Disallowed dependencies in build? (was Re: [VOTE] Apache Commons-VFS2 2.1 rc0)

Bernd Eckenfels wrote: Am Tue, 03 May 2016 21:47:43 -0400 schrieb Josh Elser: See the original point of me starting this thread: it was stated that the sandbox (might) depend on code which is not licensed in such a manner that is allowed for ASF projects. Which is why it

Re: [VOTE] Apache Commons VFS 2.1 rc1

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

Re: [VFS] Disallowed dependencies in build? (was Re: [VOTE] Apache Commons-VFS2 2.1 rc0)

Am Tue, 03 May 2016 21:47:43 -0400 schrieb Josh Elser : > See the original point of me starting this thread: it was stated that > the sandbox (might) depend on code which is not licensed in such a > manner that is allowed for ASF projects. Which is why it is not built or

[VOTE] Apache Commons VFS 2.1 rc1

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

Re: [VFS] Disallowed dependencies in build? (was Re: [VOTE] Apache Commons-VFS2 2.1 rc0)

Bernd-- See the original point of me starting this thread: it was stated that the sandbox (might) depend on code which is not licensed in such a manner that is allowed for ASF projects. Bernd Eckenfels wrote: Hello, the sandbox works perfectly fine for me. Why do you think it is not ready

Re: [VFS] Disallowed dependencies in build? (was Re: [VOTE] Apache Commons-VFS2 2.1 rc0)

Hello, the sandbox works perfectly fine for me. Why do you think it is not ready for release (beside we do not want to?) I dont think we should burden such structural and long standing changes onto a voluntary release manager given the 2.0 had the same structure. Gruss Bernd Am Tue, 3 May

Re: [VFS] Disallowed dependencies in build? (was Re: [VOTE] Apache Commons-VFS2 2.1 rc0)

sebb wrote: +1 along with someone to own this and do the proper diligence as a PMC > member to make sure that we're violating policy. It would be easy to_ensure_ a violation ... ! Since sandbox is not ready for release, for the purpose of getting a VFS release out it should be mo

Re: [VFS] Disallowed dependencies in build? (was Re: [VOTE] Apache Commons-VFS2 2.1 rc0)

a branch. > > > +1 along with someone to own this and do the proper diligence as a PMC > member to make sure that we're violating policy. It would be easy to _ensure_ a violation ... ! Since sandbox is not ready for release, for the purpose of getting a VFS release out it should be moved

Re: [VFS] Disallowed dependencies in build? (was Re: [VOTE] Apache Commons-VFS2 2.1 rc0)

sebb wrote: On 3 May 2016 at 01:43, Josh Elser wrote: Binaries are not an official release anyways. But that does not mean they can include software that is incompatible with the AL, because end users expect (and we tell them) that the software comes under AL 2.0. I

Re: [VFS] Disallowed dependencies in build? (was Re: [VOTE] Apache Commons-VFS2 2.1 rc0)

On 3 May 2016 at 01:43, Josh Elser wrote: > Binaries are not an official release anyways. But that does not mean they can include software that is incompatible with the AL, because end users expect (and we tell them) that the software comes under AL 2.0. Depending on

[VFS] Disallowed dependencies in build? (was Re: [VOTE] Apache Commons-VFS2 2.1 rc0)

Binaries are not an official release anyways. Even so, that seems like a *very* scary thing to even have this code checked into the repository if it depends on incompatibly-licensed software. Am I misunderstanding this? e...@zusammenkunft.net wrote: Hello, Agree, the sandbox profile should

Re: [VFS] JIRA Karma?

Thanks Benedikt! Benedikt Ritter wrote: Hello Josh, Josh Elser<els...@apache.org> schrieb am So., 1. Mai 2016 um 21:46 Uhr: Can someone grant me some karma on the VFS project, please? I'll eventually need to some version management, but, even now, it seems like I can't assign an

Re: [VFS] JIRA Karma?

Hello Josh, Josh Elser <els...@apache.org> schrieb am So., 1. Mai 2016 um 21:46 Uhr: > Can someone grant me some karma on the VFS project, please? I'll > eventually need to some version management, but, even now, it seems like > I can't assign an issue to myself. > I've added

Re: [VFS] JIRA Karma?

he admin page I see: > >> > >> > >>- Project Permissions > >> > >> _Default Permission Scheme_SHARED BY 53 PROJECTS > >> < > https://issues.apache.org/jira/plugins/servlet/project-config/VFS/permissions#project-config-permissions-0-shar

Re: [VFS] JIRA Karma?

Gary Gregory <garydgreg...@gmail.com> > wrote: > >> On the admin page I see: >> >> >>- Project Permissions >> >> _Default Permission Scheme_SHARED BY 53 PROJECTS >> <https://issues.apache.org/jira/plugins/servlet/project-config/VFS/perm

Re: [VFS] JIRA Karma?

https://issues.apache.org/jira/plugins/servlet/project-config/VFS/permissions#project-config-permissions-0-shared> > > So do not have a custom set up for VFS or any Commons component I would > guess. > > We do not have 53 components in Commons IIRC. > > So we'd need to clo

Re: [VFS] JIRA Karma?

On the admin page I see: - Project Permissions _Default Permission Scheme_SHARED BY 53 PROJECTS <https://issues.apache.org/jira/plugins/servlet/project-config/VFS/permissions#project-config-permissions-0-shared> So do not have a custom set up for VFS or any Commons component I would

Re: [VFS] JIRA Karma?

gt; > On Sun, May 1, 2016 at 12:46 PM, Josh Elser <els...@apache.org> wrote: > > > Can someone grant me some karma on the VFS project, please? I'll > > eventually need to some version management, but, even now, it seems like >

Re: [VFS] JIRA Karma?

-administrators) Should we make it such that any Apache Committer can assign an issue? Gary On Sun, May 1, 2016 at 12:46 PM, Josh Elser <els...@apache.org> wrote: > Can someone grant me some karma on the VFS project, please? I'll > eventually need to some version management, but, even now, it

[VFS] JIRA Karma?

Can someone grant me some karma on the VFS project, please? I'll eventually need to some version management, but, even now, it seems like I can't assign an issue to myself. Thanks in advance. - Josh - To unsubscribe, e-mail

Re: [VFS] 2.1 clirr report

Also, looks like I'm wrong about the static member moving up to a parent class (WebdavFileProvider to HttpFileProvider). I thought this wouldn't work, but a quick experiment shows that it's fine. Josh Elser wrote: https://issues.apache.org/jira/browse/VFS-377 is the biggest not-easily-fixed

Re: [VFS] 2.1 clirr report

https://issues.apache.org/jira/browse/VFS-377 is the biggest not-easily-fixed change that breaks binary compatibility for 2.1 against 2.0. The bzip/gzip file object changes are easily restored, as is a moved static member (I don't believe this is something that would I can commit

Re: [VFS] 2.1 clirr report

e sure to bring myself up to >>> speed. >>> >>> That being said: I would still like to get some consensus from those who >>> will be voting from the PMC on what should be done, given the current >>> report (since my opinion and thus vote are non-bind

Re: [VFS] 2.1 clirr report

t <dev@commons.apache.org> Sent: Sa., 30 Apr. 2016 0:11 Subject: Re: [VFS] 2.1 clirr report Hah, thanks for the details, Ralph. I will be sure to bring myself up to speed. That being said: I would still like to get some consensus from those who will be voting from the PMC on what should be done, given

Re: [VFS] 2.1 clirr report

om those who will be voting from the PMC on what should be done, given the current report (since my opinion and thus vote are non-binding :D) http://home.apache.org/~elserj/commons-vfs/commons-vfs-2.1-site/ Ralph Goers wrote: FWIW, these discussions are not new. You might enjoy reading these threads - htt

Re: [VFS] 2.1 clirr report

will be voting from the PMC on what should be done, given the current > report (since my opinion and thus vote are non-binding :D) > > http://home.apache.org/~elserj/commons-vfs/commons-vfs-2.1-site/ > > > Ralph Goers wrote: > >> FWIW, these discussions are not ne

Re: [VFS] 2.1 clirr report

://home.apache.org/~elserj/commons-vfs/commons-vfs-2.1-site/ Ralph Goers wrote: FWIW, these discussions are not new. You might enjoy reading these threads - http://www.mail-archive.com/user@commons.apache.org/msg03711.html. But maybe not! ;-) Ralph On Apr 29, 2016, at 12:43 PM, Ralph Goers

Re: [VFS] 2.1 clirr report

nstead of just >>>>>> updating the version for the artifact and adding the new methods, they >>>>>> *also* have to change the package... >>>>> It's not about compatibility, it's about avoiding jar hell. >>>> Hold up now. We were talking about compatibility. I als

Re: [VFS] 2.1 clirr report

act and adding the new methods, they >>>>> *also* have to change the package... >>>> It's not about compatibility, it's about avoiding jar hell. >>> Hold up now. We were talking about compatibility. I also don't know >>> specifically what you mean by "jar

Re: [VFS] 2.1 clirr report

. Hold up now. We were talking about compatibility. I also don't know specifically what you mean by "jar hell", but it sounds like this is not relevant to the source/binary compatibility discussion (and thus not relevant to this thread). Please correct me if I'm wrong. If a user of VFS d

Re: [VFS] 2.1 clirr report

tibility. I also don't know > specifically what you mean by "jar hell", but it sounds like this is not > relevant to the source/binary compatibility discussion (and thus not relevant > to this thread). Please correct me if I'm wrong. If a user of VFS drops in the new jar in

Re: [VFS] 2.1 clirr report

in an artifact which is guaranteed to be stable. Yes, as you say this is hard. It sounds to me like compatibility is not something commons-vfs is anywhere close to guaranteeing presently (as it's presently undefi

Re: [VFS] 2.1 clirr report

On 29 April 2016 at 16:19, Josh Elser wrote: > sebb wrote: >> >> On 29 April 2016 at 15:59, Josh Elser wrote: >>> >>> > How does changing the package name help? Doesn't that just push a >>> > NoClassDefFound error instead of some missing implementation for

Re: [VFS] 2.1 clirr report

sebb wrote: On 29 April 2016 at 15:59, Josh Elser wrote: > How does changing the package name help? Doesn't that just push a > NoClassDefFound error instead of some missing implementation for a new > method? That means we change ALL the package names and the Maven

Re: [VFS] 2.1 clirr report

rs changed on method(s) in >> o.a.c.v.p.{b.Bzip2FileObject,g.GzipFileObject} >> * Changes from TarEntry to TarArchiveEntry >> * Removed AUTHENTICATOR_TYPES from o.a.c.v.p.w.WebdavFileProvider >> >> Where do you define what

Re: [VFS] 2.1 clirr report

o.a.c.v.p.w.WebdavFileProvider Where do you define what are acceptable changes in a release? Is this going to be a sticking-point? http://home.apache.org/~elserj/commons-vfs/commons-vfs-2.1-site/ - Josh - To unsubscribe, e-mail: dev

Re: [VFS] 2.1 clirr report

to TarArchiveEntry * Removed AUTHENTICATOR_TYPES from o.a.c.v.p.w.WebdavFileProvider Where do you define what are acceptable changes in a release? Is this going to be a sticking-point? http://home.apache.org/~elserj/commons-vfs/commons-vfs-2.1-site/ - Josh

Re: [VFS] 2.1 Release Plan

for > several years) that VFS 3.0 should be modified to use > java.nio.file.FileSystem and FileStore. I don’t think it makes much sense > for VFS to have its own constructs any more. > > Ralph > > > On Apr 28, 2016, at 3:41 PM, e...@zusammenkunft.net wrote: > > > > Th

[VFS] 2.1 clirr report

} * Changes from TarEntry to TarArchiveEntry * Removed AUTHENTICATOR_TYPES from o.a.c.v.p.w.WebdavFileProvider Where do you define what are acceptable changes in a release? Is this going to be a sticking-point? http://home.apache.org/~elserj/commons-vfs/commons-vfs-2.1-site/ - Josh

[VFS] 2.1 release help

Ok, ran into my first issue. Seems like I don't have the karma to edit the existing JIRA issues (changing the fixVersion). Can someone please add me to the appropriate role for the project? - To unsubscribe, e-mail:

Re: [VFS] 2.1 Release Plan

Not to derail the conversation, but my opinion is (and has been for several years) that VFS 3.0 should be modified to use java.nio.file.FileSystem and FileStore. I don’t think it makes much sense for VFS to have its own constructs any more. Ralph > On Apr 28, 2016, at 3:41 PM

Re: [VFS] 2.1 Release Plan

Sent: Fr., 29 Apr. 2016 0:16 Subject: Re: [VFS] 2.1 Release Plan Why don't we bring [vfs] 2.1 from Java 6 to 7 and update 3rd party components? Gary On Tue, Apr 26, 2016 at 12:36 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > Yes, there is a BC breakage for providers, is

Re: [VFS] 2.1 Release Plan

in earnest tonight. Gary Gregory wrote: Why don't we bring [vfs] 2.1 from Java 6 to 7 and update 3rd party components? Gary On Tue, Apr 26, 2016 at 12:36 PM, Gary Gregory <garydgreg...@gmail.com <mailto:garydgreg...@gmail.com>> wrote: Yes, there is a BC breakage f

Re: [VFS] 2.1 Release Plan

Why don't we bring [vfs] 2.1 from Java 6 to 7 and update 3rd party components? Gary On Tue, Apr 26, 2016 at 12:36 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > Yes, there is a BC breakage for providers, is that grounds for a package > and Maven coordinate rename to vf

Re: [VFS] 2.1 Release Plan

On 27 April 2016 at 17:18, Ralph Goers <ralph.go...@dslextreme.com> wrote: > One thing to be wary of - Most, if not all, of the other Commons projects are > not multi-module projects. I remember specifically having to do “interesting” > things in the VFS pom to fix things t

Re: [VFS] 2.1 Release Plan

No worries. I am very familiar with fixing goofed-up Maven projects. The warning is appreciated. Ralph Goers wrote: One thing to be wary of - Most, if not all, of the other Commons projects are not multi-module projects. I remember specifically having to do “interesting” things in the VFS

Re: [VFS] 2.1 Release Plan

Thanks, Sebb and Ralph. I can dig through the parent poms. I wouldn't have initially realized that there was a "commons" parent pom. Thanks for pointing that out. sebb wrote: On 27 April 2016 at 05:58, Ralph Goers<ralph.go...@dslextreme.com> wrote: As I recall, I perfo

Re: [VFS] 2.1 Release Plan

Hello, see inline. Am Tue, 26 Apr 2016 18:05:01 -0400 schrieb Josh Elser<els...@apache.org>: Thanks for the great details, Bernd. Some questions/comments: I hadn't even stumbled across VFS-570 due to its lack of fixVersion=2.1. Are there more that need to be correctly tagged which

Re: [VFS] 2.1 Release Plan

On 27 April 2016 at 05:58, Ralph Goers <ralph.go...@dslextreme.com> wrote: > As I recall, I performed the VFS 2.0 release. I did use the Maven release > plugin. It has been so long that I have forgotten the details of what had to > be done, but I know I ended up using it as the mo

Re: [VFS] 2.1 Release Plan

As I recall, I performed the VFS 2.0 release. I did use the Maven release plugin. It has been so long that I have forgotten the details of what had to be done, but I know I ended up using it as the model for setting up Log4j 2’s build. As I recall I would sort of test “pre-releasing

Re: [VFS] 2.1 Release Plan

Hello, see inline. Am Tue, 26 Apr 2016 18:05:01 -0400 schrieb Josh Elser <els...@apache.org>: > Thanks for the great details, Bernd. Some questions/comments: > > I hadn't even stumbled across VFS-570 due to its lack of > fixVersion=2.1. Are there more that need to be corr

Re: [VFS] 2.1 Release Plan

Thanks for the great details, Bernd. Some questions/comments: I hadn't even stumbled across VFS-570 due to its lack of fixVersion=2.1. Are there more that need to be correctly tagged which could potentially block the release of 2.1? I'm not sure I follow you about the concern of using maven

Re: [VFS] 2.1 Release Plan

Yes, there is a BC breakage for providers, is that grounds for a package and Maven coordinate rename to vfs3? Gary On Tue, Apr 26, 2016 at 12:31 PM, Bernd Eckenfels <e...@zusammenkunft.net> wrote: > Hello Josh, > > I think a VFS 2.1 release would be cool and it is good that you

Re: [VFS] 2.1 Release Plan

Hello Josh, I think a VFS 2.1 release would be cool and it is good that you volunteer, so I dont object. My latest todo list is here: https://wiki.apache.org/commons/VfsReleaseState As you can see, I did plan to do the release and did quite some work to get VFS into a releaseable state. But I

Re: [VFS] 2.1 Release Plan

Best as I can see, Benson was able to do the commons-io 2.5 release after someone else added his key to the KEYS file (because had some separate karma being applied to it which was not included in the universal-commit change). Consider this my formal volunteer offer to be RM for commons-vfs

Re: [VFS] 2.1 Release Plan

necessary permissions and committed his GPG key. On 25 April 2016 at 17:10, Gary Gregory<garydgreg...@gmail.com> wrote: Hi, Agreed, VFS 2.1 has been too long in the making. We can release ASAP without fixing more bugs IMO. RERO and all. As an Apache committer, your are also an Apache Commo

Re: [VFS] 2.1 Release Plan

It's from the thread called "Whatever happened to commons-io 2.5?" A few people stepped up to give the necessary permissions and committed his GPG key. On 25 April 2016 at 17:10, Gary Gregory <garydgreg...@gmail.com> wrote: > Hi, > > Agreed, VFS 2.1 has been too l

[VFS] 2.1 Release Plan

been fixed (but not release) which is spurring me to take some action. There have been emails reaching back as far as 2014 asking when the next release might be, not to mention the fact that vfs-2.0 was released in 2011 (!). History aside, I'm reaching out today to: 1) See if anyone on the PMC

Re: commons-vfs: github pull requests

Am Tue, 22 Mar 2016 16:33:12 + schrieb "Epstein, Ezra" <ezra.epst...@neustar.biz>: > Is commons-vfs being maintained? And is GitHub the up-to-date code > repo? Yes, github is a mirror of the apache git repo and the apache git repo mirrors the SVN based master.

commons-vfs: github pull requests

Is commons-vfs being maintained? And is GitHub the up-to-date code repo? I notice a number of open pull requests, one from yours truly. https://github.com/apache/commons-vfs/pulls Just checking in to see if something more is needed for contributing to this project

Re: commons-vfs: org.apache.commons.vfs2.provider.http.test.HttpProviderTestCase fails

file the report directly in the JIRA: > > https://issues.apache.org/jira/browse/VFS/ > > It seems to be safe to ignore that failure. > Hm, I think we should really fix this :-) Maybe it is possible to use the Test Containers project [1] to spin up the needed infrastructure fo

Re: commons-vfs: org.apache.commons.vfs2.provider.http.test.HttpProviderTestCase fails

FileObject f = VFS.getManager().resolveFile("http://www.w3schools.com/xml/tempconvert.asmx ?WSDL"); This change is included in this pull request: https://github.com/apache/commons-vfs/pull/12 Thanks. On 3/21/16, 2:38 PM, "Epstein, Ezra" <ezra.epst...@neustar.biz> wrot

Re: commons-vfs: org.apache.commons.vfs2.provider.http.test.HttpProviderTestCase fails

Hello, I think it is a new problem. It is a bit unfortunate that those tests rely on external web sites (and those seeem to no longer exist). If you want, you can file the report directly in the JIRA: https://issues.apache.org/jira/browse/VFS/ It seems to be safe to ignore that failure. Gruss

<    2   3   4   5   6   7   8   9   10   11   >