Re: [VFS] NIO Version Questions

[Josh Elser]

Mark Fortner wrote:

There was some discussion during the last release about a NIO-compatible
version of VFS.  This raised a few questions in my mind.

1. Is there a branch where this work should start?


This is easy enough to create one if there's desire :)


2. Are there any specific API proposals, if so where are they (or will
they) be documented?  Would there be branches with specific proposal code,
or a wiki?
3. Does anyone have an "out of the gate" proposal? A proposed file
system implementation that they're willing to contribute/collaborate on?
Preferably something that's easy to test without additional server setup.
Perhaps a db-based file system that could use java db?


Something that would require its own branch to land changes in would be 
good to have an outline/overview architecture doc for what the changes 
to make are.



4. How would the code be organized? Would each implementation have to
have its own repo? If so, this might slow down initial API development.
And you always run into the danger that any API changes you make break
implementing code.


Seems dependent on the previous point (what exactly are the goals).


5. Has anyone considered support for virtual roots in file system URLs?
Like "home://", "documents://", "music://", etc.


Is this related to the NIO work?



Cheers,

Mark



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

Re: Stian to PMC

[Josh Elser]

+1 Congrats!

Sergio Fernández wrote:

congrats, Stian!
On May 25, 2016 6:11 PM, "Stian Soiland-Reyes"  wrote:


Done - now live on

http://commons.apache.org/team-list.html


Do I need to do something special to get Jira admin access? (e.g. to
manage Versions)

On 24 May 2016 at 20:20, Gary Gregory  wrote:

Stian,

You should add yourself as a PMC member here:
https://svn.apache.org/repos/asf/commons/cms-site/trunk/pom.xml

Gary

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

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



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

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






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

Re: [Poll][VFS] Switch to Git

[Josh Elser]

+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 opposed to this move? I will probably need a few days to come
back to this, so this poll with lazy consensus is open for at least 5
days.

Gruss
Bernd

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



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

Re: [VFS] Final steps for 2.1

[Josh Elser]

sebb wrote:

On 22 May 2016 at 03:54, Josh Elser<els...@apache.org>  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.


Does not follow, see below.


>  Renaming them by hand just makes things harder, IMO.


The vote mail should be on the dist/dev archives for the archives
intended for the ASF mirrors and on Nexus for the Maven jars.
The distribution files don't belong in Maven Central and they should
be copied/deleted from Nexus to dist/dev before the vote.

So there should be no inconsistency.

The only extra  manual stage is the rename which must be done before
the dist/dev files are committed.

I agree it would be simpler if no rename was involved.
But it does not affect vote consistency.


Wasn't implying that the VOTE'd artifacts were inconsistent, just the 
files are inconsistently named presently. Sorry for not being more 
specific the first time around. My only point was avoiding the rename at 
various stages in the release process.


I agree with your assessment.

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

Re: [VFS] Final steps for 2.1

[Josh Elser]

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. Renaming them by hand 
just makes things harder, IMO.


Ralph Goers wrote:

Don’t you have to copy the files into the dist directory so you can commit 
them?  Why is renaming them during that step a problem?

Ralph


On May 20, 2016, at 1:57 PM, Christopher<ctubb...@apache.org>  wrote:

Just keep in mind, that overriding the finalName only works for adjusting
the local file name when it's not attached to the build (in addition to the
directory name in an assembly). The final name is not used when it is
deployed to a Maven server or installed to the local repository. In those
cases, the artifact will be renamed according to the module's artifactId it
is in. It works for Accumulo only because we explicitly attach it to the
module with the desired artifactId.

On Fri, May 20, 2016 at 2:49 PM Josh Elser<els...@apache.org>  wrote:


Overriding the finalName is what I was assuming I'd need to change, but
thanks for the extra context, Christopher.

At least I know where I can look if I find the time to try to fix this
for the next sucker.. I mean release manager ;)

Christopher wrote:

I think we also had to override the finalName in the root execution of
maven-assembly-plugin, so unpacking the source tarball wouldn't have a
directory called "accumulo-project-", and instead would look

like

"accumulo-".

On Fri, May 20, 2016 at 2:29 PM Christopher<ctubb...@apache.org>   wrote:


We had a similar problem in Accumulo. We wanted the artifact ID of our
tarballs to just be "accumulo". So our parent pom is now called
"accumulo-project", and one of the modules (that creates the tarballs)

is

called just "accumulo".

This works for our -bin tarball (classifier: "bin" in the assembly
descriptor), but is more complicated for the -src tarball which is

created

at the root of the project.

For the -src tarball, we let the apache-release profile run its

execution

of the maven-assembly-plugin, but we use pluginManagement to override

the

default behavior of that plugin so it does not attach the artifact by
default. Then, in the "accumulo" module, we use the
build-helper-maven-plugin to attach this artifact with the "src"
classifier, right next to the -bin tarball.

It a bit complicated, but it works, and it's pretty understandable once
you realize why it's done that way. Perhaps something like that might be
needed here, since this is in a similar multi-module situation.

On Fri, May 20, 2016 at 11:36 AM sebb<seb...@gmail.com>   wrote:


On 20 May 2016 at 15:39, Josh Elser<els...@apache.org>   wrote:

Benedikt Ritter wrote:

Hello Josh,

Josh Elser<els...@apache.org>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 to be a

little

off
  for another 24hrs. These are some 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).


Are you talking about [1]? Please add any improvements you find

necessary.

I've done it so often that I'm probably unaware of little

inconsistencies.

:-)

Benedikt

[1]http://commons.apache.org/releases/release.html


Well, 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 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 defined by

commons-vfs-${commons.release.version}

This could be changed to add the -distribution suffix if it's
difficult to tell Maven not to add it.


I think this is ultimately something else that should be fixed in the

Maven

build (rather than docs) now that I give it some more thought.

Ideally,

we

just create all of the files with the correct name during the build

and

we

don't touch them after that :)

Yes.

It looks as if the Maven install plugin is responsible for adding the
-distribution suffix based on the artifactId from the dist module.

We cannot remove the -distribution suffix from the id as it would then
clash with the core module.

I don't know enough Maven to solve this.

But a work-round would be to accept the -distribution suffix and just
ensure the download page agrees.
That's trivial to do (

Re: [VFS] Final steps for 2.1

[Josh Elser]

Overriding the finalName is what I was assuming I'd need to change, but 
thanks for the extra context, Christopher.


At least I know where I can look if I find the time to try to fix this 
for the next sucker.. I mean release manager ;)


Christopher wrote:

I think we also had to override the finalName in the root execution of
maven-assembly-plugin, so unpacking the source tarball wouldn't have a
directory called "accumulo-project-", and instead would look like
"accumulo-".

On Fri, May 20, 2016 at 2:29 PM Christopher<ctubb...@apache.org>  wrote:


We had a similar problem in Accumulo. We wanted the artifact ID of our
tarballs to just be "accumulo". So our parent pom is now called
"accumulo-project", and one of the modules (that creates the tarballs) is
called just "accumulo".

This works for our -bin tarball (classifier: "bin" in the assembly
descriptor), but is more complicated for the -src tarball which is created
at the root of the project.

For the -src tarball, we let the apache-release profile run its execution
of the maven-assembly-plugin, but we use pluginManagement to override the
default behavior of that plugin so it does not attach the artifact by
default. Then, in the "accumulo" module, we use the
build-helper-maven-plugin to attach this artifact with the "src"
classifier, right next to the -bin tarball.

It a bit complicated, but it works, and it's pretty understandable once
you realize why it's done that way. Perhaps something like that might be
needed here, since this is in a similar multi-module situation.

On Fri, May 20, 2016 at 11:36 AM sebb<seb...@gmail.com>  wrote:


On 20 May 2016 at 15:39, Josh Elser<els...@apache.org>  wrote:


Benedikt Ritter wrote:

Hello Josh,

Josh Elser<els...@apache.org>   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 to be a little
off
  for another 24hrs. These are some 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).



Are you talking about [1]? Please add any improvements you find

necessary.

I've done it so often that I'm probably unaware of little

inconsistencies.

:-)

Benedikt

[1]http://commons.apache.org/releases/release.html


Well, 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 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 defined by

commons-vfs-${commons.release.version}

This could be changed to add the -distribution suffix if it's
difficult to tell Maven not to add it.


I think this is ultimately something else that should be fixed in the

Maven

build (rather than docs) now that I give it some more thought. Ideally,

we

just create all of the files with the correct name during the build and

we

don't touch them after that :)

Yes.

It looks as if the Maven install plugin is responsible for adding the
-distribution suffix based on the artifactId from the dist module.

We cannot remove the -distribution suffix from the id as it would then
clash with the core module.

I don't know enough Maven to solve this.

But a work-round would be to accept the -distribution suffix and just
ensure the download page agrees.
That's trivial to do (can even be done manually by editting the xml)


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


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






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

[ANNOUNCE] Apache Commons VFS 2.1 released

[Josh Elser]

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 server, or inside a Zip archive.


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

This release is binary compatible with 2.0, users are encouraged to 
upgrade at their earliest convenience.


For information on Commons VFS please visit the VFS website:
http://commons.apache.org/vfs/

Commons VFS can be downloaded from the following page:
http://commons.apache.org/vfs/download_vfs.cgi

- The Apache Commons community

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

Re: [VFS] Final steps for 2.1

[Josh Elser]

Benedikt Ritter wrote:

Hello Josh,

Josh Elser<els...@apache.org>  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 to be a little off
>  for another 24hrs. These are some 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).
>


Are you talking about [1]? Please add any improvements you find necessary.
I've done it so often that I'm probably unaware of little inconsistencies.
:-)

Benedikt

[1]http://commons.apache.org/releases/release.html



Well, 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 present built by Maven, but not 
expected by the website).


I think this is ultimately something else that should be fixed in the 
Maven build (rather than docs) now that I give it some more thought. 
Ideally, we just create all of the files with the correct name during 
the build and we don't touch them after that :)


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

Re: [VFS] Final steps for 2.1

[Josh Elser]

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 to be a little off 
for another 24hrs. These are some 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).


I plan to send out the ANNOUNCE as soon as I see most of the mirrors are 
updated again.


- Josh

sebb wrote:

On 19 May 2016 at 18:43, Josh Elser<els...@apache.org>  wrote:

sebb wrote:

On 19 May 2016 at 03:14, Josh Elser<els...@apache.org>   wrote:

Hi all,

Worked through the remaining steps for this release. dist.a.o (dev and
release) were both updated, trunk was bumped to 2.2-SNAPSHOT, nexus repo
was
released, reporter.a.o was updated, and the svn tag was renamed. I did


It's better to copy rather than rename.


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
(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


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 helpful.


I see a sentence on the website that would be easily included. Any
suggestions of other text that could be included? Oh, and I guess who all is
normally included besides announce@a.o? users@c.a.o? Anyone else?


Normally:

Commons: dev, users
ASF: announce


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


Likewise it would be useful to provide a short summary of the main
changes in the release.
In this case there are so many that it might be hard to summarise, so
perhaps something like:

"VFS 2.1 is binary compatible with 2.0.
It includes many new features and bug fixes; please see the release
notes for details."

The intention of adding this info is to inform potential new users why
they might want to take a look at VFS, and to inform existing users
why they might want to upgrade.

Note that at some point RELEASE_NOTES.txt became RELEASE-NOTES.txt
The former should be deleted from the web site once the announce has
occured.


Sounds great. Will include this too.


Anything else I missed?


Any superseded releases need to be removed from dist/release.
It should be safe to do this once the announce has been sent, assuming
the process above has been followed.

Also tidy the RN files (as mentioned above).


Oo, I guess I jumped the gun a little bit here. I cleaned up the 2.0 release
when I pushed out 2.1 to dist/release.


Yes, that's not ideal.

There needs to be an overlap while mirrors get the new release.
The website and announce can then be done
And then the old release can be removed


S.
P.S. well done and thanks for getting this far.


And thank you for your help too!


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



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



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

Re: [VFS] Final steps for 2.1

[Josh Elser]

Thanks, Benedikt!

Benedikt Ritter wrote:

Hello Josh,

sebb<seb...@gmail.com>  schrieb am Do., 19. Mai 2016 um 10:55 Uhr:


On 19 May 2016 at 03:14, Josh Elser<els...@apache.org>  wrote:

Hi all,

Worked through the remaining steps for this release. dist.a.o (dev and
release) were both updated, trunk was bumped to 2.2-SNAPSHOT, nexus repo

was

released, reporter.a.o was updated, and the svn tag was renamed. I did

It's better to copy rather than rename.


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.

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 brief description would be
very helpful.


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

Likewise it would be useful to provide a short summary of the main
changes in the release.
In this case there are so many that it might be hard to summarise, so
perhaps something like:

"VFS 2.1 is binary compatible with 2.0.
It includes many new features and bug fixes; please see the release
notes for details."

The intention of adding this info is to inform potential new users why
they might want to take a look at VFS, and to inform existing users
why they might want to upgrade.

Note that at some point RELEASE_NOTES.txt became RELEASE-NOTES.txt
The former should be deleted from the web site once the announce has
occured.


For information on Commons VFS please visit the VFS website:
http://commons.apache.org/vfs/

Commons VFS can be downloaded from the following page:
http://commons.apache.org/vfs/download_vfs.cgi

- The Apache Commons community


We'll need to do the following after the artifacts filter out to the
mirrors:

* Update the website [1]
* Send out the ANNOUNCE (text above)

Anything else I missed?

Any superseded releases need to be removed from dist/release.
It should be safe to do this once the announce has been sent, assuming
the process above has been followed.

Also tidy the RN files (as mentioned above).

S.
P.S. well done and thanks for getting this far.



looks good to me!

Benedikt



- Josh

[1]http://commons.apache.org/site-publish.html

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


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






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

Re: [VFS] Final steps for 2.1

[Josh Elser]

sebb wrote:

On 19 May 2016 at 03:14, Josh Elser<els...@apache.org>  wrote:

Hi all,

Worked through the remaining steps for this release. dist.a.o (dev and
release) were both updated, trunk was bumped to 2.2-SNAPSHOT, nexus repo was
released, reporter.a.o was updated, and the svn tag was renamed. I did


It's better to copy rather than rename.


Sorry, I did an `svn cp`, IIRC. Just didn't write the correct verb here :)


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.

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 brief description would be
very helpful.


I see a sentence on the website that would be easily included. Any 
suggestions of other text that could be included? Oh, and I guess who 
all is normally included besides announce@a.o? users@c.a.o? Anyone else?



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


Likewise it would be useful to provide a short summary of the main
changes in the release.
In this case there are so many that it might be hard to summarise, so
perhaps something like:

"VFS 2.1 is binary compatible with 2.0.
It includes many new features and bug fixes; please see the release
notes for details."

The intention of adding this info is to inform potential new users why
they might want to take a look at VFS, and to inform existing users
why they might want to upgrade.

Note that at some point RELEASE_NOTES.txt became RELEASE-NOTES.txt
The former should be deleted from the web site once the announce has occured.


Sounds great. Will include this too.



Anything else I missed?


Any superseded releases need to be removed from dist/release.
It should be safe to do this once the announce has been sent, assuming
the process above has been followed.

Also tidy the RN files (as mentioned above).


Oo, I guess I jumped the gun a little bit here. I cleaned up the 2.0 
release when I pushed out 2.1 to dist/release.



S.
P.S. well done and thanks for getting this far.


And thank you for your help too!

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

Re: [RESULT] [VOTE] Apache Commons VFS 2.1 rc2

[Josh Elser]

No worries! Hope you had a great vacation. :)

Benedikt Ritter wrote:

Hello Josh,

Good work, and awesome you made it through our release process :-)
sorry I wasn't able to vote on this RC. I've been on vacation last week.

BR,
Benedikt

Josh Elser<els...@apache.org>  schrieb am Mi., 18. Mai 2016 um 17:40 Uhr:


We've let this go a bit longer than the originally specified date range,
but let's close it now that we have consensus.

This VOTE passes with 3 binding +1's and 1 non-binding +1.

Thanks again for everyone's help who made this a reality. I'll try to
follow through and find some docs on the steps to promote these
artifacts (with the concerns acknowledged that were mentioned during the
vote).

- Josh

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-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
a182ac642874e85fbc7d1086f7663482
SHA1 commons-vfs-distribution-2.1-src.tar.gz
e42ac2053deb314277213e43f6f1d6b43eff3de9

MD5 commons-vfs-distribution-2.1-bin.zip b512a45c63d824eef826f174fd7a9245
SHA1 commons-vfs-distribution-2.1-bin.zip
886cb5a430da58b3a68e2abf297b6f735d3ffaf0
MD5 commons-vfs-distribution-2.1-src.zip 29645a0ad091c15b2cf76b619c33069f
SHA1 commons-vfs-distribution-2.1-src.zip
5824cf4d802865b5e93ff62c90affa58df6c4384

Signed with 4677D66C from
https://dist.apache.org/repos/dist/release/commons/KEYS

SVN tag is available at


https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.1-rc2/

r1743451

Staged Maven website:
http://home.apache.org/~elserj/commons/commons-vfs-2.1/

All reports are available in the provided staged Maven site (see "Project
Reports" at the root-level as well as under each sub-module).
JIRA-generated
release notes are available in the dist.a.o "Artifacts" repository. Unit
tests pass and the RC was built util JDK6.

(For Sebb) A direct Clirr link


http://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html


Changes since rc1:

* Fixed more compatibility concerns against 2.0 (thanks, Greg)
* Improved release notes (thanks, Sebb)

This vote will be open for 72-hours, 2016/05/14 0400 UTC.

[ ] +1 Release these artifacts as version 2.1
[ ] 0 OK, but...
[ ] -1 I oppose these artifacts as version 2.1 because..

- Josh

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


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






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

[VFS] Final steps for 2.1

[Josh Elser]

Hi all,

Worked through the remaining steps for this release. dist.a.o (dev and 
release) were both updated, trunk was bumped to 2.2-SNAPSHOT, nexus repo 
was released, reporter.a.o was updated, and the svn tag was renamed. I 
did 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.


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 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 visit the VFS website:
http://commons.apache.org/vfs/

Commons VFS can be downloaded from the following page:
http://commons.apache.org/vfs/download_vfs.cgi

- The Apache Commons community


We'll need to do the following after the artifacts filter out to the 
mirrors:


* Update the website [1]
* Send out the ANNOUNCE (text above)

Anything else I missed?

- Josh

[1]http://commons.apache.org/site-publish.html

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

[RESULT] [VOTE] Apache Commons VFS 2.1 rc2

[Josh Elser]

We've let this go a bit longer than the originally specified date range, 
but let's close it now that we have consensus.


This VOTE passes with 3 binding +1's and 1 non-binding +1.

Thanks again for everyone's help who made this a reality. I'll try to 
follow through and find some docs on the steps to promote these 
artifacts (with the concerns acknowledged that were mentioned during the 
vote).


- Josh

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-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
a182ac642874e85fbc7d1086f7663482
SHA1 commons-vfs-distribution-2.1-src.tar.gz
e42ac2053deb314277213e43f6f1d6b43eff3de9

MD5 commons-vfs-distribution-2.1-bin.zip b512a45c63d824eef826f174fd7a9245
SHA1 commons-vfs-distribution-2.1-bin.zip
886cb5a430da58b3a68e2abf297b6f735d3ffaf0
MD5 commons-vfs-distribution-2.1-src.zip 29645a0ad091c15b2cf76b619c33069f
SHA1 commons-vfs-distribution-2.1-src.zip
5824cf4d802865b5e93ff62c90affa58df6c4384

Signed with 4677D66C from
https://dist.apache.org/repos/dist/release/commons/KEYS

SVN tag is available at
https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.1-rc2/
r1743451

Staged Maven website:
http://home.apache.org/~elserj/commons/commons-vfs-2.1/

All reports are available in the provided staged Maven site (see "Project
Reports" at the root-level as well as under each sub-module).
JIRA-generated
release notes are available in the dist.a.o "Artifacts" repository. Unit
tests pass and the RC was built util JDK6.

(For Sebb) A direct Clirr link
http://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html


Changes since rc1:

* Fixed more compatibility concerns against 2.0 (thanks, Greg)
* Improved release notes (thanks, Sebb)

This vote will be open for 72-hours, 2016/05/14 0400 UTC.

[ ] +1 Release these artifacts as version 2.1
[ ] 0 OK, but...
[ ] -1 I oppose these artifacts as version 2.1 because..

- Josh

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



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

Re: [VOTE] Apache Commons VFS 2.1 rc2

[Josh Elser]

Thanks Bernd and Jörg for your votes so far!

By my tally, we're one (binding) vote away from passing this!

Gary or Sebb, any chance either of you could cast a vote (I assume this 
fell by the wayside when we thought there were issues with the NOTICE file)?


sebb wrote:

On 17 May 2016 at 17:57, Bernd<e...@zusammenkunft.net>  wrote:

Hello,

Thanks Josh!

This is a binding +1

(however I have some minor optional points which could be fixed in another
RC or before releasing the repo):


2016-05-12 5:29 GMT+02:00 Josh Elser<els...@apache.org>:


All,

Please consider the following for Apache Commons VFS2 version 2.1 (rc2).

Maven repository:
https://repository.apache.org/content/repositories/orgapachecommons-1166


- The files *.asc.md5 and *.asc.sha1 are normally deleted according to
commons procedure (not sure why).


Because they serve no purpose; they are just clutter.
A .asc file is its own validator - if it is mangled, it won't be
usable as a sig file.
It is equivalent to creating *.md5.sha1 files.


I think you can do that before the repo
is submitted.


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-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 commons-vfs-distribution-2.1-bin.tar.gz
72b7557c4e8b1789b8aa0a9c1e0cb2c9daecec30
MD5  commons-vfs-distribution-2.1-src.tar.gz
a182ac642874e85fbc7d1086f7663482
SHA1 commons-vfs-distribution-2.1-src.tar.gz
e42ac2053deb314277213e43f6f1d6b43eff3de9

MD5  commons-vfs-distribution-2.1-bin.zip b512a45c63d824eef826f174fd7a9245
SHA1 commons-vfs-distribution-2.1-bin.zip
886cb5a430da58b3a68e2abf297b6f735d3ffaf0
MD5  commons-vfs-distribution-2.1-src.zip 29645a0ad091c15b2cf76b619c33069f
SHA1 commons-vfs-distribution-2.1-src.zip
5824cf4d802865b5e93ff62c90affa58df6c4384

+ verified



Signed with 4677D66C from
https://dist.apache.org/repos/dist/release/commons/KEYS


+ verified
- PGP signature is SHA1 but I guess it is (still) fine
- Cant verify the key on a trusted path, but thats not a Commons
requirement.


The KEYS file is stored in SVN, which gives traceability of who added what key.





SVN tag is available at

https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.1-rc2/
r1743451

Staged Maven website:
http://home.apache.org/~elserj/commons/commons-vfs-2.1/

All reports are available in the provided staged Maven site (see "Project
Reports" at the root-level as well as under each sub-module).
JIRA-generated
release notes are available in the dist.a.o "Artifacts" repository. Unit
tests pass and the RC was built util JDK6.

(For Sebb) A direct Clirr link

http://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html

Changes since rc1:

* Fixed more compatibility concerns against 2.0 (thanks, Greg)
* Improved release notes (thanks, Sebb)

This vote will be open for 72-hours, 2016/05/14 0400 UTC.

   [X ] +1 Release these artifacts as version 2.1
   [ ] 0  OK, but...
   [ ] -1 I oppose these artifacts as version 2.1 because..

- Josh

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




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



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

Re: [VOTE] Apache Commons VFS 2.1 rc2

[Josh Elser]

Sean,

Circling back around on the discussions today about Jackrabbit's NOTICE 
file, this would change your -1 vote, yes?


Sean Busbey wrote:

-1 (non-binding)

bad:

* LICENSE/NOTICE file is missing a bundled third party reference[1]

maybe fine:

* source artifacts mostly match source tag[2]
* build / test from source works[3]

fine:
* verified signatures and checksums[4]

[1]:

core/src/test/java/org/apache/commons/vfs2/provider/webdav/test/JcrUtils.java

says it is copied from Apache Jackrabbit 2.4.0, which has a NOTICE.txt file.

there is no mention of this in the source repo NOTICE (I would presume the
related test jar would also be wrong).

[2]:

The source tag contains an additional module 'sandbox' that is not in the 
source artifact.

I am not sure if this is intentional, but it looks like it is.

[3]:

Related to [2], if you run `mvn verify` things are fine, but if you use the 
sandbox profile,
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 repository.apache.

On 2016-05-11 20:29, Josh Elser<els...@apache.org>  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-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
a182ac642874e85fbc7d1086f7663482
SHA1 commons-vfs-distribution-2.1-src.tar.gz
e42ac2053deb314277213e43f6f1d6b43eff3de9

MD5  commons-vfs-distribution-2.1-bin.zip b512a45c63d824eef826f174fd7a9245
SHA1 commons-vfs-distribution-2.1-bin.zip
886cb5a430da58b3a68e2abf297b6f735d3ffaf0
MD5  commons-vfs-distribution-2.1-src.zip 29645a0ad091c15b2cf76b619c33069f
SHA1 commons-vfs-distribution-2.1-src.zip
5824cf4d802865b5e93ff62c90affa58df6c4384

Signed with 4677D66C from
https://dist.apache.org/repos/dist/release/commons/KEYS

SVN tag is available at
https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.1-rc2/
r1743451

Staged Maven website:
http://home.apache.org/~elserj/commons/commons-vfs-2.1/

All reports are available in the provided staged Maven site (see "Project
Reports" at the root-level as well as under each sub-module). JIRA-generated
release notes are available in the dist.a.o "Artifacts" repository. Unit
tests pass and the RC was built util JDK6.

(For Sebb) A direct Clirr link
http://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html

Changes since rc1:

* Fixed more compatibility concerns against 2.0 (thanks, Greg)
* Improved release notes (thanks, Sebb)

This vote will be open for 72-hours, 2016/05/14 0400 UTC.

[ ] +1 Release these artifacts as version 2.1
[ ] 0  OK, but...
[ ] -1 I oppose these artifacts as version 2.1 because..

- Josh

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




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



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

Re: [VFS] NOTICE required for Jackrabbit's JcrUtils? (was: [VOTE] Apache Commons VFS 2.1 rc2)

[Josh Elser]

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 assign target.

BTW, there is a sibling file which also was derived from JackRabbit:

JackrabbitMain.java

I've not checked when this was added to the JR repo.



Took care of this :)

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

Re: The state of 2.1

[Josh Elser]

Stian Soiland-Reyes wrote:

Hi,

I assume you mean Commons VFS 2.1.

The second release candidate was effectively pulled because we were
missing a LICENSE/NOTICE entry:

https://lists.apache.org/thread.html/Zif1iomxs7u25tt

This should be trivial to fix, but also important to get right legally.


I assume Josh Elser (as the Release Manager for this candidate) will
formally mark the 2.1 RC2  thread as [CANCELLED] and then we can
prepare a new RC3 for voting.

..but be aware that many Apache committers have been involved with
ApacheCon which just finished last Friday, so folks probably have lots
of things to catch up on.

On 16 May 2016 at 01:45, Dmitry Goldenberg<dgoldenberg...@gmail.com>  wrote:

Hi,

Could someone summarize the state of the VOTE for 2.1?

Thank you.




Yeah, had a busy end of week and weekend, so I didn't have any time to 
sit down in front of a computer and hash this all out. I pinged busbey 
(the original reporter of the issue) to make sure he has visibility of 
the assessment of the situation. Your legwork has been great and makes 
sense to me, Stian.


Hopefully we can proceed with RC2, but it would be pretty easy to add 
that new line to NOTICE and roll an RC3 if necessary.


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

Re: [VFS] NOTICE required for Jackrabbit's JcrUtils? (was: [VOTE] Apache Commons VFS 2.1 rc2)

[Josh Elser]

+cc busbey (in case he misses this discuss, otherwise)

Does this make sense to you? I'm sure you have a better understanding 
than I do at the fringes of licensing @ the ASF :)


tl;dr Those copied files from jackrabbit were added after the code was 
already graduated from Incubator, thus, the original "spirit" of the 
NOTICE (being that *some* code came from "Day Software") is definitively 
known to not apply.



Stian Soiland-Reyes wrote:

JackrabbitMain seems to be based on jackrabbit-standalone module

https://github.com/apache/jackrabbit/blob/1.5/jackrabbit-standalone/src/main/java/org/apache/jackrabbit/standalone/Main.java

which starts in 2008:

https://github.com/apache/jackrabbit/commit/de58b89320ed768a89035197b46f1486b35d430d

On 16 May 2016 at 11:57, sebb  wrote:

On 16 May 2016 at 10:56, Stian Soiland-Reyes  wrote:

On 16 May 2016 at 10:10, sebb  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 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 Progress?

Tried, but cannot find you as an assign target.

BTW, there is a sibling file which also was derived from JackRabbit:

JackrabbitMain.java

I've not checked when this was added to the JR repo.


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

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


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







-
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 rc2

[Josh Elser]

Hey Sean,

#1 sounds like you're right here. I hadn't done a close enough over the 
codebase. I will defer to PMC members with more history than the few 
weeks I have...


#2/3 about the sandbox is intentional. There is code in the sandbox 
which is not "fit to be released" (see so previous conversation on this, 
around rc0 iirc).


#4 I had to manually create the xsums, the release process doesn't do it 
(and I didn't have any interest in making this work automated). That's 
why the format is different (obviously the hashes should still be equal).


Sean Busbey wrote:

-1 (non-binding)

bad:

* LICENSE/NOTICE file is missing a bundled third party reference[1]

maybe fine:

* source artifacts mostly match source tag[2]
* build / test from source works[3]

fine:
* verified signatures and checksums[4]

[1]:

core/src/test/java/org/apache/commons/vfs2/provider/webdav/test/JcrUtils.java

says it is copied from Apache Jackrabbit 2.4.0, which has a NOTICE.txt file.

there is no mention of this in the source repo NOTICE (I would presume the
related test jar would also be wrong).

[2]:

The source tag contains an additional module 'sandbox' that is not in the 
source artifact.

I am not sure if this is intentional, but it looks like it is.

[3]:

Related to [2], if you run `mvn verify` things are fine, but if you use the 
sandbox profile,
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 repository.apache.

On 2016-05-11 20:29, Josh Elser<els...@apache.org>  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-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
a182ac642874e85fbc7d1086f7663482
SHA1 commons-vfs-distribution-2.1-src.tar.gz
e42ac2053deb314277213e43f6f1d6b43eff3de9

MD5  commons-vfs-distribution-2.1-bin.zip b512a45c63d824eef826f174fd7a9245
SHA1 commons-vfs-distribution-2.1-bin.zip
886cb5a430da58b3a68e2abf297b6f735d3ffaf0
MD5  commons-vfs-distribution-2.1-src.zip 29645a0ad091c15b2cf76b619c33069f
SHA1 commons-vfs-distribution-2.1-src.zip
5824cf4d802865b5e93ff62c90affa58df6c4384

Signed with 4677D66C from
https://dist.apache.org/repos/dist/release/commons/KEYS

SVN tag is available at
https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.1-rc2/
r1743451

Staged Maven website:
http://home.apache.org/~elserj/commons/commons-vfs-2.1/

All reports are available in the provided staged Maven site (see "Project
Reports" at the root-level as well as under each sub-module). JIRA-generated
release notes are available in the dist.a.o "Artifacts" repository. Unit
tests pass and the RC was built util JDK6.

(For Sebb) A direct Clirr link
http://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html

Changes since rc1:

* Fixed more compatibility concerns against 2.0 (thanks, Greg)
* Improved release notes (thanks, Sebb)

This vote will be open for 72-hours, 2016/05/14 0400 UTC.

[ ] +1 Release these artifacts as version 2.1
[ ] 0  OK, but...
[ ] -1 I oppose these artifacts as version 2.1 because..

- Josh

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




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



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

[VOTE] Apache Commons VFS 2.1 rc2

[Josh Elser]

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
8cc35a3169e1faee727c5af94c7dd904
SHA1 commons-vfs-distribution-2.1-bin.tar.gz
72b7557c4e8b1789b8aa0a9c1e0cb2c9daecec30
MD5  commons-vfs-distribution-2.1-src.tar.gz
a182ac642874e85fbc7d1086f7663482
SHA1 commons-vfs-distribution-2.1-src.tar.gz
e42ac2053deb314277213e43f6f1d6b43eff3de9

MD5  commons-vfs-distribution-2.1-bin.zip b512a45c63d824eef826f174fd7a9245
SHA1 commons-vfs-distribution-2.1-bin.zip
886cb5a430da58b3a68e2abf297b6f735d3ffaf0
MD5  commons-vfs-distribution-2.1-src.zip 29645a0ad091c15b2cf76b619c33069f
SHA1 commons-vfs-distribution-2.1-src.zip
5824cf4d802865b5e93ff62c90affa58df6c4384

Signed with 4677D66C from
https://dist.apache.org/repos/dist/release/commons/KEYS

SVN tag is available at
https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.1-rc2/ 
r1743451


Staged Maven website:
http://home.apache.org/~elserj/commons/commons-vfs-2.1/

All reports are available in the provided staged Maven site (see "Project
Reports" at the root-level as well as under each sub-module). JIRA-generated
release notes are available in the dist.a.o "Artifacts" repository. Unit
tests pass and the RC was built util JDK6.

(For Sebb) A direct Clirr link
http://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html

Changes since rc1:

* Fixed more compatibility concerns against 2.0 (thanks, Greg)
* Improved release notes (thanks, Sebb)

This vote will be open for 72-hours, 2016/05/14 0400 UTC.

  [ ] +1 Release these artifacts as version 2.1
  [ ] 0  OK, but...
  [ ] -1 I oppose these artifacts as version 2.1 because..

- Josh

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

Re: [RESULT] [VOTE] Apache Commons VFS 2.1 rc1

[Josh Elser]

sebb wrote:

On 11 May 2016 at 15:49, Josh Elser<els...@apache.org>  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 huge list of changes, so I did not see it at first.
It did not explain that we believe the code to be binary compatible
with2.0,  at least as far as the public API is concerned.

The description in changes.xml was not updated.
Next time the RN are generated from it any changes would be lost.

==

I have now updated changes.xml and regenerated the RN.
I hope they are clear, but if not feel free to adjust changes.xml and
regenerate the RN:

mvn-N  changes:announcement-generate -Prelease-notes -Dchanges.version=2.1



Ah, thanks for the clarification. I think I missed that (or temporarily 
forgot :P)


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

Re: [RESULT] [VOTE] Apache Commons VFS 2.1 rc1

[Josh Elser]

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 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<garydgreg...@gmail.com>  wrote:

Don't despair, I plan on being +1 for the next RC :-)

Gary

On Tue, May 10, 2016 at 7:38 PM, Josh Elser<els...@apache.org>  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 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 next RC. Will try to get rc2 out 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 commons-vfs-distribution-2.1-bin.tar.gz
1192914d1ba6f8ca3a2a688feeff602c
SHA1 commons-vfs-distribution-2.1-bin.tar.gz
285097f1db6cbc9d76ae5bb3adf66a315344a864
MD5 commons-vfs-distribution-2.1-src.tar.gz
0646187562302a7dcfbddb93204fc9eb
SHA1 commons-vfs-distribution-2.1-src.tar.gz
24bab87fd4049b9389acd1b6e272f405630aeb25
MD5 commons-vfs-distribution-2.1-bin.zip 3785874aa0cda64d68acbb8fb7db8bea
SHA1 commons-vfs-distribution-2.1-bin.zip
942a23fb202b89b1a8432beeb0a66469959e661d
MD5 commons-vfs-distribution-2.1-src.zip c8ef43d308bed1b3ffcb363c15285176
SHA1 commons-vfs-distribution-2.1-src.zip
1ddf0d218f659766f136894eab0beca504ab9f8c

Signed with 4677D66C from
https://dist.apache.org/repos/dist/release/commons/KEYS

SVN tag is available at

https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project-2.1-RC1/
r1742212

Staged Maven website:
http://home.apache.org/~elserj/commons/commons-vfs-2.1/

All reports are available in the provided staged Maven site (see
"Project Reports" at the root-level as well as under each sub-module).
JIRA-generated release notes are available in the dist.a.o "Artifacts"
repository. Unit tests pass and the RC was built util JDK6.

(For Sebb) A direct Clirr link

http://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html


Changes since rc0:

* Improved release notes and website for compatibility
* Fixes to pom.xml for building website

This vote will be open for 72-hours, 2016/05/06 0400 UTC.

[ ] +1 Release these artifacts as version 2.1
[ ] 0 OK, but...
[ ] -1 I oppose these artifacts as version 2.1 because..

- Josh


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




--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition<http://www.manning.com/tahchiev/>
Spring Batch in Action<http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory


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



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

[RESULT] [VOTE] Apache Commons VFS 2.1 rc1

[Josh Elser]

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 next RC. Will try to get rc2 out 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 commons-vfs-distribution-2.1-bin.tar.gz
1192914d1ba6f8ca3a2a688feeff602c
SHA1 commons-vfs-distribution-2.1-bin.tar.gz
285097f1db6cbc9d76ae5bb3adf66a315344a864
MD5 commons-vfs-distribution-2.1-src.tar.gz
0646187562302a7dcfbddb93204fc9eb
SHA1 commons-vfs-distribution-2.1-src.tar.gz
24bab87fd4049b9389acd1b6e272f405630aeb25
MD5 commons-vfs-distribution-2.1-bin.zip 3785874aa0cda64d68acbb8fb7db8bea
SHA1 commons-vfs-distribution-2.1-bin.zip
942a23fb202b89b1a8432beeb0a66469959e661d
MD5 commons-vfs-distribution-2.1-src.zip c8ef43d308bed1b3ffcb363c15285176
SHA1 commons-vfs-distribution-2.1-src.zip
1ddf0d218f659766f136894eab0beca504ab9f8c

Signed with 4677D66C from
https://dist.apache.org/repos/dist/release/commons/KEYS

SVN tag is available at
https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project-2.1-RC1/
r1742212

Staged Maven website:
http://home.apache.org/~elserj/commons/commons-vfs-2.1/

All reports are available in the provided staged Maven site (see
"Project Reports" at the root-level as well as under each sub-module).
JIRA-generated release notes are available in the dist.a.o "Artifacts"
repository. Unit tests pass and the RC was built util JDK6.

(For Sebb) A direct Clirr link
http://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html


Changes since rc0:

* Improved release notes and website for compatibility
* Fixes to pom.xml for building website

This vote will be open for 72-hours, 2016/05/06 0400 UTC.

[ ] +1 Release these artifacts as version 2.1
[ ] 0 OK, but...
[ ] -1 I oppose these artifacts as version 2.1 because..

- Josh


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

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Josh Elser]

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-project-2.0/
commons-vfs-project-2.1-RC1/

It looks like release 2.0 has introduced a new convention. It would be good
to follow this convention with all upcoming releases...




Ack! I meant to follow suite with the 2.0 release, but it seems like I 
missed the "2" in "vfs2". Thanks for catching it.


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

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Josh Elser]

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 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-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3CCACZkXPy2R2m-95yme4J8ZbRQVtj%3DHaEZ7LncR7aU_QYAVt3UCA%40mail.gmail.com%3E

Thank you,

Gary

On Sun, May 8, 2016 at 5:06 AM, Benedikt Ritter<brit...@apache.org>  wrote:


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

(Thanks to Stian for the nonbinding vote)

Consider the vote extended another 48hrs.
On May 3, 2016 11:43 PM, "Josh Elser"<els...@apache.org>  wrote:


All,

Please consider the following for Apache Commons VFS2 version 2.1

(rc1).

Maven repository:


https://repository.apache.org/content/repositories/orgapachecommons-1163

Artifacts: https://dist.apache.org/repos/dist/dev/commons/vfs/ r13511

MD5  commons-vfs-distribution-2.1-bin.tar.gz
1192914d1ba6f8ca3a2a688feeff602c
SHA1 commons-vfs-distribution-2.1-bin.tar.gz
285097f1db6cbc9d76ae5bb3adf66a315344a864
MD5  commons-vfs-distribution-2.1-src.tar.gz
0646187562302a7dcfbddb93204fc9eb
SHA1 commons-vfs-distribution-2.1-src.tar.gz
24bab87fd4049b9389acd1b6e272f405630aeb25
MD5  commons-vfs-distribution-2.1-bin.zip

3785874aa0cda64d68acbb8fb7db8bea

SHA1 commons-vfs-distribution-2.1-bin.zip
942a23fb202b89b1a8432beeb0a66469959e661d
MD5  commons-vfs-distribution-2.1-src.zip

c8ef43d308bed1b3ffcb363c15285176

SHA1 commons-vfs-distribution-2.1-src.zip
1ddf0d218f659766f136894eab0beca504ab9f8c

Signed with 4677D66C from
https://dist.apache.org/repos/dist/release/commons/KEYS

SVN tag is available at


https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project-2.1-RC1/

r1742212

Staged Maven website:
http://home.apache.org/~elserj/commons/commons-vfs-2.1/

All reports are available in the provided staged Maven site (see

"Project

Reports" at the root-level as well as under each sub-module).
JIRA-generated release notes are available in the dist.a.o "Artifacts"
repository. Unit tests pass and the RC was built util JDK6.

(For Sebb) A direct Clirr link


http://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html

Changes since rc0:

* Improved release notes and website for compatibility
* Fixes to pom.xml for building website

This vote will be open for 72-hours, 2016/05/06 0400 UTC.

   [ ] +1 Release these artifacts as version 2.1
   [ ] 0  OK, but...
   [ ] -1 I oppose these artifacts as version 2.1 because..

- Josh







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

Re: [VFS] BC breaks in VFS 2.1 RC1

[Josh Elser]

Oh, you did? I thought I did an update before I sent my last email and 
didn't see any changes from you. Perhaps I just missed it then :)


Gary Gregory wrote:

Hi,

I am sorry for not being clearer. I've already updated trunk with 'as good
as it gets for now' code. These are the low-hanging fruit changes I wrote
about plus updates to the latest Commons Net and IO IIRC (on my phone now).

I would like a new RC to pick up these changes, see my other email(s).

Gary
On May 8, 2016 11:50 AM, "Josh Elser"<els...@apache.org>  wrote:


Gary -- how quickly can you turn around a patch to fix this? Without a
patch, I am still in favor of 2.1 being released as is. 2.1.1 can be
released with these fixes at your earliest convenience.

Gary Gregory wrote:


Just for completeness, I'm advocating we do this now, but new methods to
interfaces could be added as subinterfaces as in FileContent2 extends
FileContent.

Gary

On Sat, May 7, 2016 at 2:52 AM, sebb<seb...@gmail.com>   wrote:

I have just looked again at the Clirr errors.

Apart from the interface method additions, the changes are:

*) Replacing org.apache.commons.vfs2.provider.tar.TarEntry by
org.apache.commons.compress.archivers.tar.TarArchiveEntry in several
places.

TarEntry has been dropped, however the class was package-private so it
was clearly not part of the public API.
And likewise, methods using cannot have been part of the API.

*) replacing org.apache.commons.vfs2.provider.tar.TarInputStream by
org.apache.commons.compress.archivers.tar.TarArchiveInputStream as the
return type for a couple of methods

Again, TarInputStream has been dropped, and it was also
package-private. So again the public API must be OK.

So I think we are OK as far as BC is concerned.

Source will need to be updated if it uses any of the interfaces that
have been updated:
FileContent
FileName
FileObject
FileSystemManager
RandomAccessContent

If there may be another 2.x release, we should make sure that the
interfaces have suitable abstract class implementations that can be
extended instead of implementing 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<garydgreg...@gmail.com>   wrote:


On Fri, May 6, 2016 at 10:20 PM, Ralph Goers<ralph.go...@dslextreme.com

wrote:

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


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 for it with


RERO


and 10 VFS 2.x releases under our belts! But we are stuck with a Big
Bang
release now.

I would request another RC from the RM, and let the community decide by
VOTE.

Gary

Ralph

On May 6, 2016, at 8:40 PM, Matt Sicker<boa...@gmail.com>   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?

On 6 May 2016 at 17:46, Gary Gregory<garydgreg...@gmail.com>   wrote:

OK, I've gone through the Clirr report and fixed the low-hanging
fruits

in

trunk. I think we need another RC. I've also update Apache Commons
Compress
and Net to their current versions.

Then what we have to live with for 2.1 is BC breaks in two narrower


areas:
- Added methods to interfaces.

- Changes in the Tar classes from our own Tar classes to Apache


Commons

Compress' Tar classes.

That's how good it's going to get for now IMO.

I would be perfectly OK with repackaging for 3.0 but then this would


open
the door to other changes that folks might want to make. I would be
OK

with

saying this is 3.0 as is in this case.

I'm still not 100% comfortable with the BC based on my experience


with

large projects with deep transitive dependencies.

If the community VOTEs to release trunk (yes, another RC please) as


2.1

then I'll live with it. Releasing as 3.0 (as is) would be safe and

conservative.

Gary

On Fri, May 6, 2016 at 3:00 PM, sebb<seb...@gmail.com>   wrote:

On 6 May 2016 at 22:40, Gary Gregory<garydgreg...@gmail.com>
wrote:

I'm creating a new thread here instead of hijacking the VOTE

thread.

First, let me express my gratitude to Stian Soiland-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

observers what it is we are doing ;-)

We have BC breakage in VFS 2.1 RC1 in tw

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Josh Elser]

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). I don't see a commit nor a JIRA issue filed 
for this yet, so I'm assuming it's not already done/ready; please 
correct me if I'm wrong.


2.1 can still be released as-is and you have the ability to make the 
changes you desire, test to your heart's content and then make a 2.1.1 
release to address this issue. It would be a much different story to me 
if there was any semblance of a regular release cadence, but I have no 
patience for "last minute changes" after so long since your last 
release. IMO, you are doing just as much harm in not releasing code (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://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, 2016 at 5:06 AM, Benedikt Ritter<brit...@apache.org>  wrote:


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

(Thanks to Stian for the nonbinding vote)

Consider the vote extended another 48hrs.
On May 3, 2016 11:43 PM, "Josh Elser"<els...@apache.org>  wrote:


All,

Please consider the following for Apache Commons VFS2 version 2.1

(rc1).

Maven repository:


https://repository.apache.org/content/repositories/orgapachecommons-1163

Artifacts: https://dist.apache.org/repos/dist/dev/commons/vfs/ r13511

MD5  commons-vfs-distribution-2.1-bin.tar.gz
1192914d1ba6f8ca3a2a688feeff602c
SHA1 commons-vfs-distribution-2.1-bin.tar.gz
285097f1db6cbc9d76ae5bb3adf66a315344a864
MD5  commons-vfs-distribution-2.1-src.tar.gz
0646187562302a7dcfbddb93204fc9eb
SHA1 commons-vfs-distribution-2.1-src.tar.gz
24bab87fd4049b9389acd1b6e272f405630aeb25
MD5  commons-vfs-distribution-2.1-bin.zip

3785874aa0cda64d68acbb8fb7db8bea

SHA1 commons-vfs-distribution-2.1-bin.zip
942a23fb202b89b1a8432beeb0a66469959e661d
MD5  commons-vfs-distribution-2.1-src.zip

c8ef43d308bed1b3ffcb363c15285176

SHA1 commons-vfs-distribution-2.1-src.zip
1ddf0d218f659766f136894eab0beca504ab9f8c

Signed with 4677D66C from
https://dist.apache.org/repos/dist/release/commons/KEYS

SVN tag is available at


https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project-2.1-RC1/

r1742212

Staged Maven website:
http://home.apache.org/~elserj/commons/commons-vfs-2.1/

All reports are available in the provided staged Maven site (see

"Project

Reports" at the root-level as well as under each sub-module).
JIRA-generated release notes are available in the dist.a.o "Artifacts"
repository. Unit tests pass and the RC was built util JDK6.

(For Sebb) A direct Clirr link


http://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html

Changes since rc0:

* Improved release notes and website for compatibility
* Fixes to pom.xml for building website

This vote will be open for 72-hours, 2016/05/06 0400 UTC.

   [ ] +1 Release these artifacts as version 2.1
   [ ] 0  OK, but...
   [ ] -1 I oppose these artifacts as version 2.1 because..

- Josh







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

Re: [VFS] BC breaks in VFS 2.1 RC1

[Josh Elser]

Gary -- how quickly can you turn around a patch to fix this? Without a 
patch, I am still in favor of 2.1 being released as is. 2.1.1 can be 
released with these fixes at your earliest convenience.


Gary Gregory wrote:

Just for completeness, I'm advocating we do this now, but new methods to
interfaces could be added as subinterfaces as in FileContent2 extends
FileContent.

Gary

On Sat, May 7, 2016 at 2:52 AM, sebb<seb...@gmail.com>  wrote:


I have just looked again at the Clirr errors.

Apart from the interface method additions, the changes are:

*) Replacing org.apache.commons.vfs2.provider.tar.TarEntry by
org.apache.commons.compress.archivers.tar.TarArchiveEntry in several
places.

TarEntry has been dropped, however the class was package-private so it
was clearly not part of the public API.
And likewise, methods using cannot have been part of the API.

*) replacing org.apache.commons.vfs2.provider.tar.TarInputStream by
org.apache.commons.compress.archivers.tar.TarArchiveInputStream as the
return type for a couple of methods

Again, TarInputStream has been dropped, and it was also
package-private. So again the public API must be OK.

So I think we are OK as far as BC is concerned.

Source will need to be updated if it uses any of the interfaces that
have been updated:
FileContent
FileName
FileObject
FileSystemManager
RandomAccessContent

If there may be another 2.x release, we should make sure that the
interfaces have suitable abstract class implementations that can be
extended instead of implementing 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<garydgreg...@gmail.com>  wrote:

On Fri, May 6, 2016 at 10:20 PM, Ralph Goers<ralph.go...@dslextreme.com

wrote:


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

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 for it with

RERO

and 10 VFS 2.x releases under our belts! But we are stuck with a Big Bang
release now.

I would request another RC from the RM, and let the community decide by
VOTE.

Gary


Ralph


On May 6, 2016, at 8:40 PM, Matt Sicker<boa...@gmail.com>  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?

On 6 May 2016 at 17:46, Gary Gregory<garydgreg...@gmail.com>  wrote:


OK, I've gone through the Clirr report and fixed the low-hanging

fruits

in

trunk. I think we need another RC. I've also update Apache Commons

Compress

and Net to their current versions.

Then what we have to live with for 2.1 is BC breaks in two narrower

areas:

- Added methods to interfaces.
- Changes in the Tar classes from our own Tar classes to Apache

Commons

Compress' Tar classes.

That's how good it's going to get for now IMO.

I would be perfectly OK with repackaging for 3.0 but then this would

open

the door to other changes that folks might want to make. I would be

OK

with

saying this is 3.0 as is in this case.

I'm still not 100% comfortable with the BC based on my experience

with

large projects with deep transitive dependencies.

If the community VOTEs to release trunk (yes, another RC please) as

2.1

then I'll live with it. Releasing as 3.0 (as is) would be safe and
conservative.

Gary

On Fri, May 6, 2016 at 3:00 PM, sebb<seb...@gmail.com>  wrote:


On 6 May 2016 at 22:40, Gary Gregory<garydgreg...@gmail.com>

wrote:

I'm creating a new thread here instead of hijacking the VOTE

thread.

First, let me express my gratitude to Stian Soiland-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

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 protected

to

private, changing method arg types.

That does break BC if the objects are part of the public API.


Details:


https://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html

I see three areas that need consideration:

(0) For simple clients that only use the higher-level interfaces

and

methods, there are no problems. So this is a non-issue marker I

suppose.

Whether or 

Re: [VFS] BC breaks in VFS 2.1 RC1

[Josh Elser]

(catching up)

Thanks for writing this note, Sebb. It completely aligns with my 
opinion. In the docs from Oracle which you earlier linked, method 
additions *do not* break binary compatibility. I'm a little confused why 
this is being brought up for at least a second time now (could have been 
third).


sebb wrote:

I have just looked again at the Clirr errors.

Apart from the interface method additions, the changes are:

*) Replacing org.apache.commons.vfs2.provider.tar.TarEntry by
org.apache.commons.compress.archivers.tar.TarArchiveEntry in several
places.

TarEntry has been dropped, however the class was package-private so it
was clearly not part of the public API.
And likewise, methods using cannot have been part of the API.

*) replacing org.apache.commons.vfs2.provider.tar.TarInputStream by
org.apache.commons.compress.archivers.tar.TarArchiveInputStream as the
return type for a couple of methods

Again, TarInputStream has been dropped, and it was also
package-private. So again the public API must be OK.

So I think we are OK as far as BC is concerned.

Source will need to be updated if it uses any of the interfaces that
have been updated:
FileContent
FileName
FileObject
FileSystemManager
RandomAccessContent

If there may be another 2.x release, we should make sure that the
interfaces have suitable abstract class implementations that can be
extended instead of implementing 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<garydgreg...@gmail.com>  wrote:

On Fri, May 6, 2016 at 10:20 PM, Ralph Goers<ralph.go...@dslextreme.com>
wrote:


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 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 for it with RERO
and 10 VFS 2.x releases under our belts! But we are stuck with a Big Bang
release now.

I would request another RC from the RM, and let the community decide by
VOTE.

Gary


Ralph


On May 6, 2016, at 8:40 PM, Matt Sicker<boa...@gmail.com>  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?

On 6 May 2016 at 17:46, Gary Gregory<garydgreg...@gmail.com>  wrote:


OK, I've gone through the Clirr report and fixed the low-hanging fruits

in

trunk. I think we need another RC. I've also update Apache Commons

Compress

and Net to their current versions.

Then what we have to live with for 2.1 is BC breaks in two narrower

areas:

- Added methods to interfaces.
- Changes in the Tar classes from our own Tar classes to Apache Commons
Compress' Tar classes.

That's how good it's going to get for now IMO.

I would be perfectly OK with repackaging for 3.0 but then this would

open

the door to other changes that folks might want to make. I would be OK

with

saying this is 3.0 as is in this case.

I'm still not 100% comfortable with the BC based on my experience with
large projects with deep transitive dependencies.

If the community VOTEs to release trunk (yes, another RC please) as 2.1
then I'll live with it. Releasing as 3.0 (as is) would be safe and
conservative.

Gary

On Fri, May 6, 2016 at 3:00 PM, sebb<seb...@gmail.com>  wrote:


On 6 May 2016 at 22:40, Gary Gregory<garydgreg...@gmail.com>  wrote:

I'm creating a new thread here instead of hijacking the VOTE thread.

First, let me express my gratitude to Stian Soiland-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

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 protected to
private, changing method arg types.

That does break BC if the objects are part of the public API.


Details:


https://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html

I see three areas that need consideration:

(0) For simple clients that only use the higher-level interfaces and
methods, there are no problems. So this is a non-issue marker I

suppose.

Whether or not that affects simple clients depends on exactly which
fields and method args have changed. Are they part of the public API?
And if so, will simple cl

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Josh Elser]

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

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

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Josh Elser]

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"<els...@apache.org>  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 vote extended another 48hrs.
On May 3, 2016 11:43 PM, "Josh Elser"<els...@apache.org>  wrote:


All,

Please consider the following for Apache Commons VFS2 version 2.1 (rc1).

Maven repository:
https://repository.apache.org/content/repositories/orgapachecommons-1163
Artifacts: https://dist.apache.org/repos/dist/dev/commons/vfs/ r13511

MD5  commons-vfs-distribution-2.1-bin.tar.gz
1192914d1ba6f8ca3a2a688feeff602c
SHA1 commons-vfs-distribution-2.1-bin.tar.gz
285097f1db6cbc9d76ae5bb3adf66a315344a864
MD5  commons-vfs-distribution-2.1-src.tar.gz
0646187562302a7dcfbddb93204fc9eb
SHA1 commons-vfs-distribution-2.1-src.tar.gz
24bab87fd4049b9389acd1b6e272f405630aeb25
MD5  commons-vfs-distribution-2.1-bin.zip

3785874aa0cda64d68acbb8fb7db8bea

SHA1 commons-vfs-distribution-2.1-bin.zip
942a23fb202b89b1a8432beeb0a66469959e661d
MD5  commons-vfs-distribution-2.1-src.zip

c8ef43d308bed1b3ffcb363c15285176

SHA1 commons-vfs-distribution-2.1-src.zip
1ddf0d218f659766f136894eab0beca504ab9f8c

Signed with 4677D66C from
https://dist.apache.org/repos/dist/release/commons/KEYS

SVN tag is available at


https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project-2.1-RC1/

r1742212

Staged Maven website:
http://home.apache.org/~elserj/commons/commons-vfs-2.1/

All reports are available in the provided staged Maven site (see "Project
Reports" at the root-level as well as under each sub-module).
JIRA-generated release notes are available in the dist.a.o "Artifacts"
repository. Unit tests pass and the RC was built util JDK6.

(For Sebb) A direct Clirr link


http://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html

Changes since rc0:

* Improved release notes and website for compatibility
* Fixes to pom.xml for building website

This vote will be open for 72-hours, 2016/05/06 0400 UTC.

   [ ] +1 Release these artifacts as version 2.1
   [ ] 0  OK, but...
   [ ] -1 I oppose these artifacts as version 2.1 because..

- Josh





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

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Josh Elser]

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

> All,
>
> Please consider the following for Apache Commons VFS2 version 2.1 (rc1).
>
> Maven repository:
> https://repository.apache.org/content/repositories/orgapachecommons-1163
> Artifacts: https://dist.apache.org/repos/dist/dev/commons/vfs/ r13511
>
> MD5  commons-vfs-distribution-2.1-bin.tar.gz
> 1192914d1ba6f8ca3a2a688feeff602c
> SHA1 commons-vfs-distribution-2.1-bin.tar.gz
> 285097f1db6cbc9d76ae5bb3adf66a315344a864
> MD5  commons-vfs-distribution-2.1-src.tar.gz
> 0646187562302a7dcfbddb93204fc9eb
> SHA1 commons-vfs-distribution-2.1-src.tar.gz
> 24bab87fd4049b9389acd1b6e272f405630aeb25
> MD5  commons-vfs-distribution-2.1-bin.zip 3785874aa0cda64d68acbb8fb7db8bea
> SHA1 commons-vfs-distribution-2.1-bin.zip
> 942a23fb202b89b1a8432beeb0a66469959e661d
> MD5  commons-vfs-distribution-2.1-src.zip c8ef43d308bed1b3ffcb363c15285176
> SHA1 commons-vfs-distribution-2.1-src.zip
> 1ddf0d218f659766f136894eab0beca504ab9f8c
>
> Signed with 4677D66C from
> https://dist.apache.org/repos/dist/release/commons/KEYS
>
> SVN tag is available at
> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project-2.1-RC1/
> r1742212
>
> Staged Maven website:
> http://home.apache.org/~elserj/commons/commons-vfs-2.1/
>
> All reports are available in the provided staged Maven site (see "Project
> Reports" at the root-level as well as under each sub-module).
> JIRA-generated release notes are available in the dist.a.o "Artifacts"
> repository. Unit tests pass and the RC was built util JDK6.
>
> (For Sebb) A direct Clirr link
> http://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html
>
> Changes since rc0:
>
> * Improved release notes and website for compatibility
> * Fixes to pom.xml for building website
>
> This vote will be open for 72-hours, 2016/05/06 0400 UTC.
>
>   [ ] +1 Release these artifacts as version 2.1
>   [ ] 0  OK, but...
>   [ ] -1 I oppose these artifacts as version 2.1 because..
>
> - Josh
>

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Josh Elser]

On May 6, 2016 2:45 AM, "Jörg Schaible" <joerg.schai...@gmx.de> 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-read all of the conversation
> >>>> >>  between Jörg and Stian, but my initial reaction is the same as
what
> >>>> >>  you were implying: compatibility across more JVMs would be great,
> >>>> >>  but shouldn't block this 2.1 release.
> >>
> >> Just an additional remark: Compatibility across more JVMs*is*  an
issue,
> >> since there are platforms where you have no other choice (IBM AIX, Mac,
> >> most Linux distributions use OpenJDK by default).
> >>
> >
> > Is 2.1's compatibility across JVMs worse than 2.0's was?
>
> It passed last time. We have now new JDKs though and don't support the
Java
> 5 ones anymore and have some new tests.
>
> > What are the
> > guarantees put forth by those involved with commons-vfs for
> > compatibility WRT JVMs?
>
> If issues are reported we already identified as problem with the JDK, we
can
> simply relax and give an appropriate pointer. This is e.g. the case for
> commons-io where the IBM JDKs fail with UTF-16LE.
>
> > I'm not nit-picking JVM support -- I'm nit-picking it's severity to
> > block v2.1 for being released.
>
> As said, I do not block it, but for *my* vote, I want to know, why some
JDKs
> fail.
>
> Cheers,
> Jörg

Great, thanks for clarifying. Let's deal with this at the earliest
convenience after 2.1.

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Josh Elser]

Jörg Schaible wrote:

Jörg Schaible wrote:


>  Hi Josh,
>
>  Josh Elser wrote:
>

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


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



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


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


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

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Josh Elser]

Oh, well then! No pressure :)

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


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


Ralph Goers wrote:

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

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

Ralph


On May 4, 2016, at 9:43 PM, Josh Elser<els...@apache.org>  wrote:

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

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

Jörg Schaible wrote:

Hi,

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

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

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

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

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

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

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

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

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Josh Elser]

rrors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the
command
[ERROR]   mvn  -rf :commons-vfs2
= %<  ==

The reason is an invalid (transitive) system dependency on tools.jar of
Hadoop which is no longer present in Java 9.

Cheers,
Jörg


Josh Elser wrote:


All,

Please consider the following for Apache Commons VFS2 version 2.1 (rc1).

Maven repository:
https://repository.apache.org/content/repositories/orgapachecommons-1163
Artifacts: https://dist.apache.org/repos/dist/dev/commons/vfs/ r13511

MD5  commons-vfs-distribution-2.1-bin.tar.gz
1192914d1ba6f8ca3a2a688feeff602c
SHA1 commons-vfs-distribution-2.1-bin.tar.gz
285097f1db6cbc9d76ae5bb3adf66a315344a864
MD5  commons-vfs-distribution-2.1-src.tar.gz
0646187562302a7dcfbddb93204fc9eb
SHA1 commons-vfs-distribution-2.1-src.tar.gz
24bab87fd4049b9389acd1b6e272f405630aeb25
MD5  commons-vfs-distribution-2.1-bin.zip 3785874aa0cda64d68acbb8fb7db8bea
SHA1 commons-vfs-distribution-2.1-bin.zip
942a23fb202b89b1a8432beeb0a66469959e661d
MD5  commons-vfs-distribution-2.1-src.zip c8ef43d308bed1b3ffcb363c15285176
SHA1 commons-vfs-distribution-2.1-src.zip
1ddf0d218f659766f136894eab0beca504ab9f8c

Signed with 4677D66C from
https://dist.apache.org/repos/dist/release/commons/KEYS

SVN tag is available at
https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project-2.1-RC1/
r1742212

Staged Maven website:
http://home.apache.org/~elserj/commons/commons-vfs-2.1/

All reports are available in the provided staged Maven site (see
"Project Reports" at the root-level as well as under each sub-module).
JIRA-generated release notes are available in the dist.a.o "Artifacts"
repository. Unit tests pass and the RC was built util JDK6.

(For Sebb) A direct Clirr link
http://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html

Changes since rc0:

* Improved release notes and website for compatibility
* Fixes to pom.xml for building website

This vote will be open for 72-hours, 2016/05/06 0400 UTC.

[ ] +1 Release these artifacts as version 2.1
[ ] 0  OK, but...
[ ] -1 I oppose these artifacts as version 2.1 because..

- Josh



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







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

Re: [VFS] WIP specific release instructions

[Josh Elser]

sebb wrote:

On 5 May 2016 at 05:49, Josh Elser<els...@apache.org>  wrote:


sebb wrote:

Have a look at the scripts in

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

I used those for VALIDATOR and NET.


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


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


Gotcha. Makes sense. Thanks for bringing them up.




---

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

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


No need to use package if using CP40


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


mvn deploy



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



--

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

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


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

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


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


I don't follow that.


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



I see.

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


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



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



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

Re: [VFS] WIP specific release instructions

[Josh Elser]

sebb wrote:

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

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


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



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


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

Re: [VFS] WIP specific release instructions

[Josh Elser]

sebb wrote:

Have a look at the scripts in

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

I used those for VALIDATOR and NET.


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



On 4 May 2016 at 04:43, Josh Elser<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 writing
it down here before I forget (we can figure out where it *should* go later).

rc0 only:
# Make the branch
$ svn cp trunk branches/VFS-XXX
$ cd branches/VFS-XXX
# Set the proper versions
$ mvn release:prepare


We use a tag not a branch, but perhaps that is what the release plugin does.
In which case I assume the branch is taken to avoid mangling trunk?


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


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



---

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

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


No need to use package if using CP40


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




# Set back to 1.7 because my 1.6 installation has trouble deploying to nexus
$ export JAVA_HOME=$(/usr/libexec/java_home -v1.7)


So does mine; in which case use -Pjava-1.6 below.


$ mvn deploy -Prelease -Duser.name=${asf.username}

# This is what could be consolidated via one invocation of `mvn site`
$ mvn site:site site:stage

# Move back to the root SVN repo
$ cd ../..
$ svn cp branches/VFS-XXX tags/commons-vfs-project-XXX-rcN


Isn't that what the release plugin does?

You might find

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

easier to use - it does it all for you without needing to create a
temporary branch.


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


--

Things not covered above:

* Copying artifacts (tarballs/zips, xsums, and sigs) into
dist.a.o/dev/commons/... (building md5/sha1 files)
* Closing staging repo in Nexus


That can be done using Nexus2DistDev.sh


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




--

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

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


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

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


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


I don't follow that.


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





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

- Josh

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



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



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

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Josh Elser]

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

[INFO] Reactor Build Order:
[INFO]
[INFO] Apache Commons VFS
[INFO] Apache Commons VFS Core
[INFO] Apache Commons VFS Examples
[INFO] Apache Commons VFS Distribution
[INFO]
[INFO]

[INFO] Building Apache Commons VFS 2.1
[INFO]

[INFO]
[INFO] --- maven-clean-plugin:3.0.0:clean (default-clean) @ commons-vfs2-
project ---
[INFO] Deleting /home/joehni/tmp/download/commons-vfs-2.1/target
[INFO]
[INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-maven-3) @ commons-
vfs2-project ---
[INFO]
[INFO] --- build-helper-maven-plugin:1.10:parse-version (parse-version) @
commons-vfs2-project ---
[INFO]
[INFO] --- maven-antrun-plugin:1.8:run (javadoc.resources) @ commons-vfs2-
project ---
[INFO] Executing tasks

main:
  [copy] Copying 2 files to /home/joehni/tmp/download/commons-
vfs-2.1/target/apidocs/META-INF
[INFO] Executed tasks
[INFO]
[INFO] --- maven-antrun-plugin:1.8:run (vfs-jar-manifest) @ commons-vfs2-
project ---
[INFO] Executing tasks

main:
 [mkdir] Created dir: /home/joehni/tmp/download/commons-
vfs-2.1/target/osgi
 [touch] Creating /home/joehni/tmp/download/commons-
vfs-2.1/target/osgi/MANIFEST.MF
[INFO] Executed tasks
[INFO]
[INFO] --- maven-remote-resources-plugin:1.5:process (default) @ commons-
vfs2-project ---
[INFO]
[INFO] --- buildnumber-maven-plugin:1.4:create (default) @ commons-vfs2-
project ---
[INFO] Executing: /bin/sh -c cd '/home/joehni/tmp/download/commons-vfs-2.1'
&&  'svn' '--non-interactive' 'info'
[INFO] Working directory: /home/joehni/tmp/download/commons-vfs-2.1
[INFO] Storing buildNumber: ?? at timestamp: 1462399750905
[INFO] Executing: /bin/sh -c cd '/home/joehni/tmp/download/commons-vfs-2.1'
&&  'svn' '--non-interactive' 'info'
[INFO] Working directory: /home/joehni/tmp/download/commons-vfs-2.1
[INFO] Storing buildScmBranch: UNKNOWN_BRANCH
[INFO]
[INFO] --- maven-bundle-plugin:3.0.1:manifest (bundle-manifest) @ commons-
vfs2-project ---
[WARNING] Ignoring project type pom - supportedProjectTypes = [jar, bundle]
[INFO]
[INFO] --- animal-sniffer-maven-plugin:1.15:check (checkAPIcompatibility) @
commons-vfs2-project ---
[INFO] Signature checking is skipped.
[INFO]
[INFO] --- maven-site-plugin:3.4:attach-descriptor (attach-descriptor) @
commons-vfs2-project ---
[INFO]
[INFO]

[INFO] Building Apache Commons VFS Core 2.1
[INFO]

[INFO]

[INFO] Reactor Summary:
[INFO]
[INFO] Apache Commons VFS . SUCCESS [  3.068
s]
[INFO] Apache Commons VFS Core  FAILURE [  0.350
s]
[INFO] Apache Commons VFS Examples  SKIPPED
[INFO] Apache Commons VFS Distribution  SKIPPED
[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 3.738 s
[INFO] Finished at: 2016-05-05T00:09:12+02:00
[INFO] Final Memory: 23M/78M
[INFO]

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

The reason is an invalid (transitive) system dependency on tools.jar of
Hadoop which is no longer present in Java 9.

Cheers,
Jörg


Josh Elser wrote:


All,

Please consider the following for Apache Commons VFS2 version 2.1 (rc1).

Maven repository:
https://repository.apache.org/content/repositories/orgapachecommons-1163
Artifacts: https://dist.apache.org/repos/dist/dev/commons/vfs/ r13511

MD5  commons-vfs-distribution-2.1-bin.tar.gz
1192914d1ba6f8ca3a2a688feeff602c
SHA1 commons-vfs-distribution-2.1-bin.tar.gz
285097f1db6cbc9d76ae5bb3adf66a315344a864
MD5  commons-vfs-dist

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

[Josh Elser]

Bernd Eckenfels wrote:

Am Tue, 03 May 2016 21:47:43 -0400
schrieb Josh Elser<els...@apache.org>:


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 shipped by default and called sandbox.
(this was not my idea and before my time but I dont see a reason to
change this for this release)

Gruss
Bernd

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



I was just pointed to http://www.apache.org/legal/resolved.html#optional

The way this reads, because we don't push it to Nexus, that's fine.

The other half is that I was (incorrectly) assuming that the src release 
was still including the sandbox. This is wrong -- there are no 
occurrences of it in release artifacts.


I'm good now :)

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

[VOTE] Apache Commons VFS 2.1 rc1

[Josh Elser]

All,

Please consider the following for Apache Commons VFS2 version 2.1 (rc1).

Maven repository: 
https://repository.apache.org/content/repositories/orgapachecommons-1163

Artifacts: https://dist.apache.org/repos/dist/dev/commons/vfs/ r13511

MD5  commons-vfs-distribution-2.1-bin.tar.gz 
1192914d1ba6f8ca3a2a688feeff602c
SHA1 commons-vfs-distribution-2.1-bin.tar.gz 
285097f1db6cbc9d76ae5bb3adf66a315344a864
MD5  commons-vfs-distribution-2.1-src.tar.gz 
0646187562302a7dcfbddb93204fc9eb
SHA1 commons-vfs-distribution-2.1-src.tar.gz 
24bab87fd4049b9389acd1b6e272f405630aeb25

MD5  commons-vfs-distribution-2.1-bin.zip 3785874aa0cda64d68acbb8fb7db8bea
SHA1 commons-vfs-distribution-2.1-bin.zip 
942a23fb202b89b1a8432beeb0a66469959e661d

MD5  commons-vfs-distribution-2.1-src.zip c8ef43d308bed1b3ffcb363c15285176
SHA1 commons-vfs-distribution-2.1-src.zip 
1ddf0d218f659766f136894eab0beca504ab9f8c


Signed with 4677D66C from 
https://dist.apache.org/repos/dist/release/commons/KEYS


SVN tag is available at 
https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project-2.1-RC1/ 
r1742212


Staged Maven website: 
http://home.apache.org/~elserj/commons/commons-vfs-2.1/


All reports are available in the provided staged Maven site (see 
"Project Reports" at the root-level as well as under each sub-module). 
JIRA-generated release notes are available in the dist.a.o "Artifacts" 
repository. Unit tests pass and the RC was built util JDK6.


(For Sebb) A direct Clirr link 
http://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html


Changes since rc0:

* Improved release notes and website for compatibility
* Fixes to pom.xml for building website

This vote will be open for 72-hours, 2016/05/06 0400 UTC.

  [ ] +1 Release these artifacts as version 2.1
  [ ] 0  OK, but...
  [ ] -1 I oppose these artifacts as version 2.1 because..

- Josh

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

Re: [RESULT] [VOTE] Apache Commons-VFS2 2.1 rc0

[Josh Elser]

Don't thank me yet, we haven't gotten the release out ;)

Gary Gregory wrote:

Thanks for RM'ing Josh! We're long overdue for a VFS release.

Gary

On Tue, May 3, 2016 at 6:50 PM, Josh Elser<els...@apache.org>  wrote:


This vote fails with one -1 and nothing else.

Going to be trying to roll an rc1 with the feedback given so far.

Josh Elser wrote:


All,

Please consider the following for Apache Commons VFS2 version 2.1 (rc0).

Maven repository:
https://repository.apache.org/content/repositories/orgapachecommons-1161

Artifacts:
https://dist.apache.org/repos/dist/dev/commons/vfs/{binaries,source}

Staged site:
http://home.apache.org/~elserj/commons/commons-vfs-2.1/index.html

All reports are available in the provided staged Maven site.
JIRA-generated release notes are available in the dist.a.o "Artifacts"
repository. Unit tests pass and the RC was built util JDK6.

The current code is available in branches/VFS-2.1 at r1741921. This is
what will be copied to tags upon successful passing of this vote.

This vote will be open for 72-hours, 2016/05/05 0500 UTC.

[ ] +1 Release these artifacts as version 2.1
[ ] 0 OK, but...
[ ] -1 I oppose these artifacts as version 2.1 because..

- Josh


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







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

[RESULT] [VOTE] Apache Commons-VFS2 2.1 rc0

[Josh Elser]

This vote fails with one -1 and nothing else.

Going to be trying to roll an rc1 with the feedback given so far.

Josh Elser wrote:

All,

Please consider the following for Apache Commons VFS2 version 2.1 (rc0).

Maven repository:
https://repository.apache.org/content/repositories/orgapachecommons-1161

Artifacts:
https://dist.apache.org/repos/dist/dev/commons/vfs/{binaries,source}

Staged site:
http://home.apache.org/~elserj/commons/commons-vfs-2.1/index.html

All reports are available in the provided staged Maven site.
JIRA-generated release notes are available in the dist.a.o "Artifacts"
repository. Unit tests pass and the RC was built util JDK6.

The current code is available in branches/VFS-2.1 at r1741921. This is
what will be copied to tags upon successful passing of this vote.

This vote will be open for 72-hours, 2016/05/05 0500 UTC.

[ ] +1 Release these artifacts as version 2.1
[ ] 0 OK, but...
[ ] -1 I oppose these artifacts as version 2.1 because..

- Josh


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

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

[Josh Elser]

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 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 2016 15:55:00 +0100
schrieb sebb<seb...@gmail.com>:


On 3 May 2016 at 01:43, Josh Elser<els...@apache.org>  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 incompatible software is a different thing.
For example, most of Commons depends on Java.
That is expected to be provided by the user, not us, so they take the
decision on the license.


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?

It depends on the exact license.
Some incompatible dependencies are OK as binaries

http://www.apache.org/legal/resolved.html#optional
and
http://www.apache.org/legal/resolved.html#prohibited

But given that the sandbox does not appear to be ready to release as
it stands, I would be inclined to move it into a branch.


e...@zusammenkunft.net wrote:

Hello,

Agree, the sandbox profile should be in the site build enabled,
but we cannot distribute the binaries as official release since it
has dependencies which are not Apache approved (and potentially
unfinished suff).

Gruss
Bernd


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


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




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



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

Re: [VOTE] Apache Commons-VFS2 2.1 rc0

[Josh Elser]

sebb wrote:

>  mvn site:stage is used expressly for this purpose. Maven has no problems
>  with properly constructed multi-module projects -- it's a fallacy that Maven
>  cannot handle multi-module projects well.


[Since Maven knows it is a multi-module project it should not need a
different command.
Or at least it should warn the user to start again]

I guess VFS is not properly constructed then.

I just tried mvn:site having cleared out the local repo of VFS stuff and I get:

[ERROR] Failed to execute goal on project commons-vfs2-examples: Could
not resolve dependencies for project
org.apache.commons:commons-vfs2-examples:jar:2.1: Could not find
artifact org.apache.commons:commons-vfs2:jar:2.1 in central
(https://repo.maven.apache.org/maven2) ->  [Help 1]

Whereas I just tried 'mvn site' with Commons Net3.5  and it worked fine.
It downloaded Net3.4  for Clirr, but otherwise did not need any Net jars.


That doesn't entirely surprise me, but it's definitely possible to work 
around. Short-term workaround would be (probably) `mvn package site`. I 
don't think site would bind to the package phase by default.



>  However, fixing it is a separate topic than this RC voting:)


Fixing what?



Fixing any oddness in the maven site for this project. The site can be 
built -- it's not a blocker for the release (at least no one has said it 
needs to be yet). Thus, we should have further discussion in something 
that isn't tagged as a [VOTE], IMO.


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

Re: [VOTE] Apache Commons-VFS2 2.1 rc0

[Josh Elser]

sebb wrote:

>>  Ideally the duplicate archives should be dropped, but that is not a
>>  blocker, just a nuisance when reviewing.

>
>
>  Yeah, I'll try to figure out what's going on with that when I roll rc1. I'm
>  not sure since it's not pulling directly from the apache.pom (I'm not sure
>  what all the commons parent pom is doing yet).


It would be a lot easier if VFS were a single module project.
Maven does not handle multi-module projects well.
For example I just tried "mvn site" in the RC directory and it
complained about not finding various bits of VFS in the repo.
This does not happen with single module projects.


mvn site:stage is used expressly for this purpose. Maven has no problems 
with properly constructed multi-module projects -- it's a fallacy that 
Maven cannot handle multi-module projects well.


However, fixing it is a separate topic than this RC voting :)

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

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

[Josh Elser]

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 moved to a branch.



lol, oh the missing "not" is pretty good.

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

Re: [VOTE] Apache Commons-VFS2 2.1 rc0

[Josh Elser]

sebb wrote:

>  Sebb -- would addressing these points in the release notes cause you to
>  change your -1 to a +1? I'd like to make all the changes I can ASAP and roll
>  the next RC. Because I haven't said it explicitly -- thanks for taking the
>  time to give all of the feedback that you have already.


I think we should drop sandbox from trunk entirely; that will resolve
the issues.


I agree with you completely.


Ideally the duplicate archives should be dropped, but that is not a
blocker, just a nuisance when reviewing.


Yeah, I'll try to figure out what's going on with that when I roll rc1. 
I'm not sure since it's not pulling directly from the apache.pom (I'm 
not sure what all the commons parent pom is doing yet).



I'm not yet convinced about the Clirr errors.
I tried running the previous tests jar against the current code.
There were some errors, but these may be due to code fixes. I've not
had time to investigate fully.
But in any case, the description in changes.xml needs to explain why
the Clirr errors are not a concern.


IIRC, the errors that I saw were about new methods or fields which 
should be fine for binary compatibility (sans the aforementioned Tar* 
classes). Given what you said earlier and my personal understanding, 
this should not affect binary compat.


I have it on my list to update the necessary docs with the "why" before rc1.

LMK if/when you decide for certain about the API additions and whether 
or not they're OK. Thanks.


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

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

[Josh Elser]

sebb wrote:

On 3 May 2016 at 01:43, Josh Elser<els...@apache.org>  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 didn't mean to imply that. Just a passing comment on the 'official 
release' phrase.



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?


It depends on the exact license.
Some incompatible dependencies are OK as binaries

http://www.apache.org/legal/resolved.html#optional
and
http://www.apache.org/legal/resolved.html#prohibited

But given that the sandbox does not appear to be ready to release as
it stands, I would be inclined to move it into 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.



e...@zusammenkunft.net wrote:

Hello,

Agree, the sandbox profile should be in the site build enabled, but we
cannot distribute the binaries as official release since it has dependencies
which are not Apache approved (and potentially unfinished suff).

Gruss
Bernd


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



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



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

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

[Josh Elser]

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 be in the site build enabled, but we cannot 
distribute the binaries as official release since it has dependencies which are 
not Apache approved (and potentially unfinished suff).

Gruss
Bernd



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

Re: [VOTE] Apache Commons-VFS2 2.1 rc0

[Josh Elser]

Josh Elser wrote:

sebb wrote:

On 2 May 2016 at 15:00, Josh Elser<els...@apache.org> wrote:

> Also, please re-read the end of the previous thread on compatibility.
>
> I clearly stated that there were some changes which I consider not
worth
> changing about the TarArchiveEntry code. If you feel like these are
not
> acceptable, please start a discussion about this so you can come to
> consensus on how the changes should be addressed.


The release vote mail really needs to include all the release-specific
information that the reviewer needs to do the review.

If there are caveats etc relating to the Clirr report these need to be
included in the vote mail.
Both to make it easier for the reviewers, and for the historical
record to show that these items were considered.



Ok, this was not made clear to me. Thank you for letting me know. I'd
encourage you to update your project's website. For other projects, I
assume that those voting would have the context from previous
discussions, but acknowledge that this is not how commons operates.


Sebb -- would addressing these points in the release notes cause you to 
change your -1 to a +1? I'd like to make all the changes I can ASAP and 
roll the next RC. Because I haven't said it explicitly -- thanks for 
taking the time to give all of the feedback that you have already.


Everyone else -- even though Sebb voted -1 on rc0, I would greatly 
appreciate if everyone could still look through rc0 and give any more 
feedback which would keep you from a +1.


Thanks.

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

Re: [VOTE] Apache Commons-VFS2 2.1 rc0

[Josh Elser]

I had just tried to make sure it was included in the build because I 
assumed that it was meant to be released :)


It's becoming apparent that was inaccurate.

Ralph Goers wrote:

As I recall 2.0 did not really include sandbox as part of the release because 
we didn’t want to officially support the sandbox components. They might have 
been included in the source distribution though. But these emails make it sound 
like it is exactly the opposite of what I would have expected.

Ralph


On May 2, 2016, at 6:35 AM, Josh Elser<els...@apache.org>  wrote:

sebb wrote:

The "Download and Build" page is more suitable for developers than end
users (especially if it points to trunk, which is not voted on) so
should not be the primary download page.

Also there seem to be two identical copies of each of the non-Maven
release artifacts:
commons-vfs-2.1-bin
and
commons-vfs2-distribution-2.1-bin

etc.


Are they supposed to be the same? If not what is missing from one of them?

I have no idea. This is just what your build process did...

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






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



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

Re: [VFS] JIRA Karma?

[Josh Elser]

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 issue to myself.



I've added you to the commons-developers group. You should now be able to
assign and modify issues.

Benedikt



Thanks in advance.

- Josh

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






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

Re: [VOTE] Apache Commons-VFS2 2.1 rc0

[Josh Elser]

sebb wrote:

http://home.apache.org/~elserj/commons/commons-vfs-2.1/index.html
mentions Release Notes but the link points to

https://archive.apache.org/dist/commons/vfs/RELEASE_NOTES.txt

which of course is for2.0.

It would be helpful to use the current release notes on the site.


Ok, I'll have to figure out how that gets wired up. I have no idea if 
that's dynamic or static.



The new RN at
https://dist.apache.org/repos/dist/dev/commons/vfs/RELEASE-NOTES.txt
don't mention any of the Clirr issues.


Ok, I will update that then.

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

Re: [VOTE] Apache Commons-VFS2 2.1 rc0

[Josh Elser]

sebb wrote:

On 2 May 2016 at 15:00, Josh Elser<els...@apache.org>  wrote:

>  Also, please re-read the end of the previous thread on compatibility.
>
>  I clearly stated that there were some changes which I consider not worth
>  changing about the TarArchiveEntry code. If you feel like these are not
>  acceptable, please start a discussion about this so you can come to
>  consensus on how the changes should be addressed.


The release vote mail really needs to include all the release-specific
information that the reviewer needs to do the review.

If there are caveats etc relating to the Clirr report these need to be
included in the vote mail.
Both to make it easier for the reviewers, and for the historical
record to show that these items were considered.



Ok, this was not made clear to me. Thank you for letting me know. I'd 
encourage you to update your project's website. For other projects, I 
assume that those voting would have the context from previous 
discussions, but acknowledge that this is not how commons operates.


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

Re: [VOTE] Apache Commons-VFS2 2.1 rc0

[Josh Elser]

Also, please re-read the end of the previous thread on compatibility.

I clearly stated that there were some changes which I consider not worth 
changing about the TarArchiveEntry code. If you feel like these are not 
acceptable, please start a discussion about this so you can come to 
consensus on how the changes should be addressed.


Josh Elser wrote:

Sebb -- did you actually read the changes?

You should note that those are all method additions which we already
decided were allowed

sebb wrote:

I have now found the Clirr Report at

http://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html


There are still some breaking changes that affect BC as far as I can
tell, so that means I need to vote

-1



On 2 May 2016 at 11:31, sebb<seb...@gmail.com> wrote:

Also the sandbox tree is missing from the source archives.
Yet there are sandbox jars in Nexus.
We cannot publish source to Maven that is not also in the source
artifacts.

If the sandbox code is not intended to be released, it should be moved
from trunk.


On 2 May 2016 at 11:16, sebb<seb...@gmail.com> wrote:

Also please include a link to the KEYS file, i.e.

https://www.apache.org/dist/commons/KEYS

Note that the standard download page is

http://home.apache.org/~elserj/commons/commons-vfs-2.1/download_vfs.html


I think that should be in the site menu.

The "Download and Build" page is more suitable for developers than end
users (especially if it points to trunk, which is not voted on) so
should not be the primary download page.

Also there seem to be two identical copies of each of the non-Maven
release artifacts:
commons-vfs-2.1-bin
and
commons-vfs2-distribution-2.1-bin

etc.


Are they supposed to be the same? If not what is missing from one of
them?

On 2 May 2016 at 10:40, sebb<seb...@gmail.com> wrote:

On 2 May 2016 at 05:28, Josh Elser<els...@apache.org> wrote:

All,

Please consider the following for Apache Commons VFS2 version 2.1
(rc0).

Maven repository:
https://repository.apache.org/content/repositories/orgapachecommons-1161


The e-mail should contain the hashes of the release items as the above
URL is transitory.
The hashes allow one to tie the released files back to the vote
thread.

They can be copied from the Nexus mail.


Artifacts:
https://dist.apache.org/repos/dist/dev/commons/vfs/{binaries,source}

Likewise here we include the revision id of the URL:

https://dist.apache.org/repos/dist/dev/commons/vfs/



Staged site:
http://home.apache.org/~elserj/commons/commons-vfs-2.1/index.html

There's no Clirr report that I could find.

Also the download page links to trunk rather than the specific tag.


All reports are available in the provided staged Maven site.
JIRA-generated
release notes are available in the dist.a.o "Artifacts"
repository. Unit
tests pass and the RC was built util JDK6.

E-mail should really have URL to make it easy for reviewers.


The current code is available in branches/VFS-2.1 at r1741921.
This is what
will be copied to tags upon successful passing of this vote.

Full URLs in e-mails please.
Also it should be a TAG not a branch, as it should be kept if the vote
is successful


This vote will be open for 72-hours, 2016/05/05 0500 UTC.

[ ] +1 Release these artifacts as version 2.1
[ ] 0 OK, but...
[X] -1 I oppose these artifacts as version 2.1 because..

As above.

No need necessarily to rebuild everything as most of the concerns
relate to the vote e-mail and the site.
e.g. you can rename the branch as a tag.


- Josh

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



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



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

Re: [VOTE] Apache Commons-VFS2 2.1 rc0

[Josh Elser]

sebb wrote:

The "Download and Build" page is more suitable for developers than end
users (especially if it points to trunk, which is not voted on) so
should not be the primary download page.

Also there seem to be two identical copies of each of the non-Maven
release artifacts:
commons-vfs-2.1-bin
and
commons-vfs2-distribution-2.1-bin

etc.


Are they supposed to be the same? If not what is missing from one of them?


I have no idea. This is just what your build process did...

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

Re: [VOTE] Apache Commons-VFS2 2.1 rc0

[Josh Elser]

Josh Elser wrote:

Sebb wrote:

> Please consider the following for Apache Commons VFS2 version 2.1
(rc0).
>
> Maven repository:
>
https://repository.apache.org/content/repositories/orgapachecommons-1161


The e-mail should contain the hashes of the release items as the above
URL is transitory.
The hashes allow one to tie the released files back to the vote thread.


Ugh, this is what happens when I try to finish this up late at night :)


Also, it's worth nothing that your email template on the website 
(https://commons.apache.org/releases/prepare.html) does not include 
instructions for this which is what I'll blame for forgetting to do this 
on my own.


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

Re: [VOTE] Apache Commons-VFS2 2.1 rc0

[Josh Elser]

(So sorry, fingers sent too quick)

commons-vfs-2.1-bin.tar.gz:
MD5 fdaad280f3d3c592df048a58bfa8debd
SHA1 edfa8ac8c31e2e4b88898ac2418f9e7a7fe34324

commons-vfs-2.1-bin.zip:
MD5 951448d632ff37363c4bd0dcad3a887e
SHA1 2fd9262d349f6d62eb34912a7d56d406b7655568

My GPG key is 4677D66C

Josh Elser wrote:

Forgot to include xsum/sig info:

commons-vfs-2.1-src.tar.gz:
MD5 f768cf5f2d00cfa58b70d221054ca1c9
SHA1 d5a53ecf575e961b2e6b472e8bf5b013b33bfa78

commons-vfs-2.1-src.zip:
MD5 2eb6a10883b77ce137a391a7dd341120
SHA1 f831eb7cb62df295ef8b1a090e209550c6ea5c35

Josh Elser wrote:

All,

Please consider the following for Apache Commons VFS2 version 2.1 (rc0).

Maven repository:
https://repository.apache.org/content/repositories/orgapachecommons-1161

Artifacts:
https://dist.apache.org/repos/dist/dev/commons/vfs/{binaries,source}

Staged site:
http://home.apache.org/~elserj/commons/commons-vfs-2.1/index.html

All reports are available in the provided staged Maven site.
JIRA-generated release notes are available in the dist.a.o "Artifacts"
repository. Unit tests pass and the RC was built util JDK6.

The current code is available in branches/VFS-2.1 at r1741921. This is
what will be copied to tags upon successful passing of this vote.

This vote will be open for 72-hours, 2016/05/05 0500 UTC.

[ ] +1 Release these artifacts as version 2.1
[ ] 0 OK, but...
[ ] -1 I oppose these artifacts as version 2.1 because..

- Josh


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



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

Re: [VOTE] Apache Commons-VFS2 2.1 rc0

[Josh Elser]

Forgot to include xsum/sig info:

commons-vfs-2.1-src.tar.gz:
MD5 f768cf5f2d00cfa58b70d221054ca1c9
SHA1 d5a53ecf575e961b2e6b472e8bf5b013b33bfa78

commons-vfs-2.1-src.zip:
MD5 2eb6a10883b77ce137a391a7dd341120
SHA1 f831eb7cb62df295ef8b1a090e209550c6ea5c35

Josh Elser wrote:

All,

Please consider the following for Apache Commons VFS2 version 2.1 (rc0).

Maven repository:
https://repository.apache.org/content/repositories/orgapachecommons-1161

Artifacts:
https://dist.apache.org/repos/dist/dev/commons/vfs/{binaries,source}

Staged site:
http://home.apache.org/~elserj/commons/commons-vfs-2.1/index.html

All reports are available in the provided staged Maven site.
JIRA-generated release notes are available in the dist.a.o "Artifacts"
repository. Unit tests pass and the RC was built util JDK6.

The current code is available in branches/VFS-2.1 at r1741921. This is
what will be copied to tags upon successful passing of this vote.

This vote will be open for 72-hours, 2016/05/05 0500 UTC.

[ ] +1 Release these artifacts as version 2.1
[ ] 0 OK, but...
[ ] -1 I oppose these artifacts as version 2.1 because..

- Josh


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

Re: [VOTE] Apache Commons-VFS2 2.1 rc0

[Josh Elser]

Hrm, so I either botched the build command (highly possible) or the 
source archive is screwed up and doesn't include it.


Can someone please enlighten me as to whether or not the sandbox should 
actually be included?


sebb wrote:

Also the sandbox tree is missing from the source archives.
Yet there are sandbox jars in Nexus.
We cannot publish source to Maven that is not also in the source artifacts.

If the sandbox code is not intended to be released, it should be moved
from trunk.


On 2 May 2016 at 11:16, sebb<seb...@gmail.com>  wrote:

Also please include a link to the KEYS file, i.e.

https://www.apache.org/dist/commons/KEYS

Note that the standard download page is

http://home.apache.org/~elserj/commons/commons-vfs-2.1/download_vfs.html

I think that should be in the site menu.

The "Download and Build" page is more suitable for developers than end
users (especially if it points to trunk, which is not voted on) so
should not be the primary download page.

Also there seem to be two identical copies of each of the non-Maven
release artifacts:
commons-vfs-2.1-bin
and
commons-vfs2-distribution-2.1-bin

etc.


Are they supposed to be the same? If not what is missing from one of them?

On 2 May 2016 at 10:40, sebb<seb...@gmail.com>  wrote:

On 2 May 2016 at 05:28, Josh Elser<els...@apache.org>  wrote:

All,

Please consider the following for Apache Commons VFS2 version 2.1 (rc0).

Maven repository:
https://repository.apache.org/content/repositories/orgapachecommons-1161

The e-mail should contain the hashes of the release items as the above
URL is transitory.
The hashes allow one to tie the released files back to the vote thread.

They can be copied from the Nexus mail.


Artifacts:
https://dist.apache.org/repos/dist/dev/commons/vfs/{binaries,source}

Likewise here we include the revision id of the URL:

https://dist.apache.org/repos/dist/dev/commons/vfs/



Staged site:
http://home.apache.org/~elserj/commons/commons-vfs-2.1/index.html

There's no Clirr report that I could find.

Also the download page links to trunk rather than the specific tag.


All reports are available in the provided staged Maven site. JIRA-generated
release notes are available in the dist.a.o "Artifacts" repository. Unit
tests pass and the RC was built util JDK6.

E-mail should really have URL to make it easy for reviewers.


The current code is available in branches/VFS-2.1 at r1741921. This is what
will be copied to tags upon successful passing of this vote.

Full URLs in e-mails please.
Also it should be a TAG not a branch, as it should be kept if the vote
is successful


This vote will be open for 72-hours, 2016/05/05 0500 UTC.

   [ ] +1 Release these artifacts as version 2.1
   [ ] 0  OK, but...
   [X] -1 I oppose these artifacts as version 2.1 because..

As above.

No need necessarily to rebuild everything as most of the concerns
relate to the vote e-mail and the site.
e.g. you can rename the branch as a tag.


- Josh

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



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



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

Re: [VOTE] Apache Commons-VFS2 2.1 rc0

[Josh Elser]

Sebb -- did you actually read the changes?

You should note that those are all method additions which we already 
decided were allowed


sebb wrote:

I have now found the Clirr Report at

http://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html

There are still some breaking changes that affect BC as far as I can
tell, so that means I need to vote

-1



On 2 May 2016 at 11:31, sebb<seb...@gmail.com>  wrote:

Also the sandbox tree is missing from the source archives.
Yet there are sandbox jars in Nexus.
We cannot publish source to Maven that is not also in the source artifacts.

If the sandbox code is not intended to be released, it should be moved
from trunk.


On 2 May 2016 at 11:16, sebb<seb...@gmail.com>  wrote:

Also please include a link to the KEYS file, i.e.

https://www.apache.org/dist/commons/KEYS

Note that the standard download page is

http://home.apache.org/~elserj/commons/commons-vfs-2.1/download_vfs.html

I think that should be in the site menu.

The "Download and Build" page is more suitable for developers than end
users (especially if it points to trunk, which is not voted on) so
should not be the primary download page.

Also there seem to be two identical copies of each of the non-Maven
release artifacts:
commons-vfs-2.1-bin
and
commons-vfs2-distribution-2.1-bin

etc.


Are they supposed to be the same? If not what is missing from one of them?

On 2 May 2016 at 10:40, sebb<seb...@gmail.com>  wrote:

On 2 May 2016 at 05:28, Josh Elser<els...@apache.org>  wrote:

All,

Please consider the following for Apache Commons VFS2 version 2.1 (rc0).

Maven repository:
https://repository.apache.org/content/repositories/orgapachecommons-1161

The e-mail should contain the hashes of the release items as the above
URL is transitory.
The hashes allow one to tie the released files back to the vote thread.

They can be copied from the Nexus mail.


Artifacts:
https://dist.apache.org/repos/dist/dev/commons/vfs/{binaries,source}

Likewise here we include the revision id of the URL:

https://dist.apache.org/repos/dist/dev/commons/vfs/



Staged site:
http://home.apache.org/~elserj/commons/commons-vfs-2.1/index.html

There's no Clirr report that I could find.

Also the download page links to trunk rather than the specific tag.


All reports are available in the provided staged Maven site. JIRA-generated
release notes are available in the dist.a.o "Artifacts" repository. Unit
tests pass and the RC was built util JDK6.

E-mail should really have URL to make it easy for reviewers.


The current code is available in branches/VFS-2.1 at r1741921. This is what
will be copied to tags upon successful passing of this vote.

Full URLs in e-mails please.
Also it should be a TAG not a branch, as it should be kept if the vote
is successful


This vote will be open for 72-hours, 2016/05/05 0500 UTC.

   [ ] +1 Release these artifacts as version 2.1
   [ ] 0  OK, but...
   [X] -1 I oppose these artifacts as version 2.1 because..

As above.

No need necessarily to rebuild everything as most of the concerns
relate to the vote e-mail and the site.
e.g. you can rename the branch as a tag.


- Josh

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



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



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

Re: [VOTE] Apache Commons-VFS2 2.1 rc0

[Josh Elser]

Sebb wrote:

>  Please consider the following for Apache Commons VFS2 version 2.1 (rc0).
>
>  Maven repository:
>  https://repository.apache.org/content/repositories/orgapachecommons-1161


The e-mail should contain the hashes of the release items as the above
URL is transitory.
The hashes allow one to tie the released files back to the vote thread.


Ugh, this is what happens when I try to finish this up late at night :)

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

[VOTE] Apache Commons-VFS2 2.1 rc0

[Josh Elser]

All,

Please consider the following for Apache Commons VFS2 version 2.1 (rc0).

Maven repository: 
https://repository.apache.org/content/repositories/orgapachecommons-1161


Artifacts: 
https://dist.apache.org/repos/dist/dev/commons/vfs/{binaries,source}


Staged site: 
http://home.apache.org/~elserj/commons/commons-vfs-2.1/index.html


All reports are available in the provided staged Maven site. 
JIRA-generated release notes are available in the dist.a.o "Artifacts" 
repository. Unit tests pass and the RC was built util JDK6.


The current code is available in branches/VFS-2.1 at r1741921. This is 
what will be copied to tags upon successful passing of this vote.


This vote will be open for 72-hours, 2016/05/05 0500 UTC.

  [ ] +1 Release these artifacts as version 2.1
  [ ] 0  OK, but...
  [ ] -1 I oppose these artifacts as version 2.1 because..

- Josh

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

[VFS] JIRA Karma?

[Josh Elser]

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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VFS] 2.1 clirr report

[Josh Elser]

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 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 these changes, and, IMO, calling out VFS-377 as
"intentionally changed" is fine.
work).

Bernd -- I think this also helps out the changes you suggested making.

But again, I'd *really* like to get consensus from the PMC. I'm stuck on
making an RC until you all can agree what should be done :). I'll be
committing the changes to (mostly) restore binary compat shortly.

sebb wrote:

Has anyone looked at whether the changes really do affect BC?
Note that the Maven Clirr does not distinguish between source compat
and BC.
Breaking source compat is not as serious an issue.

For example, the new methds in various interfaces don't affect BC:

https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.5.3-100


Some of the changes clearly do affect BC, but has anyone looked at
whether the old API can be implemented in terms of the new?

It may be a bit tedious to check, but if BC can be achieved then it
reduces the downstream effort needed.


On 30 April 2016 at 00:00, Josh Elser<els...@apache.org> wrote:

So, just call 2.1 instead 3.0? Fine by me.

Package name becomes o.a.c.vfs3? ArtifactId becomes (variants of)
commons-vfs3? Please confirm, Gary.

I don't think we need to expound any more about why compatibility is
important. No one has even presented any such argument. Let's stick to
action :)


Gary Gregory wrote:

Let's look at this from a different POV:

1) If we release 2.1 as is, we are creating a risk. We are strictly
speaking breaking BC.
2) If we release trunk as 3.0 with a package and Maven coordinate
change,
then there is zero risk. If you want to use the new version, you MUST
change your imports.

The risk, as remote as it may seem, is what I run into regularly
dealing
with a deep stack: I do not depend on jar Z but I depend on X, I
compile
against X. X depends on Y depends on Z. If there is BC problem in X,
I can
deal with it. If it is in Y or Z then I am due for some hacking.

For example, here are two BC breaks in maintenance releases I recently
found:

- https://issues.apache.org/jira/browse/WSS-577 Binary compatibility
broken
between version<=2.1.3 and>=2.1.4 with
org.apache.wss4j.dom.WSSecurityEngineResult
- https://issues.apache.org/jira/browse/SANTUARIO-440 Binary
compatibility
broken between version 2.0.5 and 2.0.4 in
org.apache.xml.security.c14n.CanonicalizationException

In these two cases, I was very lucky that I could change my source
code to
match the changes. But these changes should have never been made in a
maintenance release.

So... the least risky option is (2), which is a 0-risk option.

Gary

On Fri, Apr 29, 2016 at 3:11 PM, Josh Elser<els...@apache.org> wrote:


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 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 -
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<ralph.go...@dslextreme.com>

wrote:

On Apr 29, 2016, at 10:57 AM, Josh Elser<els...@apache.org> wrote:



Ralph Goers wrote:


On Apr 29, 2016, at 9:27 AM, Josh Elser<els...@apache.org> wrote:

sebb wrote:


On 29 April 2016 at 16:19, Josh Elser<els...@apache.org> wrote:


sebb wrote:


On 29 April 2016 at 15:59, Josh Elser<els...@apache.org>
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
coords.

Effectively it's a different component, and users have to
change
the
import package names.


How is that at all improving *any* level of compatibility? I
really
don't
see how that is providing any service to your users. Now,
instead
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 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
r

Re: [VFS] 2.1 clirr report

[Josh Elser]

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 these changes, and, IMO, calling out VFS-377 as 
"intentionally changed" is fine.

work).

Bernd -- I think this also helps out the changes you suggested making.

But again, I'd *really* like to get consensus from the PMC. I'm stuck on 
making an RC until you all can agree what should be done :). I'll be 
committing the changes to (mostly) restore binary compat shortly.


sebb wrote:

Has anyone looked at whether the changes really do affect BC?
Note that the Maven Clirr does not distinguish between source compat and BC.
Breaking source compat is not as serious an issue.

For example, the new methds in various interfaces don't affect BC:

https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.5.3-100

Some of the changes clearly do affect BC, but has anyone looked at
whether the old API can be implemented in terms of the new?

It may be a bit tedious to check, but if BC can be achieved then it
reduces the downstream effort needed.


On 30 April 2016 at 00:00, Josh Elser<els...@apache.org>  wrote:

So, just call 2.1 instead 3.0? Fine by me.

Package name becomes o.a.c.vfs3? ArtifactId becomes (variants of)
commons-vfs3? Please confirm, Gary.

I don't think we need to expound any more about why compatibility is
important. No one has even presented any such argument. Let's stick to
action :)


Gary Gregory wrote:

Let's look at this from a different POV:

1) If we release 2.1 as is, we are creating a risk. We are strictly
speaking breaking BC.
2) If we release trunk as 3.0 with a package and Maven coordinate change,
then there is zero risk. If you want to use the new version, you MUST
change your imports.

The risk, as remote as it may seem, is what I run into regularly dealing
with a deep stack: I do not depend on jar Z but I depend on X, I compile
against X. X depends on Y depends on Z. If there is BC problem in X, I can
deal with it. If it is in Y or Z then I am due for some hacking.

For example, here are two BC breaks in maintenance releases I recently
found:

- https://issues.apache.org/jira/browse/WSS-577 Binary compatibility
broken
between version<=2.1.3 and>=2.1.4 with
org.apache.wss4j.dom.WSSecurityEngineResult
- https://issues.apache.org/jira/browse/SANTUARIO-440 Binary compatibility
broken between version 2.0.5 and 2.0.4 in
org.apache.xml.security.c14n.CanonicalizationException

In these two cases, I was very lucky that I could change my source code to
match the changes. But these changes should have never been made in a
maintenance release.

So... the least risky option is (2), which is a 0-risk option.

Gary

On Fri, Apr 29, 2016 at 3:11 PM, Josh Elser<els...@apache.org>   wrote:


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 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 -
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<ralph.go...@dslextreme.com>

wrote:

On Apr 29, 2016, at 10:57 AM, Josh Elser<els...@apache.org>wrote:



Ralph Goers wrote:


On Apr 29, 2016, at 9:27 AM, Josh Elser<els...@apache.org> wrote:

sebb wrote:


On 29 April 2016 at 16:19, Josh Elser<els...@apache.org>  wrote:


sebb wrote:


On 29 April 2016 at 15:59, Josh Elser<els...@apache.org>
   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 coords.

Effectively it's a different component, and users have to change
the
import package names.


How is that at all improving *any* level of compatibility? I
really
don't
see how that is providing any service to your users. Now, instead
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 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 place of the old one and
their application gets runtime errors then, by definition, bina

Re: [VFS] 2.1 clirr report

[Josh Elser]

So, just call 2.1 instead 3.0? Fine by me.

Package name becomes o.a.c.vfs3? ArtifactId becomes (variants of) 
commons-vfs3? Please confirm, Gary.


I don't think we need to expound any more about why compatibility is 
important. No one has even presented any such argument. Let's stick to 
action :)


Gary Gregory wrote:

Let's look at this from a different POV:

1) If we release 2.1 as is, we are creating a risk. We are strictly
speaking breaking BC.
2) If we release trunk as 3.0 with a package and Maven coordinate change,
then there is zero risk. If you want to use the new version, you MUST
change your imports.

The risk, as remote as it may seem, is what I run into regularly dealing
with a deep stack: I do not depend on jar Z but I depend on X, I compile
against X. X depends on Y depends on Z. If there is BC problem in X, I can
deal with it. If it is in Y or Z then I am due for some hacking.

For example, here are two BC breaks in maintenance releases I recently
found:

- https://issues.apache.org/jira/browse/WSS-577 Binary compatibility broken
between version<=2.1.3 and>=2.1.4 with
org.apache.wss4j.dom.WSSecurityEngineResult
- https://issues.apache.org/jira/browse/SANTUARIO-440 Binary compatibility
broken between version 2.0.5 and 2.0.4 in
org.apache.xml.security.c14n.CanonicalizationException

In these two cases, I was very lucky that I could change my source code to
match the changes. But these changes should have never been made in a
maintenance release.

So... the least risky option is (2), which is a 0-risk option.

Gary

On Fri, Apr 29, 2016 at 3:11 PM, Josh Elser<els...@apache.org>  wrote:


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 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 -
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<ralph.go...@dslextreme.com>

wrote:

On Apr 29, 2016, at 10:57 AM, Josh Elser<els...@apache.org>   wrote:



Ralph Goers wrote:


On Apr 29, 2016, at 9:27 AM, Josh Elser<els...@apache.org>wrote:

sebb wrote:


On 29 April 2016 at 16:19, Josh Elser<els...@apache.org> wrote:


sebb wrote:


On 29 April 2016 at 15:59, Josh Elser<els...@apache.org>
  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 coords.

Effectively it's a different component, and users have to change
the
import package names.


How is that at all improving *any* level of compatibility? I really
don't
see how that is providing any service to your users. Now, instead
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 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 place of the old one and
their application gets runtime errors then, by definition, binary
compatibility is broken.  This can happen if the user implemented their own
FileSystem and are using interfaces that have had new methods added. It can
happen if public methods have had signatures change.  If any of these
happen then Commons policy is that the package names must change and the
artifact id must change, as the jar is no longer compatible with the old
one.  This allows the old jar and the new jar to be used side-by-side.


Ok. Can you point me at this documentation? Apparently the issues I
take with this are more engrained into all of Commons :)


I would have to search the dev mailing list but this has been discussed
in the past.  The first link below discusses the versioning policy but does
not explicitly call out changing the package name and artifactid. The
second two links are example of release announcements for incompatible
releases.

https://commons.apache.org/releases/versioning.html<
https://commons.apache.org/releases/versioning.html>   <
https://commons.apache.org/releases/versioning.html<
https://commons.apache.org/releases/versioning.html>>

http://www.h-online.com/open/news/item/Apache-Commons-Lang-3-0-makes-a-break-with-the-past-1283761.html
<
http://www.h-online.com/open/news/item/Apache-Commons-Lang-3-0-makes-a-break-with-the-past-1283761.html>
&l

Re: [VFS] 2.1 clirr report

[Josh Elser]

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 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 - 
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<ralph.go...@dslextreme.com>  wrote:


On Apr 29, 2016, at 10:57 AM, Josh Elser<els...@apache.org>  wrote:



Ralph Goers wrote:

On Apr 29, 2016, at 9:27 AM, Josh Elser<els...@apache.org>   wrote:

sebb wrote:

On 29 April 2016 at 16:19, Josh Elser<els...@apache.org>wrote:

sebb wrote:

On 29 April 2016 at 15:59, Josh Elser<els...@apache.org> 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 coords.
Effectively it's a different component, and users have to change the
import package names.

How is that at all improving *any* level of compatibility? I really don't
see how that is providing any service to your users. Now, instead 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 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 place of the old one and their 
application gets runtime errors then, by definition, binary compatibility is 
broken.  This can happen if the user implemented their own FileSystem and are 
using interfaces that have had new methods added. It can happen if public 
methods have had signatures change.  If any of these happen then Commons policy 
is that the package names must change and the artifact id must change, as the 
jar is no longer compatible with the old one.  This allows the old jar and the 
new jar to be used side-by-side.

Ok. Can you point me at this documentation? Apparently the issues I take with 
this are more engrained into all of Commons :)

I would have to search the dev mailing list but this has been discussed in the 
past.  The first link below discusses the versioning policy but does not 
explicitly call out changing the package name and artifactid. The second two 
links are example of release announcements for incompatible releases.

https://commons.apache.org/releases/versioning.html<https://commons.apache.org/releases/versioning.html>
  
<https://commons.apache.org/releases/versioning.html<https://commons.apache.org/releases/versioning.html>>
http://www.h-online.com/open/news/item/Apache-Commons-Lang-3-0-makes-a-break-with-the-past-1283761.html<http://www.h-online.com/open/news/item/Apache-Commons-Lang-3-0-makes-a-break-with-the-past-1283761.html>
  
<http://www.h-online.com/open/news/item/Apache-Commons-Lang-3-0-makes-a-break-with-the-past-1283761.html<http://www.h-online.com/open/news/item/Apache-Commons-Lang-3-0-makes-a-break-with-the-past-1283761.html>>
https://commons.apache.org/proper/commons-collections/release_4_0.html<https://commons.apache.org/proper/commons-collections/release_4_0.html>
  
<https://commons.apache.org/proper/commons-collections/release_4_0.html<https://commons.apache.org/proper/commons-collections/release_4_0.html>>

Ralph





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

Re: [VFS] 2.1 clirr report

[Josh Elser]

Ralph Goers wrote:

On Apr 29, 2016, at 9:27 AM, Josh Elser<els...@apache.org>  wrote:

sebb wrote:

On 29 April 2016 at 16:19, Josh Elser<els...@apache.org>   wrote:

sebb wrote:

On 29 April 2016 at 15:59, Josh Elser<els...@apache.org>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 coords.
Effectively it's a different component, and users have to change the
import package names.

How is that at all improving *any* level of compatibility? I really don't
see how that is providing any service to your users. Now, instead 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 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 place of the old one and their 
application gets runtime errors then, by definition, binary compatibility is 
broken.  This can happen if the user implemented their own FileSystem and are 
using interfaces that have had new methods added. It can happen if public 
methods have had signatures change.  If any of these happen then Commons policy 
is that the package names must change and the artifact id must change, as the 
jar is no longer compatible with the old one.  This allows the old jar and the 
new jar to be used side-by-side.


Ok. Can you point me at this documentation? Apparently the issues I take 
with this are more engrained into all of Commons :)


If it's not yet clear, I do not have any confusion about what source and 
binary compatibility is. My confusion is around Commons' application of 
"compatibility", specifically, my current understanding of what is done 
for compatibility would make me unhappy as a user. However, that is a 
completely separate discussion that can be had at a later time.


My goal here is to find out what the Commons PMC considers to be 
blockers to a release so I can avoid wasting time in cutting RCs that 
will just be immediately -1'ed. That's why I keep asking for 
documentation on your policies :)


I still don't have a clear understanding of what *needs* to be done to 
cut 2.1 which is why I keep poking at this all, trying to get an answer 
by understanding your policies.



What matters is what the expectation is as to how users are going to use VFS in 
their projects.  Most will use the providers that we have created. Some may 
implement their own.  We may say that most users can just drop in the jar but 
if you are doing a), b) and/or c) (whatever those are defined to be) that you 
must recompile your code.


Is this an indirect way of asking me as release manager to enumerate 
this "matrix" for you then as a part of the release process or are you 
just stating your view of how you would like it work?


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

Re: [VFS] 2.1 clirr report

[Josh Elser]

sebb wrote:

On 29 April 2016 at 16:19, Josh Elser<els...@apache.org>  wrote:

sebb wrote:

On 29 April 2016 at 15:59, Josh Elser<els...@apache.org>   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 coords.
Effectively it's a different component, and users have to change the
import package names.


How is that at all improving *any* level of compatibility? I really don't
see how that is providing any service to your users. Now, instead 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 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.



  Where do you all define what is public API (and thus what is stated to
be
  stable)?



That's the big question...


So, let me give some personal opinions here: you cannot claim to have any
level of compatibility if you do not prominently define what is subject to
compatibility. Just take a look at the introduction on semver[1]: "For this
system to work, you first need to declare a public API".

It is my strong opinion that any attempt to "improve compatibility" is
pointless if you haven't actually put forth the effort to define what you're
keeping compatible.

The feeling I'm getting is that this is not defined. As such, I feel this is
going the same way as the "we should upgrade min JDK" and "we should upgrade
dependencies" -- it's not ready to go and should be addressed in a future
release.

I don't want to come across as dismissive, but I've had this conversation
with more than one other project in the past. If there are concerns, let's
state them, discuss how they be addressed, and move on so we can avoid
unclear worries.


I agree that we are not very good at defining what is public API.

Or rather, we are not very good at defining what is *not* intended to be public.

This is a general problem with Java projects that have more than one
level of package.
Methods and fields often have to be made public or protected to
satisfy internal use.

So in the end it may come down to a judgement call as to which parts
of the otherwise public API are unlikely to be used externally.


A common approach is to define artifacts or specifics packages 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 undefined) 
and it should not hold up a release of 2.1 (my two cents).


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

Re: [VFS] 2.1 clirr report

[Josh Elser]

sebb wrote:

On 29 April 2016 at 15:59, Josh Elser<els...@apache.org>  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 coords.
Effectively it's a different component, and users have to change the
import package names.


How is that at all improving *any* level of compatibility? I really 
don't see how that is providing any service to your users. Now, instead 
of just updating the version for the artifact and adding the new 
methods, they *also* have to change the package...



>  Where do you all define what is public API (and thus what is stated to be
>  stable)?
>


That's the big question...



So, let me give some personal opinions here: you cannot claim to have 
any level of compatibility if you do not prominently define what is 
subject to compatibility. Just take a look at the introduction on 
semver[1]: "For this system to work, you first need to declare a public 
API".


It is my strong opinion that any attempt to "improve compatibility" is 
pointless if you haven't actually put forth the effort to define what 
you're keeping compatible.


The feeling I'm getting is that this is not defined. As such, I feel 
this is going the same way as the "we should upgrade min JDK" and "we 
should upgrade dependencies" -- it's not ready to go and should be 
addressed in a future release.


I don't want to come across as dismissive, but I've had this 
conversation with more than one other project in the past. If there are 
concerns, let's state them, discuss how they be addressed, and move on 
so we can avoid unclear worries.


[1] http://semver.org/

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

Re: [patch] Add elserj to KEYS

[Josh Elser]

Thanks, sebb. That did the trick.

sebb wrote:

Try again.

I added you to the commons unix group

On 29 April 2016 at 05:03, Josh Elser<els...@apache.org>  wrote:

Can someone add my key to
https://dist.apache.org/repos/dist/release/commons/KEYS, please? It would
appear that I lack the required karma.

Thanks in advance.

- Josh


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


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



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

Re: [VFS] 2.1 clirr report

[Josh Elser]

How does changing the package name help? Doesn't that just push a 
NoClassDefFound error instead of some missing implementation for a new 
method?


Where do you all define what is public API (and thus what is stated to 
be stable)?


Gary Gregory wrote:

We have 2 choices IMO: document breaks or change package name. The later is
safer from a jar hell POV.

The question is how likely are the changes going to break BC IRL? There are
two main use cases: user like call sites and implementors of providers.

Thoughts?

Gary
It looks like there are about 7 areas in core/ where compatibility against
2.0 has been broken:

* Methods added to o.a.c.v.{FileContent,FileName,FileObject}
* Method added to o.a.c.v.RandomAccessContent
* Parameters 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 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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



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

[patch] Add elserj to KEYS

[Josh Elser]

Can someone add my key to 
https://dist.apache.org/repos/dist/release/commons/KEYS, please? It 
would appear that I lack the required karma.


Thanks in advance.

- Josh
Index: KEYS
===
--- KEYS(revision 13454)
+++ KEYS(working copy)
@@ -5520,3 +5520,100 @@
 EaWfWeQZ4Q==
 =b8+3
 -END PGP PUBLIC KEY BLOCK-
+
+pub   4096R/4677D66C 2013-05-04
+uid  Josh Elser (Apache) <els...@apache.org>
+sig 34677D66C 2016-04-06  Josh Elser (Apache) <els...@apache.org>
+uid      Josh Elser <josh.el...@gmail.com>
+sig 34677D66C 2013-05-04  Josh Elser (Apache) <els...@apache.org>
+sig  00B6899D 2013-05-04  Christopher L Tubbs II (Christopher) 
<ctubb...@gmail.com>
+sigR ABBA8A49 2013-05-04  Eric Newton <eric.new...@gmail.com>
+sub   4096R/99D5F66C 2013-05-04
+sig  4677D66C 2013-05-04  Josh Elser (Apache) <els...@apache.org>
+
+-BEGIN PGP PUBLIC KEY BLOCK-
+
+mQINBFGFRlQBEACk3q10Uf5vjHZ8rsSt2DA/GSvST6CCvqPPk56dmtLCs8ojO0rb
+aOXXx1DFrrm9BILSp1edhPpCs+KbQnpO8f1YM+k+WY3lc/Ah0X5oUQQranCjC/Qi
+Uf1tgp9xLG58ic1zVov8QGhyC+7XjA03pZe86izv6UvfL6ufU8XicnIYlRBugkg9
+bkjjM6A3OZLFoxEp20KdeWqhTOjCEDR1ocNcQ4IF64iVU/Stnn5KmywhzlfwWoGZ
+kFAzxEyghD/49+oANPJtnL2aZ1FS9ZiR/dkR73nDPWDioS1MusMwlNDErzoqpJLK
+UyePh3AxY+v3R9oo+Mu1Nxmp7bIoyCmnxufOCUOtxSVpMMWOBsdpMKuMgG6GyBKR
+wP2mAPHgMwKfLeqsiKUTZHzspUshsHovuVYcGbpV9in27fo7K7bKf3M7CE639a+e
+Wz8sIhQ0wj9IPqt96t56LhINDSbG2DOJY5m5ljxmSaM3Z59QgU191b7ZAn6GLszM
+OZL9qpPf/oCjHuYs1qJFrWALvdRFXYD6cd8BrtBP+mpgnYFLEZ8lBBeJKKJxaxxb
+gk/TOzXqBxigz7fvMc9FoNEbZiJkIsquKUko3YohrAYVIIDzJKV6buP6IJg95LYb
+i94zd65OzHvjQV3ljo9mt60wgMhdLDOCKV4d++zutkekzrXNTYhk0HjjwwARAQAB
+tCFKb3NoIEVsc2VyIDxqb3NoLmVsc2VyQGdtYWlsLmNvbT6JAjcEEwEKACEFAlGF
+RlQCGwMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AACgkQt9XNRUZ31mzzBBAAkfuT
+HhL5vAxRy780dV4jIE+CjK242DlATe8J8xAP4kF34WD4qijDnysaGqNFNBO7sq1+
+EBn1OizYPcMEIwhoqZ9bBjwRGPmHyM3Y6vKFnXQwl+YR3gpYYR4csh2ZD9iX+U74
+jo+2tHICbCdpjQkAUe0yIivT3GMntKuaGuHZx0+0qmtNeYSjuuKyl+9V1/mTPUQA
+EUcPpG3BFpFURYDf0W39uGJMBUXLGB3dJiwb0Y0/NDFAZubuO2uUc0ihlaYMvYqw
+lhxI4BWxoLwSE1ATAyM04iLld6qNk/c35jb+NNsl07BC26A4nQdNa+L1V2M2pe25
+0zU65CATNdLf5T+Rg9i1k7li1KJmL9SzyDOQd2WEtv67Tx/T5qG5ISL86VIbzAdM
+Shc00FutRgQ5IJIj5msySL3O5x3MGaMUhVocWP4oCShk/BlBOkcjHYzqpI8hm8hf
+Rrip2zbO8Met64/fkwMTMXX4E76hCMblYjTa/H4VlQ08oukwJyZagbhkivAjsETM
+5wXgW/x0QU1Rkfwv6GLoZqS1rumrX6S12x31qBXT/KKuI3QdSStkJU96/MeC8oD6
+AvjtahBLiKalX64VFmM4vX2TIb4OjkO1fySBPXj4GR1F9eg7S2wlSLryG/tGrx9B
+GH7qD6aMCk4xyb5o4YxNylmM9pDGByqveXflDIqJAhwEEAEKAAYFAlGFS0gACgkQ
+bwza5wC2iZ2GQBAAvmZDHFMExlr76mKjw1uiecJB7cGVfOx2Lg/NSoV09K2BKNcV
+4gJrVH2lLIlR19rSP1U+YoWJr+es2HDUZz+uzJNZ8ZcgBfLuaEO2JGA+0P3aPBuJ
+kBkDk3YDSx5Q5U9KFM0RBOebC901ZFyUpRAdeb/a3xfX20G7KyTmfZXegmqKsiwU
+WHNqrOObRnXR2sif3ruuARK2/8SZo6isdRjssxkaJMOOt7rN1j3DxI1x8eiewAUs
+UXleuZZj/3kLP0WeJkJIVZ5Blkptn3owrZWoidKK5I4x0ge6zDGNCn50zechtksU
++iV7Leu61P3s0ssoYlaJi2sJK5aZiInMafI5WJeevbNIeWNoCv5I4KNgw+XRPblU
+31O7BXFxImP3i6eBW4EbUHMycrIvN0itSrCsKpDX2XE6CEPSlhd7lXisXdaNLWP8
+DDvPv+ML7XlOBv0Ebho5PaQMhSjCQKsV1Edq+Po74/mxSRlqw/9qjymiB8a+6+qT
+cQxiGuyr1bD5rR5d2ns73H+QtOlvJ1v1bVNQbElgYTtYq5XL4+O1ZpTJYAmUB0z6
+wCIrmnpkOz82eqr+7eUIW1l2+t1Pi/LXlYOZ9SBIPxF85ZanBsUFyUC2R2woZdIf
+p5g+QtiNYzKZYH4EglztZ09uqWi2r6crMTZiq+c7EXOyQEOspwtaXCg+FiuJAh8E
+EAECAAkFAlGFSu8CBwAACgkQJSyQKKu6ikkdoRAAxfoQuL5cmJpN0Jwdo2ONIRpR
++YkU4BgDPyWAIEsAMBRdZ06ZSsTjRMAWJqfIvsItSfJsN26eJ87aUbKctxmEpZ/e
+hXs2X1wrnjwqIWqDxLDvipRKBFA3S7rItGpskRajnkrc+ZGpUYVVNUF7H/DkRafW
+Fx2WOfZo33Zyoj/a11xmC6TPAzeoaTHd43jbJFLTX1TRdnubd9NLH2RBOZmJwOIu
+3tDuookK4Z6cvDv7HlgS7y869z21m9WQfKD2jcuh8+t7UqLhQITvlBxaPgri9xFn
+8Gsyr+ro7mEhK7vxGi2ozFYFpDbZerqTHysx6Yw6G5wL8UZlIAXaIfOpbA142EUY
+ynQPQbKr6xmKe/5EAM0FKmfRGCx/p3So9FLaYDHBTwu83ie6AUlEY8OhpL5xadMO
+VK+JCC6Y8VSymjnK8zO+743ePw9HCBuArAnSRSOfeJvs3JO6th9v/x18d/oMAy9n
+BMYbF12WTNRhKYcD350RgxucC9kVj+tFSJg/1034JZvg6oX1V1gPu5GuwuFacng/
+zB7XG3Sb7bDKmLWZUVXCD8JLrLY9F4K/jBClBFiARQ1gTUraA/vxvJBaXHtH82Hz
+twzISWWZriBMroj7DIHlJcu9FGKWo4uwvDFhWYsQgGhu1TFBki8hYVox7PpXnh3+
+qoqElhs5kqgzgE8HzzO0J0pvc2ggRWxzZXIgKEFwYWNoZSkgPGVsc2VyakBhcGFj
+aGUub3JnPokCOAQTAQIAIgUCVwUjqQIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgEC
+F4AACgkQt9XNRUZ31mzyPg/8DfHIi7O3T1mqIbucnUvyvOgpzaadprmn0JjcXXTD
+AsQimCRJcbNjHAlN1U3eEt9bK96P53ZgrqqpO7a7p6FG6vxCh1ggX3fWkSKnNyfd
+kaAOyy8XDig6A6NaJ3Wrakd6yJ2q8RXOzPHhe7D56hB+UA5wwjdWM8XDR/mbb/Pt
+tX469LseSONIANRTjl2JWpPKrrjnOcRybC6lyVWFDxBpPXcglVpmiHu1RGvNOwCO
+JtEmC73keUR1PqzXROkk2/+aRFF38beu4DuJCjzCvUK81iCN+BEJMaE8rrfNgIDZ
+BiVUYubwpQZjxEwf1xti+cLH+e6SQ7Ybh0GJdg7K+CUhQq5IMIiTDWucTpfLza9F
+m+RR2gVhr5utNe/G7LACoI0C2yRxUWxCQ7dW3Zy2+RgQrbtJsOHkCWV4kSgz+k/0
+ISkT/jhMr4qARAcEgYwaTaTSXjXQNtoAaMCk6bWkvZe64SRNWagtjMdRQdc+PXc+
+YCbUD4CfBCx49mGKpnAu1VOgAdnBEGhdsoDCexj+i6tBAEBCMJ0anxbQ8Yjq05Be
+/ucuC946CSraggsLU51KLV4c69cA6EFEkNhYbX5sI1qMSJHKGxCt/bCQyZtCeoGm
+5PYRZJZZUyBWSP+VwuMe343CKiZkqhk3VonXZTzsJ+GP3RZE43TVqmSCcOb/LswV
+bSi5Ag0EUYVGVAEQAOhs+y

[VFS] 2.1 clirr report

[Josh Elser]

It looks like there are about 7 areas in core/ where compatibility 
against 2.0 has been broken:


* Methods added to o.a.c.v.{FileContent,FileName,FileObject}
* Method added to o.a.c.v.RandomAccessContent
* Parameters 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 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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VFS] 2.1 release help

[Josh Elser]

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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VFS] 2.1 Release Plan

[Josh Elser]

Because we should make a release of the code that's ready to go now :)

I think it's fine to drop 1.6 support, but if it's going to involve more 
code changes, I don't think it should happen for 2.1. If it's just a 
matter of tweaking the compiler-plugin, that's fine.


I hope to look at this all 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 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 <mailto:e...@zusammenkunft.net>> wrote:

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 am quite happy that you
want to
step in as I havent had the time to do the procedure yet.

And this is not the actual release procedure (which should be
doable as
long as you do not try to use the release-plugin and be careful
about
the multi-module+sandbox nature of VFS (as opposed to other commons
projects)). Also be carefull about branch and tag namings (the
SVN is a
bit messy in this regard).

My main concern I am afraid I would not have enough capacity is
because
of the Clirr report and a lot of partially incompatible changes.
Most
of them only affect providers if they do not properly use
abstract base
classes, but still the list of Clirr violations is long and
developers
here have not yet voiced if they would accept a RC with this
situation
(or not).

Anyway, I do agree that the current critical and blocker bugs are
important but should not stop the 2.1 release (especially if a 2.1.1
release aferwards is much faster to do.) It would be cool to have
VFS-570 (write suport for VFS, but even that could be delivered with
2.1.1 - it might annoy the HDFS folks a bit)

So I can help you in case you need me to sponsor some changes (I
hope I
have enough karma now).

We could even make a joined RC1, I am just not sure it wont open
a big
chunk of additional work.

Gruss
Bernd

  Am Tue, 26 Apr 2016 09:40:01 -0400
    schrieb Josh Elser <els...@apache.org <mailto:els...@apache.org>>:

 > Thanks Matt and Gary.
 >
 > I do recall seeing the asf-wide note that my commit-bit also
applies
 > to commons-*. Thanks for bringing that up. Specifically
though, I am
 > only interested in cutting a release -- if we can get a new
release
 > cut that we can use downstream, that increases the likelihood
that I
 > will have more things to contribute back :)
 >
 > I'll pull up the thread in the archives and get back to ya'll
with
 > any questions I have after that.
 >
 > - Josh
 >
 > Matt Sicker wrote:
 > > 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 <mailto: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 Commons
committer,
 > >> so feel free to create JIRAs, fix bugs and so on.
 > >>
 > >> There might be some karma issues with a non-PMC member
performing a
 > >> release, and I think we just went through this (sorry, I'm in
 > >> settling in a new house, not much time to dig in the ML
archives).
 > >>
 > >> Does anyone recall?
 > >>
 > >> Gary
 > >>
 > >>
 > >>
 > >> On Mon, Apr 25, 2016 at 12:06 PM, Josh
Elser<els...

Re: [VFS] 2.1 Release Plan

[Josh Elser]

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 pom to fix things that didn’t work correctly in 
commons-parent. I am sure over the course of time a lot of that has changed.  
But you will probably have some trial and error, which is why I would build 
first by manually activating the profiles and not starting with the release 
plugin as it is much easier to just blow away the target directory and start 
over than it is to revert stuff from scm.

Ralph


On Apr 27, 2016, at 8:31 AM, Josh Elser<josh.el...@gmail.com>  wrote:

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 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” by running a build with -P 
apache-release as that profile enables a bunch of stuff in the ASF parent pom.

Commons Parent has a -P release profile which is different.
I'm not sure CP works all that well with apache-release which does not
support everything we expect.

You can use -Ptest-deploy to change the deploy target to target/deploy
and compare the two.

You may need to use 'mvn package deploy' rather than plain 'mvn
deploy' if the VFS pom creates any jars in the package phase.


Ralph


On Apr 26, 2016, at 3:27 PM, Bernd Eckenfels<e...@zusammenkunft.net>   wrote:

Hello,

see inline.

Am Tue, 26 Apr 2016 18:05:01 -0400
schrieb Josh Elser<els...@apache.org<mailto: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
could potentially block the release of 2.1?

I did not waste much time in setting/unsetting the fixversion. I
modified some severities and closed some. But the blocker bugs (the
ones I considered) are all closed.

You could do a mass change on the existing bugs, but I am sure that
causes some discussion and especially people setting the fields back to
their preferences (at least that happend a few times in the past).


I'm not sure I follow you about the concern of using
maven-release-plugin with a multi-module maven project. This works
just fine (@see other Apache maven projects I'm involved in). If
there are demons laying in wait, I can knock them out as I find them.

Well yes, I use the release plugin aswell (in fact I did a company
internal release of VFS 2.1 with it already). I think it was also used
for the 2.0 release. But there are some things (especially the tagging
of the SVN and the tag in the POM) which is currently not very
preferable in apache commons I think. I would not use it for a release
(especially as rolling back and revovering would be painful). But I
agreee with you, it should work.


Are there instructions on running clirr? I'm not familiar with the
tool (and I don't see any configuration in the top-level pom.xml).

You can run the "mvn -Psandbox clean site" build (possibly follwoed by
a site tst deploy). The clirr report is part of it. I had a site build
from the snapshot on people.apache.org<http://people.apache.org/>, but I havent 
checked if/how the
new server would look like. So currently you need to run it locally.


Do you have the karma to make a 2.2 version on JIRA? That'd be a nice
help to start moving stuff out of 2.1 (as well as make sure things
sitting in Patch Available don't get forgotten).

Yes, seems like I can do it. I created 2.2.


I would lean towards
the side of only putting bug-fixes into a 2.1.1 and preferring
towards any new features/changes into a 2.2 (to closer follow the
definition of semver). We presently have 3 major and 1 minor version
unresolved for fixVersion=2.1 -- these where the issues I previously
referred to that I felt OK bumping out as well.
Gary -- "BC breakage" == base-class breakage? As in: the common
base-class for all of the VFS Providers has changed (and would
require changes from anyone downstream that has built their own)?

It refers to (binary) backward compatibility. For a client a new method
in an interface is a compatible change which fits into a minor update.
However when you have to implement a interface as a VFS provider you
wont be binary and source compatible. For most classes it is not a
problem since the mehtod is provided by the AbstractBaseClass for an
interface (but not all Interface

Re: [VFS] 2.1 Release Plan

[Josh Elser]

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 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” by running a build with -P 
apache-release as that profile enables a bunch of stuff in the ASF parent pom.


Commons Parent has a -P release profile which is different.
I'm not sure CP works all that well with apache-release which does not
support everything we expect.

You can use -Ptest-deploy to change the deploy target to target/deploy
and compare the two.

You may need to use 'mvn package deploy' rather than plain 'mvn
deploy' if the VFS pom creates any jars in the package phase.


Ralph


On Apr 26, 2016, at 3:27 PM, Bernd Eckenfels<e...@zusammenkunft.net>  wrote:

Hello,

see inline.

Am Tue, 26 Apr 2016 18:05:01 -0400
schrieb Josh Elser<els...@apache.org<mailto: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
could potentially block the release of 2.1?

I did not waste much time in setting/unsetting the fixversion. I
modified some severities and closed some. But the blocker bugs (the
ones I considered) are all closed.

You could do a mass change on the existing bugs, but I am sure that
causes some discussion and especially people setting the fields back to
their preferences (at least that happend a few times in the past).


I'm not sure I follow you about the concern of using
maven-release-plugin with a multi-module maven project. This works
just fine (@see other Apache maven projects I'm involved in). If
there are demons laying in wait, I can knock them out as I find them.

Well yes, I use the release plugin aswell (in fact I did a company
internal release of VFS 2.1 with it already). I think it was also used
for the 2.0 release. But there are some things (especially the tagging
of the SVN and the tag in the POM) which is currently not very
preferable in apache commons I think. I would not use it for a release
(especially as rolling back and revovering would be painful). But I
agreee with you, it should work.


Are there instructions on running clirr? I'm not familiar with the
tool (and I don't see any configuration in the top-level pom.xml).

You can run the "mvn -Psandbox clean site" build (possibly follwoed by
a site tst deploy). The clirr report is part of it. I had a site build
from the snapshot on people.apache.org<http://people.apache.org/>, but I havent 
checked if/how the
new server would look like. So currently you need to run it locally.


Do you have the karma to make a 2.2 version on JIRA? That'd be a nice
help to start moving stuff out of 2.1 (as well as make sure things
sitting in Patch Available don't get forgotten).

Yes, seems like I can do it. I created 2.2.


I would lean towards
the side of only putting bug-fixes into a 2.1.1 and preferring
towards any new features/changes into a 2.2 (to closer follow the
definition of semver). We presently have 3 major and 1 minor version
unresolved for fixVersion=2.1 -- these where the issues I previously
referred to that I felt OK bumping out as well.
Gary -- "BC breakage" == base-class breakage? As in: the common
base-class for all of the VFS Providers has changed (and would
require changes from anyone downstream that has built their own)?

It refers to (binary) backward compatibility. For a client a new method
in an interface is a compatible change which fits into a minor update.
However when you have to implement a interface as a VFS provider you
wont be binary and source compatible. For most classes it is not a
problem since the mehtod is provided by the AbstractBaseClass for an
interface (but not all Interfaces have that and it was never mandatory
for an provider to use them).


I can try to start pounding on an initial RC in the evenings this
week. I'll be sure to reach out as I need some more help/karma ;)

Anything more needed from me?

Gruss
Bernd



Gary Gregory wrote:

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
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 am q

Re: [VFS] 2.1 Release Plan

[Josh Elser]

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
could potentially block the release of 2.1?


I did not waste much time in setting/unsetting the fixversion. I
modified some severities and closed some. But the blocker bugs (the
ones I considered) are all closed.

You could do a mass change on the existing bugs, but I am sure that
causes some discussion and especially people setting the fields back to
their preferences (at least that happend a few times in the past).


I'll make sure to avoid the spam when closing all the issues currently 
fixVersion=2.1.



I'm not sure I follow you about the concern of using
maven-release-plugin with a multi-module maven project. This works
just fine (@see other Apache maven projects I'm involved in). If
there are demons laying in wait, I can knock them out as I find them.


Well yes, I use the release plugin aswell (in fact I did a company
internal release of VFS 2.1 with it already). I think it was also used
for the 2.0 release. But there are some things (especially the tagging
of the SVN and the tag in the POM) which is currently not very
preferable in apache commons I think. I would not use it for a release
(especially as rolling back and revovering would be painful). But I
agreee with you, it should work.


Are there instructions on running clirr? I'm not familiar with the
tool (and I don't see any configuration in the top-level pom.xml).


You can run the "mvn -Psandbox clean site" build (possibly follwoed by
a site tst deploy). The clirr report is part of it. I had a site build
from the snapshot on people.apache.org, but I havent checked if/how the
new server would look like. So currently you need to run it locally.


Thanks! Very helpful.


Do you have the karma to make a 2.2 version on JIRA? That'd be a nice
help to start moving stuff out of 2.1 (as well as make sure things
sitting in Patch Available don't get forgotten).


Yes, seems like I can do it. I created 2.2.


Thank you!


I would lean towards
the side of only putting bug-fixes into a 2.1.1 and preferring
towards any new features/changes into a 2.2 (to closer follow the
definition of semver). We presently have 3 major and 1 minor version
unresolved for fixVersion=2.1 -- these where the issues I previously
referred to that I felt OK bumping out as well.



Gary -- "BC breakage" == base-class breakage? As in: the common
base-class for all of the VFS Providers has changed (and would
require changes from anyone downstream that has built their own)?


It refers to (binary) backward compatibility. For a client a new method
in an interface is a compatible change which fits into a minor update.
However when you have to implement a interface as a VFS provider you
wont be binary and source compatible. For most classes it is not a
problem since the mehtod is provided by the AbstractBaseClass for an
interface (but not all Interfaces have that and it was never mandatory
for an provider to use them).


Ah ok. Thanks for the clarification on "BC".


I can try to start pounding on an initial RC in the evenings this
week. I'll be sure to reach out as I need some more help/karma ;)


Anything more needed from me?


Not at the moment. I will reach out if/when I get stuck

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

Re: [VFS] 2.1 Release Plan

[Josh Elser]

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-release-plugin with a multi-module maven project. This works just 
fine (@see other Apache maven projects I'm involved in). If there are 
demons laying in wait, I can knock them out as I find them.


Are there instructions on running clirr? I'm not familiar with the tool 
(and I don't see any configuration in the top-level pom.xml).


Do you have the karma to make a 2.2 version on JIRA? That'd be a nice 
help to start moving stuff out of 2.1 (as well as make sure things 
sitting in Patch Available don't get forgotten). I would lean towards 
the side of only putting bug-fixes into a 2.1.1 and preferring towards 
any new features/changes into a 2.2 (to closer follow the definition of 
semver). We presently have 3 major and 1 minor version unresolved for 
fixVersion=2.1 -- these where the issues I previously referred to that I 
felt OK bumping out as well.


Gary -- "BC breakage" == base-class breakage? As in: the common 
base-class for all of the VFS Providers has changed (and would require 
changes from anyone downstream that has built their own)?


I can try to start pounding on an initial RC in the evenings this week. 
I'll be sure to reach out as I need some more help/karma ;)


Gary Gregory wrote:

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
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 am quite happy that you want to
step in as I havent had the time to do the procedure yet.

And this is not the actual release procedure (which should be doable as
long as you do not try to use the release-plugin and be careful about
the multi-module+sandbox nature of VFS (as opposed to other commons
projects)). Also be carefull about branch and tag namings (the SVN is a
bit messy in this regard).

My main concern I am afraid I would not have enough capacity is because
of the Clirr report and a lot of partially incompatible changes. Most
of them only affect providers if they do not properly use abstract base
classes, but still the list of Clirr violations is long and developers
here have not yet voiced if they would accept a RC with this situation
(or not).

Anyway, I do agree that the current critical and blocker bugs are
important but should not stop the 2.1 release (especially if a 2.1.1
release aferwards is much faster to do.) It would be cool to have
VFS-570 (write suport for VFS, but even that could be delivered with
2.1.1 - it might annoy the HDFS folks a bit)

So I can help you in case you need me to sponsor some changes (I hope I
have enough karma now).

We could even make a joined RC1, I am just not sure it wont open a big
chunk of additional work.

Gruss
Bernd

  Am Tue, 26 Apr 2016 09:40:01 -0400
schrieb Josh Elser<els...@apache.org>:


Thanks Matt and Gary.

I do recall seeing the asf-wide note that my commit-bit also applies
to commons-*. Thanks for bringing that up. Specifically though, I am
only interested in cutting a release -- if we can get a new release
cut that we can use downstream, that increases the likelihood that I
will have more things to contribute back :)

I'll pull up the thread in the archives and get back to ya'll with
any questions I have after that.

- Josh

Matt Sicker wrote:

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 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 Commons committer,
so feel free to create JIRAs, fix bugs and so on.

There might be some karma issues with a non-PMC member performing a
release, and I think we just went through this (sorry, I'm in
settling in a new house, not much time to dig in the ML archives).

Does anyone recall?

Gary



On Mon, Apr 25, 2016 at 12:06 PM, Josh Elser<els...@apache.org>
wrote:


Hi all,

There are presently 171 resolved issues sitting in commons-vfs2
2.1-SNAPSHOT, with 4 outstanding (none of which look like
blockers to

me).

The lack of any release of commons-vfs2 in years has been a big
problem downstream. This past weekend, I was again annoyed by
bugs that have been fixed (but not release) which is

Re: [VFS] 2.1 Release Plan

[Josh Elser]

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 2.1.

Josh Elser wrote:

Thanks Matt and Gary.

I do recall seeing the asf-wide note that my commit-bit also applies to
commons-*. Thanks for bringing that up. Specifically though, I am only
interested in cutting a release -- if we can get a new release cut that
we can use downstream, that increases the likelihood that I will have
more things to contribute back :)

I'll pull up the thread in the archives and get back to ya'll with any
questions I have after that.

- Josh

Matt Sicker wrote:

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 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 Commons committer, so
feel
free to create JIRAs, fix bugs and so on.

There might be some karma issues with a non-PMC member performing a
release, and I think we just went through this (sorry, I'm in
settling in a
new house, not much time to dig in the ML archives).

Does anyone recall?

Gary



On Mon, Apr 25, 2016 at 12:06 PM, Josh Elser<els...@apache.org> wrote:


Hi all,

There are presently 171 resolved issues sitting in commons-vfs2
2.1-SNAPSHOT, with 4 outstanding (none of which look like blockers to

me).

The lack of any release of commons-vfs2 in years has been a big problem
downstream. This past weekend, I was again annoyed by bugs that have
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 has the cycles to volunteer as RM.
1a) If not, how can you empower me (or others) to make the release on
your behalf.
2) Understand, specifically, what (if any) roadblocks exist to release
this version.

Thanks.

- Josh


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




--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition<http://www.manning.com/tahchiev/>
Spring Batch in Action<http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory







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

Re: [VFS] 2.1 Release Plan

[Josh Elser]

Thanks Matt and Gary.

I do recall seeing the asf-wide note that my commit-bit also applies to 
commons-*. Thanks for bringing that up. Specifically though, I am only 
interested in cutting a release -- if we can get a new release cut that 
we can use downstream, that increases the likelihood that I will have 
more things to contribute back :)


I'll pull up the thread in the archives and get back to ya'll with any 
questions I have after that.


- Josh

Matt Sicker wrote:

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 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 Commons committer, so feel
free to create JIRAs, fix bugs and so on.

There might be some karma issues with a non-PMC member performing a
release, and I think we just went through this (sorry, I'm in settling in a
new house, not much time to dig in the ML archives).

Does anyone recall?

Gary



On Mon, Apr 25, 2016 at 12:06 PM, Josh Elser<els...@apache.org>  wrote:


Hi all,

There are presently 171 resolved issues sitting in commons-vfs2
2.1-SNAPSHOT, with 4 outstanding (none of which look like blockers to

me).

The lack of any release of commons-vfs2 in years has been a big problem
downstream. This past weekend, I was again annoyed by bugs that have 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 has the cycles to volunteer as RM.
   1a) If not, how can you empower me (or others) to make the release on
your behalf.
2) Understand, specifically, what (if any) roadblocks exist to release
this version.

Thanks.

- Josh


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




--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition<http://www.manning.com/tahchiev/>
Spring Batch in Action<http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory







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

[VFS] 2.1 Release Plan

[Josh Elser]

Hi all,

There are presently 171 resolved issues sitting in commons-vfs2 
2.1-SNAPSHOT, with 4 outstanding (none of which look like blockers to me).


The lack of any release of commons-vfs2 in years has been a big problem 
downstream. This past weekend, I was again annoyed by bugs that have 
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 has the cycles to volunteer as RM.
  1a) If not, how can you empower me (or others) to make the release on 
your behalf.
2) Understand, specifically, what (if any) roadblocks exist to release 
this version.


Thanks.

- Josh


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