On 25 May 2016 at 20:06, Benedikt Ritter wrote:
> I haven't done git migrations too often. The last time I can remember, all
> the issues on github were closed automatically. I don't remember why. INFRA
> had to reopen the issues manually.
OK, that's another good argument for doing it one by one
+1 wfm
Bernd Eckenfels wrote:
Hello,
I would like to be able to use Git with the Apache Commons VFS repo. As
we agreed upon I call out the intention to do this and ask you for your
oppinion.
Now that we have the 2.1 release out of the way the switch wont affect
any planned steps.
Anybody
+1
On 05/25/2016 04:55 PM, Gary Gregory wrote:
On Wed, May 25, 2016 at 1:20 PM, Bernd Eckenfels
wrote:
Hello,
I would like to be able to use Git with the Apache Commons VFS repo. As
we agreed upon I call out the intention to do this and ask you for your
oppinion.
+1
Gary
Now that we
On Wed, May 25, 2016 at 4:20 PM, Bernd Eckenfels wrote:
> Hello,
>
> I would like to be able to use Git with the Apache Commons VFS repo. As
> we agreed upon I call out the intention to do this and ask you for your
> oppinion.
+1
Woonsan
>
> Now that we have the 2.1 relea
On Wed, May 25, 2016 at 1:20 PM, Bernd Eckenfels
wrote:
> Hello,
>
> I would like to be able to use Git with the Apache Commons VFS repo. As
> we agreed upon I call out the intention to do this and ask you for your
> oppinion.
>
+1
Gary
>
> Now that we have the 2.1 re
Hello,
I would like to be able to use Git with the Apache Commons VFS repo. As
we agreed upon I call out the intention to do this and ask you for your
oppinion.
Now that we have the 2.1 release out of the way the switch wont affect
any planned steps.
Anybody opposed to this move? I will
e same location).
> Otherwise we need to be worried about open pull requests, link to
> forks, etc.
>
I haven't done git migrations too often. The last time I can remember, all
the issues on github were closed automatically. I don't remember why. INFRA
had to reopen the issues manua
ion).
> Otherwise we need to be worried about open pull requests, link to
> forks, etc.
>
>
> We can start with VFS, then perhaps IO and Collections?
All fine with me.
Gary
>
>
>
>
> On 25 May 2016 at 12:09, Benedikt Ritter wrote:
> > Gary Gregory schrieb am
can start with VFS, then perhaps IO and Collections?
On 25 May 2016 at 12:09, Benedikt Ritter wrote:
> Gary Gregory schrieb am Di., 24. Mai 2016 um
> 23:03 Uhr:
>
>> I think we have to do 1-by-1 with infra anyway but I'd prefer to do it all.
>> My guess from recolle
we still have the "every component may do stuff as it sees fit" we
should move components 1-by-1.
In the past we have did votes by lazy consensus for moving components to
git.
Benedikt
>
> Gary
>
> On Tue, May 24, 2016 at 1:48 PM, wrote:
>
> > I would nominate VFS
Hi,
I happend to meet this old thread while looking at VFS-180, and was
tempted to ask a question here. :-)
I took a look at the current Jackrabbit based test cases, but I'm not
sure if JR is the only option now.
Tomcat has a built-in WebDavServlet to expose DAV access
(read/write/list) and
I think we have to do 1-by-1 with infra anyway but I'd prefer to do it all.
My guess from recollections from previous email threads is that folks would
rather do this 1-by-1. You could start a [POLL] thread.
Gary
On Tue, May 24, 2016 at 1:48 PM, wrote:
> I would nominate VFS to mov
I would nominate VFS to move to git, the question is do we keep want to do that
one by one?
Gruss
Bernd
--
http://bernd.eckenfels.net
-Original Message-
From: Gary Gregory
To: Commons Developers List
Cc: annou...@apache.org, Commons Users List
Sent: Di., 24 Mai 2016 22:36
Subject
distributed by the download servers.
Gruss
Bernd
--
http://bernd.eckenfels.net
-Original Message-
From: Josh Elser
To: Commons Developers List
Sent: Di., 24 Mai 2016 4:20
Subject: Re: [VFS] Final steps for 2.1
sebb wrote:
> On 22 May 2016 at 03:54, Josh Elser wrote:
>> >
sebb wrote:
On 22 May 2016 at 03:54, Josh Elser wrote:
> It's not a problem, it's an inconvenience.
>
> Ideally, Maven builds the artifacts with the intended names. This creates
> consistency through every VOTE message, xsum/sig verification automation,
> website links, and dist.a.o files.
configure Maven to not deploy the ASF
archives but to create the hashes instead.
This should work for all components, not just VFS.
I think this has been looked at, but for single module components the
gain is not that great for the effort involved, so it was not pursued.
>
> Ralph Goers wrote:
by the pom used by the commons:download
plugin to generate the website source file.
The entry means the suffix is suppressed by
the plugin.
The download name is defined by
commons-vfs-${commons.release.version}
This could be changed to add the -distribution suffix if it's
difficult
more places that the docs could
>>>>> use
>>>>>>>>> some help (I knew what needed to be done already, but,
>> obviously, I
>>>>>>>>> didn't do it quite right on my own).
>>>>>>>>>
>&g
but,
> obviously, I
> >>>>>>> didn't do it quite right on my own).
> >>>>>>>
> >>>>>
> >>>>> Are you talking about [1]? Please add any improvements you find
> >>> necessary.
> >>>>>
"-bin" for the binary release are present built by Maven, but not
expected
by the website).
The -bin suffix is controlled by the pom used by the commons:download
plugin to generate the website source file.
The entry means the suffix is suppressed by
the plugin.
The download name is def
are of little
>> inconsistencies.
>> >> :-)
>> >>
>> >> Benedikt
>> >>
>> >> [1]http://commons.apache.org/releases/release.html
>> >>
>> >
>> > Well, the problem this time is the inconsistency between
the problem this time is the inconsistency between what file names
> > that Maven generates and what the website is expecting the names to be
> > (notably the "-distribution" for both binary and source releases and a
> > "-bin" for the binary release are prese
aven generates and what the website is expecting the names to be
> (notably the "-distribution" for both binary and source releases and a
> "-bin" for the binary release are present built by Maven, but not expected
> by the website).
The -bin suffix is controlled by the pom us
The Apache Commons team is pleased to announce the release of Apache
Commons VFS 2.1. Apache Commons VFS provides a single API for accessing
various different file systems. It presents a uniform view of the files
from various different sources, such as the files on local disk, on an
HTTP
Benedikt Ritter wrote:
Hello Josh,
Josh Elser schrieb am Fr., 20. Mai 2016 um 05:28 Uhr:
> One more (final?) snafu: turns out I used the "wrong" name for the
> artifacts in dist.a.o which caused the website to have the wrong links.
>
> Just corrected that, sadly the website will continue
Sorry, I did an `svn cp`, IIRC. Just didn't write the correct verb here
> :)
> >
> > Yes, I have since seen the commit message.
> >
> >>>> remove the checksums on the signatures before promoting the Nexus
> >>>> repository
> >>>>
ues out as well.
Copying from Ralph's 2.0 announcement:
The Apache Commons team is pleased to announce the release of Apache
Commons
VFS 2.1
We ought to include a paragraph on what VFS does.
The Announce will be seen much wider than just the VFS user community.
Yes, people can check the we
rb here :)
Yes, I have since seen the commit message.
>>> remove the checksums on the signatures before promoting the Nexus
>>> repository
>>> (thanks for pointing that out Bernd and Sebb). Just pushed all of the
>>> fixVersion=2.1 issues out as well.
&
ssues out as well.
Copying from Ralph's 2.0 announcement:
The Apache Commons team is pleased to announce the release of Apache
Commons
VFS 2.1
We ought to include a paragraph on what VFS does.
The Announce will be seen much wider than just the VFS user community.
Yes, people can check t
.
Copying from Ralph's 2.0 announcement:
The Apache Commons team is pleased to announce the release of Apache Commons
VFS 2.1
We ought to include a paragraph on what VFS does.
The Announce will be seen much wider than just the VFS user community.
Yes, people can check the website, but a br
/repositories/orgapachecommons-1166
Artifacts: https://dist.apache.org/repos/dist/dev/commons/vfs/ r13608
MD5 commons-vfs-distribution-2.1-bin.tar.gz
8cc35a3169e1faee727c5af94c7dd904
SHA1 commons-vfs-distribution-2.1-bin.tar.gz
72b7557c4e8b1789b8aa0a9c1e0cb2c9daecec30
MD5 comm
x27;s 2.0 announcement:
The Apache Commons team is pleased to announce the release of Apache
Commons VFS 2.1
Details of the changes and bug fixes in this release can be found in
the release notes:
http://www.apache.org/dist/commons/vfs/RELEASE_NOTES.txt
For information on Commons VFS please visi
With VFS 2.1 getting out, I can clean up Groovy VFS 1.0 as well and get
it out of beta state \o/
I'm all for that NIO thing :-}
Just yesterday I wrote a provider for Files.probeFileContent(Path) which
utilises Apache Tika. It's on Github atm -
https://github.com/ysb33r/nio2-filedet
If Java 7 is going to be the minimum version then VFS should become an
extension of java.nio.file. Not doing that doesn’t make any sense to me and
you should just keep the Java version at 6 since you aren’t taking advantage of
the new Java APIs.
Ralph
> On May 19, 2016, at 3:21 AM, G
:53:35 2016
> New Revision: 13683
>
> Log:
> Remove commons-vfs 2.1 rc2 artifacts from dist/dev
>
> Removed:
> dev/commons/vfs/RELEASE-NOTES.txt
> dev/commons/vfs/binaries/commons-vfs-distribution-2.1-bin.tar.gz
> dev/commons/vfs/binaries/commons-vfs-distributio
bb). Just pushed all of the
> > fixVersion=2.1 issues out as well.
> >
> > Copying from Ralph's 2.0 announcement:
> >
> >
> > The Apache Commons team is pleased to announce the release of Apache
> Commons
> > VFS 2.1
>
> We ought to include
Gary Gregory schrieb am Do., 19. Mai 2016 um
10:21 Uhr:
> Now that we have finally gotten 2.1 out the door, I think it is time to
> move [vfs] on to Java 7.
>
+1
>
> Tracking here: https://issues.apache.org/jira/browse/VFS-612
>
> Gary
>
> --
> E-Mail:
>
> The Apache Commons team is pleased to announce the release of Apache Commons
> VFS 2.1
We ought to include a paragraph on what VFS does.
The Announce will be seen much wider than just the VFS user community.
Yes, people can check the website, but a brief description would be
very
itory:
> > https://repository.apache.org/content/repositories/orgapachecommons-1166
> > Artifacts: https://dist.apache.org/repos/dist/dev/commons/vfs/ r13608
> >
> > MD5 commons-vfs-distribution-2.1-bin.tar.gz
> > 8cc35a3169e1faee727c5af94c7dd904
> &g
Now that we have finally gotten 2.1 out the door, I think it is time to
move [vfs] on to Java 7.
Tracking here: https://issues.apache.org/jira/browse/VFS-612
Gary
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.
repository (thanks for pointing that out Bernd and Sebb). Just pushed
all of the fixVersion=2.1 issues out as well.
Copying from Ralph's 2.0 announcement:
The Apache Commons team is pleased to announce the release of Apache
Commons VFS 2.1
Details of the changes and bug fixes in
sitories/orgapachecommons-1166
Artifacts: https://dist.apache.org/repos/dist/dev/commons/vfs/ r13608
MD5 commons-vfs-distribution-2.1-bin.tar.gz
8cc35a3169e1faee727c5af94c7dd904
SHA1 commons-vfs-distribution-2.1-bin.tar.gz
72b7557c4e8b1789b8aa0a9c1e0cb2c9daecec30
MD5 commons-vfs-di
he.org/repos/dist/dev/commons/vfs/ r13608
>
> MD5 commons-vfs-distribution-2.1-bin.tar.gz
> 8cc35a3169e1faee727c5af94c7dd904
> SHA1 commons-vfs-distribution-2.1-bin.tar.gz
> 72b7557c4e8b1789b8aa0a9c1e0cb2c9daecec30
> MD5 commons-vfs-distribution-2.1-src.tar.gz
> a182ac642
t; mentioned module
>> is missing.
>>
>> [4]:
>>
>> everything properly checks out, but the format of the md5 file was
>> different for the artifacts in
>> dist.apache compared to repository.apache.
>>
>> On 2016-05-11 20:29, Jos
ersion was used for the release.
+ all *.sha1, *.md5 and *.asc verified in
orgapachecommons-1166/org/apache/commons/commons-vfs2-distribution/2.1/
Artifacts: https://dist.apache.org/repos/dist/dev/commons/vfs/ r13608
MD5 commons-vfs-distribution-2.1-bin.tar.gz
8cc35a3169e1faee727c5af94c7dd904
SH
.
Hopefully.
Note that Maven did not create these hashes for the NET and Validator
releases I created recently.
It would be worth knowing what Maven version was used for the release.
> + all *.sha1, *.md5 and *.asc verified in
> orgapachecommons-1166/org/apache/commons/commons-vfs2-distribu
n
orgapachecommons-1166/org/apache/commons/commons-vfs2-distribution/2.1/
>
> Artifacts: https://dist.apache.org/repos/dist/dev/commons/vfs/ r13608
>
> MD5 commons-vfs-distribution-2.1-bin.tar.gz
> 8cc35a3169e1faee727c5af94c7dd904
> SHA1 com
Hi,
built this version from source the tarball. IBM JDK' still fail, but it
seems caused by a test making wrong assumptions (see VFS-500). Built with
JDK 9 fails because of failure with jar plugin. However, all tests pass
previously.
Therefore: +1
Cheers,
Jörg
Josh Elser wrote:
wrote:
> >>>>
> >>>> Ignore that, I see you found the actual source file,
> >>>> so clearly it is not from the original Day contribution.
> >>>>
> >>>> I was mislead by the comments in the source which implied it came fro
he source which implied it came from
>>>> various sources.
>>>> It would be helpful to identify the actual sources in the JIRA and VFS
>>>> once they have been established (not a blocker IMO)
>>>>
>>>>>> I'll ask on dev@jackra
-11 20:29, Josh Elser wrote:
All,
Please consider the following for Apache Commons VFS2 version 2.1 (rc2).
Maven repository:
https://repository.apache.org/content/repositories/orgapachecommons-1166
Artifacts: https://dist.apache.org/repos/dist/dev/commons/vfs/ r13608
MD5 commons-vfs-d
aphrase here.
It sounds like we have everything covered for NOTICE about the JackRabbit
sources. I'd recommend adding a comment to the copied files that points at
VFS-611 so that in future reviews there's an easy indicator that we've done due
Stian Soiland-Reyes wrote:
>>>> I'll ask on dev@jackrabbit to be sure.
>
> Agreed - so I've tracked it ashttps://issues.apache.org/jira/browse/VFS-611
>
> Could you assign it to me so I can mark it as In Progress?
Tried, but cannot find you as an assig
wrote:
Ignore that, I see you found the actual source file,
so clearly it is not from the original Day contribution.
I was mislead by the comments in the source which implied it came from
various sources.
It would be helpful to identify the actual sources in the JIRA and VFS
once they have been e
;>
>>> I was mislead by the comments in the source which implied it came from
>>> various sources.
>>> It would be helpful to identify the actual sources in the JIRA and VFS
>>> once they have been established (not a blocker IMO)
>>>
>>>>>
mplied it came from
>> various sources.
>> It would be helpful to identify the actual sources in the JIRA and VFS
>> once they have been established (not a blocker IMO)
>>
>>>> I'll ask on dev@jackrabbit to be sure.
>
> Agreed - so I've tracked it
dentify the actual sources in the JIRA and VFS
> once they have been established (not a blocker IMO)
>
>>> I'll ask on dev@jackrabbit to be sure.
Agreed - so I've tracked it as https://issues.apache.org/jira/browse/VFS-611
Could you assign it to me so I can mark it as In Progre
arly it is not from the original Day contribution.
I was mislead by the comments in the source which implied it came from
various sources.
It would be helpful to identify the actual sources in the JIRA and VFS
once they have been established (not a bloc
;>> >
>>> > says it is copied from Apache Jackrabbit 2.4.0, which has a NOTICE.txt
>>> file.
>>>
>>> i.e.
>>>
>>> http://svn.apache.org/repos/asf/jackrabbit/tags/2.4.0/NOTICE.txt
>>>
>>> > there is no mention of t
2.4.0, which has a NOTICE.txt
>> file.
>>
>> i.e.
>>
>> http://svn.apache.org/repos/asf/jackrabbit/tags/2.4.0/NOTICE.txt
>>
>> > there is no mention of this in the source repo NOTICE (I would presume
>> the
>> > related test jar would als
jar would also be wrong).
>
> Whether that is needed or not depends on whether the specific file was
> part of the original source code from Day.
>
> The file was added as a part of fixing VFS-392
>
> @Gary: can you advise which source files you used to create JcrUtils?
>
ICE.txt
> there is no mention of this in the source repo NOTICE (I would presume the
> related test jar would also be wrong).
Whether that is needed or not depends on whether the specific file was
part of the original source code from Day.
The file was added as a part of fixing VFS-392
@Gary
gt; via `mvn -Pinclude-sandbox verify`, things fall over because the above
>> mentioned module
>> is missing.
>>
>> [4]:
>>
>> everything properly checks out, but the format of the md5 file was
>> different for the artifacts in
>> dist.apache compared to reposit
20:29, Josh Elser wrote:
> > All,
> >
> > Please consider the following for Apache Commons VFS2 version 2.1 (rc2).
> >
> > Maven repository:
> > https://repository.apache.org/content/repositories/orgapachecommons-1166
> > Artifacts: http
://repository.apache.org/content/repositories/orgapachecommons-1166
Artifacts: https://dist.apache.org/repos/dist/dev/commons/vfs/ r13608
MD5 commons-vfs-distribution-2.1-bin.tar.gz
8cc35a3169e1faee727c5af94c7dd904
SHA1 commons-vfs-distribution-2.1-bin.tar.gz
72b7557c4e8b1789b8aa0a9c1e0cb2c9daecec30
Maven repository:
> https://repository.apache.org/content/repositories/orgapachecommons-1166
> Artifacts: https://dist.apache.org/repos/dist/dev/commons/vfs/ r13608
>
> MD5 commons-vfs-distribution-2.1-bin.tar.gz
> 8cc35a3169e1faee727c5af94c7dd904
> SHA1 commons-vfs-distribution-2.1-bin.tar.gz
rg/content/repositories/orgapachecommons-1166
> Artifacts: https://dist.apache.org/repos/dist/dev/commons/vfs/ r13608
>
> MD5 commons-vfs-distribution-2.1-bin.tar.gz
> 8cc35a3169e1faee727c5af94c7dd904
> SHA1 commons-vfs-distribution-2.1-bin.tar.gz
> 72b7557c4e8b1789b8aa0a9c1e0cb2c9daecec30
>
All,
Please consider the following for Apache Commons VFS2 version 2.1 (rc2).
Maven repository:
https://repository.apache.org/content/repositories/orgapachecommons-1166
Artifacts: https://dist.apache.org/repos/dist/dev/commons/vfs/ r13608
MD5 commons-vfs-distribution-2.1-bin.tar.gz
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
hanges and hope we can get the minimum
>>>> binding votes for the next RC. Will try to get rc2 out in the next day
>>>> or
>>>> two.
>>>>
>>>> Josh Elser wrote:
>>>>
>>>>> All,
>>>>>
>>>>> Pleas
ut in the next day or
two.
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 com
ote:
>>
>>> 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
gt;> 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
>>
>> MD
s/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-distri
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
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 con
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.
;
>> 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_Q
ceeded the vote extension and I've gotten one
binding vote (essentially**. Please vote at your earliest convenience.
Gary Gregory wrote:
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-archiv
it.
My personal opinion is that I am comfortable with releasing 2.1 with
the
issues Gary mentions. There should have been 10 releases for VFS 2 by
now.
Well, yeah, RERO would have been great but it was not on high enough on
my
priority list too ;-) The issue we have now would have popped each
the interface.
>>> Then external source will only need to be updated once.
>>>
>>> Assuming others agree with my analysis, these findings need to be
>>> documented in the RN.
>>>
>>>
>>> On 7 May 2016 at 06:29, Gary Gregory
(due
to the nasty race conditions that exist in 2.0) than you are in
releasing something that is not 100% binary compatible.
Gary Gregory wrote:
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://ma
those thoughts and mentioned them a few times
since Java 7 was released. But absolutely no effort has been expended
to do
it.
My personal opinion is that I am comfortable with releasing 2.1 with the
issues Gary mentions. There should have been 10 releases for VFS 2 by
now.
Well, yeah, RERO would
been expended to do
it.
My personal opinion is that I am comfortable with releasing 2.1 with the
issues Gary mentions. There should have been 10 releases for VFS 2 by now.
Well, yeah, RERO would have been great but it was not on high enough on my
priority list too ;-) The issue we have now would
me. I have had those thoughts and mentioned them a few times
> >> since Java 7 was released. But absolutely no effort has been expended
> to do
> >> it.
> >>
> >> My personal opinion is that I am comfortable with releasing 2.1 with the
> >> issues
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
>
> > 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
> > 1192914d1ba6f8ca3a2a688feeff60
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?
It seems the patch for VFS-5
has been expended to do
>> it.
>>
>> My personal opinion is that I am comfortable with releasing 2.1 with the
>> issues Gary mentions. There should have been 10 releases for VFS 2 by now.
>>
>
> Well, yeah, RERO would have been great but it was not on high e
th the
> issues Gary mentions. There should have been 10 releases for VFS 2 by now.
>
Well, yeah, RERO would have been great but it was not on high enough on my
priority list too ;-) The issue we have now would have popped each time we
wanted to break BC, so we could have gotten a better feel
That was me. I have had those thoughts and mentioned them a few times since
Java 7 was released. But absolutely no effort has been expended to do it.
My personal opinion is that I am comfortable with releasing 2.1 with the issues
Gary mentions. There should have been 10 releases for VFS 2 by
On Fri, May 6, 2016 at 8:40 PM, Matt Sicker wrote:
> I thought there were talks about using Java 1.7 APIs in 3.0 that would
> eliminate the need for some classes in commons-vfs, or am I confusing that
> with another commons project?
>
You are correct, but this is a big job worth
I thought there were talks about using Java 1.7 APIs in 3.0 that would
eliminate the need for some classes in commons-vfs, or am I confusing that
with another commons project?
On 6 May 2016 at 17:46, Gary Gregory wrote:
> OK, I've gone through the Clirr report and fixed the low-hangin
Reyes for RM'ing a
> > release, I'm sure he did not know what he was getting himself into! ;-)
>
> Huh? ... that was/is Josh Elser.
> Who does (also) deserve many thanks.
>
> > Part of me writing this here is flushing out for myself, voters, and
> casual
s that the breaks will not affect (m)any users.
In the case of vfs I can live with the latter.
- Jörg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
gt; casual
> > observers what it is we are doing ;-)
> >
> > We have BC breakage in VFS 2.1 RC1 in two areas:
> >
> > - Adding methods to public interfaces
>
> AFAIK that is only a SOURCE breakage.
>
> > - Other stuff like removing fields, changing fields from p
... that was/is Josh Elser.
Who does (also) deserve many thanks.
> Part of me writing this here is flushing out for myself, voters, and casual
> observers what it is we are doing ;-)
>
> We have BC breakage in VFS 2.1 RC1 in two areas:
>
> - Adding methods to public int
ers, and casual
observers what it is we are doing ;-)
We have BC breakage in VFS 2.1 RC1 in two areas:
- Adding methods to public interfaces
- Other stuff like removing fields, changing fields from protected to
private, changing method arg types.
Details:
https://home.apache.org/~elserj/commons/commons-
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
post release):
https://home.apache.org/~elserj/commons/commons-vfs-2.1/download.html
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
501 - 600 of 2214 matches
Mail list logo
