cross 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 iden
ing 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
>>
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.
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:
>
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
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
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
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
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
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
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’
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
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
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
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
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
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
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
&
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 <
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
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
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
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
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
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
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
> [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]
>
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
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
.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
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,
' 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
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
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
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
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
; 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>
-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
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
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
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
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
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
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
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
://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
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
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
.
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
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
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
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
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
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
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
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
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
}
* 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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
601 - 700 of 2037 matches
Mail list logo