subject:"Re\: \[VOTE\] Release Commons VFS 2.0"

On 18 August 2011 01:09, Ralph Goers  wrote:
>
> On Aug 17, 2011, at 3:27 PM, sebb wrote:
>
>> On 17 August 2011 23:17, ralph.goers @dslextreme.com
>>  wrote:
>>> I'd prefer to not remove it from the modules list as that will also remove
>>> it from the web site.
>>
>> But then surely source archive builds will fail?
>
> Yeah. I'll have to think about that. I hate it when you make me think.
>
> So somehow the site build should include the module and the rest of the time 
> it is not enabled.

Try using a profile to enable it, and ensure you enable the profile
when building the site, but not when building the artifacts.

> Ralph
> -
> 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] Release Commons VFS 2.0

2011-08-17 Thread Ralph Goers


On Aug 17, 2011, at 3:27 PM, sebb wrote:

> On 17 August 2011 23:17, ralph.goers @dslextreme.com
>  wrote:
>> I'd prefer to not remove it from the modules list as that will also remove
>> it from the web site.
> 
> But then surely source archive builds will fail?

Yeah. I'll have to think about that. I hate it when you make me think. 

So somehow the site build should include the module and the rest of the time it 
is not enabled.

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

Re: [Vote] Release Commons VFS 2.0

On 17 August 2011 23:17, ralph.goers @dslextreme.com
 wrote:
> I'd prefer to not remove it from the modules list as that will also remove
> it from the web site.

But then surely source archive builds will fail?

> Ralph
>
> On Wed, Aug 17, 2011 at 2:46 PM, sebb  wrote:
>
>> On 17 August 2011 20:43, ralph.goers @dslextreme.com
>>  wrote:
>> > The sandbox question I can't answer very well. The sandbox stuff was
>> there
>> > long before I arrived to work on VFS, although I rewrote the webdav stuff
>> > and moved it to core. The only real description is on the web site under
>> > "File Systems" where it says they under in development (not by me :-) ).
>> >
>> > None of the sandbox stuff appears to have been distributed with the 1.0
>> > release, including in the source distribution. I don't know of a  way I
>> can
>> > stop Maven from deploying it to the staging repo, but I can certainly
>> delete
>>
>> Can't you just remove it from the modules list?
>> That should stop Maven creating the jars at least.
>>
>> In fact, if we are not releasing sandbox it really ought to be
>> disabled in the POM (perhaps via a profile)
>>
>> > it from there just like I did the distribution zips. If desired, I'd have
>> to
>> > do another release to remove that source from the release.  It would also
>> > stay on the web site.
>> >
>> > Ralph
>> >
>> >
>> > On Wed, Aug 17, 2011 at 12:27 PM, Phil Steitz 
>> wrote:
>> >
>> >> On 8/17/11 11:32 AM, ralph.goers @dslextreme.com wrote:
>> >> > What do you mean "It did not work"?  This is a multi-project site so
>> in
>> >> > general mvn site is useless.  You have to run mvn site:stage-deply
>> >> > -DstagingSiteURL="file url where I want the site to go".  I suppose I
>> >> could
>> >> > add that to the readme, but it is documented pretty well on the maven
>> >> site
>> >> > plugin web site.
>> >> >
>> >> > In a prior release candidate I wasn't generating the release notes and
>> I
>> >> had
>> >> > the comment in the README.  The release was vetoed due to the lack of
>> >> > release notes. I simply forgot to delete the README.
>> >> >
>> >> > Did you run announcement-generate from the core directory? That only
>> >> works
>> >> > at the project root.
>> >> >
>> >> > The build instructions consist of:
>> >> >
>> >> > mvn clean install
>> >>
>> >> Those instructions appear on the "Download and Build" paged linked
>> >> in the main site menu, so I don't see this as a a blocker.
>> >> Instructions on how to build the site are nice to have, but not
>> >> showstoppers, IMO - especially since they generally stop working as
>> >> incompatible plugin and / or maven versions change.
>> >>
>> >> One question I have and I apologize if this has already been
>> >> discussed is are we sure we want to release the "sandbox" stuff?
>> >> There is no disclaimer of any kind on the web site or in the release
>> >> notes.  If the contents of that jar are being released as normal
>> >> artifacts, why is it called "sandbox"?  If not, why no explanation
>> >> anywhere of what "sandbox" means?
>> >>
>> >> Phil
>> >> >
>> >> > Ralph
>> >> >
>> >> > On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory > >> >wrote:
>> >> >
>> >> >> Hi All:
>> >> >>
>> >> >> I am not sure if I am building correctly, but here is what I found.
>> Some
>> >> >> build instructions in the readme.txt file would help.
>> >> >>
>> >> >> Downloaded source zip from
>> >> >> http://people.apache.org/~rgoers/commons-vfs/staged/
>> >> >>
>> >> >> From the root I ran "mvn site" which did not work. Fine, starting to
>> >> poke
>> >> >> around.
>> >> >>
>> >> >> From the "dist" directory I ran "mvn site" which did not work:
>> >> >>
>> >> >> [INFO] Generating "Dependency Management" report    ---
>> >> >> maven-project-info-reports-plugin:2.3.1
>> >> >> Downloading:
>> >> >>
>> >> >>
>> >>
>> http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom
>> >> >> [WARNING] Unable to create Maven project from repository.
>> >> >> org.apache.maven.project.ProjectBuildingException: Error resolving
>> >> project
>> >> >> artifact: Failure to find
>> >> org.apache.commons:commons-vfs-examples:pom:2.0
>> >> >> in
>> >> >> http://r
>> >> >> epo1.maven.org/maven2 was cached in the local repository, resolution
>> >> will
>> >> >> not be reattempted until the update interval of central has elapsed
>> or
>> >> >> updates are for
>> >> >> ced for project org.apache.commons:commons-vfs-examples:pom:2.0
>> >> >>        at
>> >> >>
>> >> >>
>> >>
>> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272)
>> >> >>        at
>> >> >>
>> >> >>
>> >>
>> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
>> >> >>        at
>> >> >>
>> >> >>
>> >>
>> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)
>> >> >>
>> >> >> Why would building the site require an installed VFS2?
>> >> >>
>> >> >> Th

Re: [Vote] Release Commons VFS 2.0

I'd prefer to not remove it from the modules list as that will also remove
it from the web site.

Ralph

On Wed, Aug 17, 2011 at 2:46 PM, sebb  wrote:

> On 17 August 2011 20:43, ralph.goers @dslextreme.com
>  wrote:
> > The sandbox question I can't answer very well. The sandbox stuff was
> there
> > long before I arrived to work on VFS, although I rewrote the webdav stuff
> > and moved it to core. The only real description is on the web site under
> > "File Systems" where it says they under in development (not by me :-) ).
> >
> > None of the sandbox stuff appears to have been distributed with the 1.0
> > release, including in the source distribution. I don't know of a  way I
> can
> > stop Maven from deploying it to the staging repo, but I can certainly
> delete
>
> Can't you just remove it from the modules list?
> That should stop Maven creating the jars at least.
>
> In fact, if we are not releasing sandbox it really ought to be
> disabled in the POM (perhaps via a profile)
>
> > it from there just like I did the distribution zips. If desired, I'd have
> to
> > do another release to remove that source from the release.  It would also
> > stay on the web site.
> >
> > Ralph
> >
> >
> > On Wed, Aug 17, 2011 at 12:27 PM, Phil Steitz 
> wrote:
> >
> >> On 8/17/11 11:32 AM, ralph.goers @dslextreme.com wrote:
> >> > What do you mean "It did not work"?  This is a multi-project site so
> in
> >> > general mvn site is useless.  You have to run mvn site:stage-deply
> >> > -DstagingSiteURL="file url where I want the site to go".  I suppose I
> >> could
> >> > add that to the readme, but it is documented pretty well on the maven
> >> site
> >> > plugin web site.
> >> >
> >> > In a prior release candidate I wasn't generating the release notes and
> I
> >> had
> >> > the comment in the README.  The release was vetoed due to the lack of
> >> > release notes. I simply forgot to delete the README.
> >> >
> >> > Did you run announcement-generate from the core directory? That only
> >> works
> >> > at the project root.
> >> >
> >> > The build instructions consist of:
> >> >
> >> > mvn clean install
> >>
> >> Those instructions appear on the "Download and Build" paged linked
> >> in the main site menu, so I don't see this as a a blocker.
> >> Instructions on how to build the site are nice to have, but not
> >> showstoppers, IMO - especially since they generally stop working as
> >> incompatible plugin and / or maven versions change.
> >>
> >> One question I have and I apologize if this has already been
> >> discussed is are we sure we want to release the "sandbox" stuff?
> >> There is no disclaimer of any kind on the web site or in the release
> >> notes.  If the contents of that jar are being released as normal
> >> artifacts, why is it called "sandbox"?  If not, why no explanation
> >> anywhere of what "sandbox" means?
> >>
> >> Phil
> >> >
> >> > Ralph
> >> >
> >> > On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory  >> >wrote:
> >> >
> >> >> Hi All:
> >> >>
> >> >> I am not sure if I am building correctly, but here is what I found.
> Some
> >> >> build instructions in the readme.txt file would help.
> >> >>
> >> >> Downloaded source zip from
> >> >> http://people.apache.org/~rgoers/commons-vfs/staged/
> >> >>
> >> >> From the root I ran "mvn site" which did not work. Fine, starting to
> >> poke
> >> >> around.
> >> >>
> >> >> From the "dist" directory I ran "mvn site" which did not work:
> >> >>
> >> >> [INFO] Generating "Dependency Management" report---
> >> >> maven-project-info-reports-plugin:2.3.1
> >> >> Downloading:
> >> >>
> >> >>
> >>
> http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom
> >> >> [WARNING] Unable to create Maven project from repository.
> >> >> org.apache.maven.project.ProjectBuildingException: Error resolving
> >> project
> >> >> artifact: Failure to find
> >> org.apache.commons:commons-vfs-examples:pom:2.0
> >> >> in
> >> >> http://r
> >> >> epo1.maven.org/maven2 was cached in the local repository, resolution
> >> will
> >> >> not be reattempted until the update interval of central has elapsed
> or
> >> >> updates are for
> >> >> ced for project org.apache.commons:commons-vfs-examples:pom:2.0
> >> >>at
> >> >>
> >> >>
> >>
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272)
> >> >>at
> >> >>
> >> >>
> >>
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
> >> >>at
> >> >>
> >> >>
> >>
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)
> >> >>
> >> >> Why would building the site require an installed VFS2?
> >> >>
> >> >> The README.txt says to run "mvn changes:announcement-generate" to get
> >> >> release notes but there is a RELEASE-NOTES.txt file in the same dir.
> Why
> >> do
> >> >> we need two?
> >> >>
> >> >> When I do run "mvn changes:announcement-generate", I g

Re: [Vote] Release Commons VFS 2.0

I didn't check, but for some reason I assumed that once I do a "close" that
I wouldn't be able to delete anything. But you are correct. I can do that so
I will as it is easier.

Ralph

On Wed, Aug 17, 2011 at 2:51 PM, sebb  wrote:

> On 17 August 2011 20:55, ralph.goers @dslextreme.com
>  wrote:
> > Nope. That is my mistake.  Maven generated them when it uploaded them to
> the
> > Nexus staging repo. But I deleted that since we don't deliver them from
> > there. I then uploaded the artifacts from where they were built on my
> > machine to the directory on people.a.o rather than grabbing them from
> Nexus,
> > which is what I should have done.  I'll have to correct that.
>
> Rather than copying them before the vote, you could leave the zip/tgz
> archives in the Nexus staging area until the vote is complete.
>
> Then, just before publishing the staging repo, copy the non-Maven
> files to the dist/ directory and delete from staging.
>
> Then release the staging area.
>
> Saves at least one set of copying.
>
> > Ralph
> >
> > On Wed, Aug 17, 2011 at 12:45 PM, Oliver Heger <
> oliver.he...@oliver-heger.de
> >> wrote:
> >
> >> Build is now successful under Windows 7 with Java 1.5 and 1.6. Artifacts
> >> and site look good.
> >>
> >> The only thing I am missing are md5 files. Are they required (other
> >> components used to have them)? If not, you can count my +1.
> >>
> >> Oliver
> >>
> >> Am 17.08.2011 07:44, schrieb Ralph Goers:
> >>
> >>  This is a vote to release Apache Commons VFS 2.0.
> >>>
> >>> Changes made since the last candidate:
> >>>
> >>> * Fixed the manifest error that was causing the build to fail.
> >>> * Changed the copyright date in the Notice file from 2010 to 2011.
> >>> * Removed the references to javamail from the Notice file.
> >>> * Removed all the @version tags
> >>> * Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and
> >>> src/changes/announcement.vm (osgi/MANIFEST.MF has been removed).
> >>> * Modified the release notes to mention the code is not source
> compatible
> >>> with VFS 1.x and that the package name changed.
> >>> * Fixed the WARNING for the use of the deprecated tasks element.
> >>> * Fixed the WARNING for the use of the deprecated systemProperties
> >>> element.
> >>> * Made sure all jars have NOTICE.txt and LICENSE.txt
> >>>
> >>> The build message
> >>> [WARNING] Ignoring project type pom - supportedProjectTypes = [jar,
> >>> bundle]
> >>> was not fixed as that is due to commons parent causing the maven-bundle
> >>> plugin to run on all subprojects, including those that don't generate
> >>> bundles or jars.
> >>>
> >>> I have also removed files that shouldn't be present in the Maven
> >>> repository from the staging repo.
> >>>
> >>> [ ] +1 release it
> >>> [ ] +0 go ahead I don't care
> >>> [ ] -1 no, do not release it because.
> >>>
> >>> Ralph
> >>>
> >>>
> >>> Tag: https://svn.apache.org/repos/**asf/commons/proper/vfs/tags/**
> >>> commons-vfs2-project-2.0/<
> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/>
> (revision 1158401).
> >>>
> >>> Site: http://people.apache.org/~**rgoers/commons-vfs/site/<
> http://people.apache.org/~rgoers/commons-vfs/site/>
> >>>
> >>> Binaries: http://people.apache.org/~**rgoers/commons-vfs/staged/<
> http://people.apache.org/~rgoers/commons-vfs/staged/>
> >>>
> >>> The following artifacts have been staged to the org.apache.commons-045
> >>> (u:rgoers, a:208.29.163.248) repository.
> >>>
> >>> The Maven artifacts are at:
> >>>
> >>> https://repository.apache.org/**content/groups/staging/org/**
> >>> apache/commons/commons-vfs2/<
> https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2/
> >
> >>> https://repository.apache.org/**content/groups/staging/org/**
> >>> apache/commons/commons-vfs2-**examples/<
> https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-examples/
> >
> >>> https://repository.apache.org/**content/groups/staging/org/**
> >>> apache/commons/commons-vfs2-**project/<
> https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-project/
> >
> >>> https://repository.apache.org/**content/groups/staging/org/**
> >>> apache/commons/commons-vfs2-**sandbox/<
> https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-sandbox/
> >
> >>>
> >>> and consist of
> >>>
> >>> archetype-catalog.xml
> >>> commons-vfs2-examples-2.0-**javadoc.jar
> >>> commons-vfs2-examples-2.0-**sources.jar.asc
> >>> commons-vfs2-examples-2.0.pom
> >>> commons-vfs2-examples-2.0-**tests.jar
> >>> commons-vfs2-examples-2.0-**tests.jar.asc
> >>> commons-vfs2-examples-2.0.jar.**asc
> >>> commons-vfs2-examples-2.0.pom.**asc
> >>> commons-vfs2-examples-2.0-**javadoc.jar.asc
> >>> commons-vfs2-examples-2.0.jar
> >>> commons-vfs2-examples-2.0-**sources.jar
> >>> commons-vfs2-project-2.0.pom.**asc
> >>> commons-vfs2-project-2.0.pom
> >>> commons-vfs2-sandbox-2.0.pom.**asc
> >>> commons-vfs2-sandbox-2.0-**s

Re: [Vote] Release Commons VFS 2.0

On 17 August 2011 20:55, ralph.goers @dslextreme.com
 wrote:
> Nope. That is my mistake.  Maven generated them when it uploaded them to the
> Nexus staging repo. But I deleted that since we don't deliver them from
> there. I then uploaded the artifacts from where they were built on my
> machine to the directory on people.a.o rather than grabbing them from Nexus,
> which is what I should have done.  I'll have to correct that.

Rather than copying them before the vote, you could leave the zip/tgz
archives in the Nexus staging area until the vote is complete.

Then, just before publishing the staging repo, copy the non-Maven
files to the dist/ directory and delete from staging.

Then release the staging area.

Saves at least one set of copying.

> Ralph
>
> On Wed, Aug 17, 2011 at 12:45 PM, Oliver Heger > wrote:
>
>> Build is now successful under Windows 7 with Java 1.5 and 1.6. Artifacts
>> and site look good.
>>
>> The only thing I am missing are md5 files. Are they required (other
>> components used to have them)? If not, you can count my +1.
>>
>> Oliver
>>
>> Am 17.08.2011 07:44, schrieb Ralph Goers:
>>
>>  This is a vote to release Apache Commons VFS 2.0.
>>>
>>> Changes made since the last candidate:
>>>
>>> * Fixed the manifest error that was causing the build to fail.
>>> * Changed the copyright date in the Notice file from 2010 to 2011.
>>> * Removed the references to javamail from the Notice file.
>>> * Removed all the @version tags
>>> * Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and
>>> src/changes/announcement.vm (osgi/MANIFEST.MF has been removed).
>>> * Modified the release notes to mention the code is not source compatible
>>> with VFS 1.x and that the package name changed.
>>> * Fixed the WARNING for the use of the deprecated tasks element.
>>> * Fixed the WARNING for the use of the deprecated systemProperties
>>> element.
>>> * Made sure all jars have NOTICE.txt and LICENSE.txt
>>>
>>> The build message
>>> [WARNING] Ignoring project type pom - supportedProjectTypes = [jar,
>>> bundle]
>>> was not fixed as that is due to commons parent causing the maven-bundle
>>> plugin to run on all subprojects, including those that don't generate
>>> bundles or jars.
>>>
>>> I have also removed files that shouldn't be present in the Maven
>>> repository from the staging repo.
>>>
>>> [ ] +1 release it
>>> [ ] +0 go ahead I don't care
>>> [ ] -1 no, do not release it because.
>>>
>>> Ralph
>>>
>>>
>>> Tag: https://svn.apache.org/repos/**asf/commons/proper/vfs/tags/**
>>> commons-vfs2-project-2.0/
>>>  (revision 1158401).
>>>
>>> Site: 
>>> http://people.apache.org/~**rgoers/commons-vfs/site/
>>>
>>> Binaries: 
>>> http://people.apache.org/~**rgoers/commons-vfs/staged/
>>>
>>> The following artifacts have been staged to the org.apache.commons-045
>>> (u:rgoers, a:208.29.163.248) repository.
>>>
>>> The Maven artifacts are at:
>>>
>>> https://repository.apache.org/**content/groups/staging/org/**
>>> apache/commons/commons-vfs2/
>>> https://repository.apache.org/**content/groups/staging/org/**
>>> apache/commons/commons-vfs2-**examples/
>>> https://repository.apache.org/**content/groups/staging/org/**
>>> apache/commons/commons-vfs2-**project/
>>> https://repository.apache.org/**content/groups/staging/org/**
>>> apache/commons/commons-vfs2-**sandbox/
>>>
>>> and consist of
>>>
>>> archetype-catalog.xml
>>> commons-vfs2-examples-2.0-**javadoc.jar
>>> commons-vfs2-examples-2.0-**sources.jar.asc
>>> commons-vfs2-examples-2.0.pom
>>> commons-vfs2-examples-2.0-**tests.jar
>>> commons-vfs2-examples-2.0-**tests.jar.asc
>>> commons-vfs2-examples-2.0.jar.**asc
>>> commons-vfs2-examples-2.0.pom.**asc
>>> commons-vfs2-examples-2.0-**javadoc.jar.asc
>>> commons-vfs2-examples-2.0.jar
>>> commons-vfs2-examples-2.0-**sources.jar
>>> commons-vfs2-project-2.0.pom.**asc
>>> commons-vfs2-project-2.0.pom
>>> commons-vfs2-sandbox-2.0.pom.**asc
>>> commons-vfs2-sandbox-2.0-**sources.jar.asc
>>> commons-vfs2-sandbox-2.0-test-**sources.jar.asc
>>> commons-vfs2-sandbox-2.0.jar
>>> commons-vfs2-sandbox-2.0-**javadoc.jar
>>> commons-vfs2-sandbox-2.0-test-**sources.jar
>>> commons-vfs2-sandbox-2.0.jar.**asc
>>> commons-vfs2-sandbox-2.0-**sources.jar
>>> commons-vfs2-sandbox-2.0-**javadoc.jar.asc
>>> commons-vfs2-sandbox-2.0-**tests.jar.asc
>>> commons-vfs2-sandbox-2.0-**tests.jar
>>> commons-vfs2-sandbox-2.0.pom
>>> commons-vfs2-2.0.pom.asc
>>> commons-vfs2-2.0-javadoc.

Re: [Vote] Release Commons VFS 2.0

On 17 August 2011 20:43, ralph.goers @dslextreme.com
 wrote:
> The sandbox question I can't answer very well. The sandbox stuff was there
> long before I arrived to work on VFS, although I rewrote the webdav stuff
> and moved it to core. The only real description is on the web site under
> "File Systems" where it says they under in development (not by me :-) ).
>
> None of the sandbox stuff appears to have been distributed with the 1.0
> release, including in the source distribution. I don't know of a  way I can
> stop Maven from deploying it to the staging repo, but I can certainly delete

Can't you just remove it from the modules list?
That should stop Maven creating the jars at least.

In fact, if we are not releasing sandbox it really ought to be
disabled in the POM (perhaps via a profile)

> it from there just like I did the distribution zips. If desired, I'd have to
> do another release to remove that source from the release.  It would also
> stay on the web site.
>
> Ralph
>
>
> On Wed, Aug 17, 2011 at 12:27 PM, Phil Steitz  wrote:
>
>> On 8/17/11 11:32 AM, ralph.goers @dslextreme.com wrote:
>> > What do you mean "It did not work"?  This is a multi-project site so in
>> > general mvn site is useless.  You have to run mvn site:stage-deply
>> > -DstagingSiteURL="file url where I want the site to go".  I suppose I
>> could
>> > add that to the readme, but it is documented pretty well on the maven
>> site
>> > plugin web site.
>> >
>> > In a prior release candidate I wasn't generating the release notes and I
>> had
>> > the comment in the README.  The release was vetoed due to the lack of
>> > release notes. I simply forgot to delete the README.
>> >
>> > Did you run announcement-generate from the core directory? That only
>> works
>> > at the project root.
>> >
>> > The build instructions consist of:
>> >
>> > mvn clean install
>>
>> Those instructions appear on the "Download and Build" paged linked
>> in the main site menu, so I don't see this as a a blocker.
>> Instructions on how to build the site are nice to have, but not
>> showstoppers, IMO - especially since they generally stop working as
>> incompatible plugin and / or maven versions change.
>>
>> One question I have and I apologize if this has already been
>> discussed is are we sure we want to release the "sandbox" stuff?
>> There is no disclaimer of any kind on the web site or in the release
>> notes.  If the contents of that jar are being released as normal
>> artifacts, why is it called "sandbox"?  If not, why no explanation
>> anywhere of what "sandbox" means?
>>
>> Phil
>> >
>> > Ralph
>> >
>> > On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory > >wrote:
>> >
>> >> Hi All:
>> >>
>> >> I am not sure if I am building correctly, but here is what I found. Some
>> >> build instructions in the readme.txt file would help.
>> >>
>> >> Downloaded source zip from
>> >> http://people.apache.org/~rgoers/commons-vfs/staged/
>> >>
>> >> From the root I ran "mvn site" which did not work. Fine, starting to
>> poke
>> >> around.
>> >>
>> >> From the "dist" directory I ran "mvn site" which did not work:
>> >>
>> >> [INFO] Generating "Dependency Management" report    ---
>> >> maven-project-info-reports-plugin:2.3.1
>> >> Downloading:
>> >>
>> >>
>> http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom
>> >> [WARNING] Unable to create Maven project from repository.
>> >> org.apache.maven.project.ProjectBuildingException: Error resolving
>> project
>> >> artifact: Failure to find
>> org.apache.commons:commons-vfs-examples:pom:2.0
>> >> in
>> >> http://r
>> >> epo1.maven.org/maven2 was cached in the local repository, resolution
>> will
>> >> not be reattempted until the update interval of central has elapsed or
>> >> updates are for
>> >> ced for project org.apache.commons:commons-vfs-examples:pom:2.0
>> >>        at
>> >>
>> >>
>> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272)
>> >>        at
>> >>
>> >>
>> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
>> >>        at
>> >>
>> >>
>> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)
>> >>
>> >> Why would building the site require an installed VFS2?
>> >>
>> >> The README.txt says to run "mvn changes:announcement-generate" to get
>> >> release notes but there is a RELEASE-NOTES.txt file in the same dir. Why
>> do
>> >> we need two?
>> >>
>> >> When I do run "mvn changes:announcement-generate", I get:
>> >>
>> >> [INFO] --- maven-changes-plugin:2.4:announcement-generate (default-cli)
>> @
>> >> commons-vfs2 ---
>> >> [WARNING] changes.xml file
>> >> C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist.
>> >>
>> >> There is no such file.
>> >>
>> >> I do not know if I should -1 this because there are no build
>> instructions,
>> >> or if there are, they are located in some non-obvious spot.
>> >

Re: [Vote] Release Commons VFS 2.0

Sorry, yes.

Ralph

On Wed, Aug 17, 2011 at 1:33 PM, Luc Maisonobe wrote:

> Le 17/08/2011 22:13, ralph.goers @dslextreme.com a écrit :
>
>  OK. I will take care of this, the MD5 issue and do something with the
>> README
>> in a few hours after I get home from work and send out another release
>> vote.
>>
>
> Was this vote offocially cancelled ?
>
> Luc
>
>
>  In the meantime, if there are any other problems that should be corrected
>> I'd appreciate the feedback.
>>
>> Ralph
>>
>> On Wed, Aug 17, 2011 at 1:05 PM, Phil Steitz
>>  wrote:
>>
>>  On 8/17/11 12:43 PM, ralph.goers @dslextreme.com wrote:
>>>
 The sandbox question I can't answer very well. The sandbox stuff was

>>> there
>>>
 long before I arrived to work on VFS, although I rewrote the webdav
 stuff
 and moved it to core. The only real description is on the web site under
 "File Systems" where it says they under in development (not by me :-) ).

 None of the sandbox stuff appears to have been distributed with the 1.0
 release, including in the source distribution. I don't know of a  way I

>>> can
>>>
 stop Maven from deploying it to the staging repo, but I can certainly

>>> delete
>>>
 it from there just like I did the distribution zips. If desired, I'd
 have

>>> to
>>>
 do another release to remove that source from the release.  It would
 also
 stay on the web site.

>>>
>>> Staying on the web site is fine.  Releasing code and jars that we do
>>> not intend to support is not, so I am -1 on this release.   We used
>>> to have an /experimental tree in [math] that we omitted from source
>>> and binary releases.  In the source assembly descriptor, this kind
>>> of thing at least used to work:
>>>
>>> 
>>>  src
>>>  
>>>**/mantissa/**
>>>**/experimental/**
>>>  
>>> 
>>>
>>> Phil
>>>

 Ralph


 On Wed, Aug 17, 2011 at 12:27 PM, Phil Steitz

>>> wrote:
>>>

  On 8/17/11 11:32 AM, ralph.goers @dslextreme.com wrote:
>
>> What do you mean "It did not work"?  This is a multi-project site so
>> in
>> general mvn site is useless.  You have to run mvn site:stage-deply
>> -DstagingSiteURL="file url where I want the site to go".  I suppose I
>>
> could
>
>> add that to the readme, but it is documented pretty well on the maven
>>
> site
>
>> plugin web site.
>>
>> In a prior release candidate I wasn't generating the release notes and
>>
> I
>>>
 had
>
>> the comment in the README.  The release was vetoed due to the lack of
>> release notes. I simply forgot to delete the README.
>>
>> Did you run announcement-generate from the core directory? That only
>>
> works
>
>> at the project root.
>>
>> The build instructions consist of:
>>
>> mvn clean install
>>
> Those instructions appear on the "Download and Build" paged linked
> in the main site menu, so I don't see this as a a blocker.
> Instructions on how to build the site are nice to have, but not
> showstoppers, IMO - especially since they generally stop working as
> incompatible plugin and / or maven versions change.
>
> One question I have and I apologize if this has already been
> discussed is are we sure we want to release the "sandbox" stuff?
> There is no disclaimer of any kind on the web site or in the release
> notes.  If the contents of that jar are being released as normal
> artifacts, why is it called "sandbox"?  If not, why no explanation
> anywhere of what "sandbox" means?
>
> Phil
>
>> Ralph
>>
>> On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory> wrote:
>>
>>  Hi All:
>>>
>>> I am not sure if I am building correctly, but here is what I found.
>>>
>> Some
>>>
 build instructions in the readme.txt file would help.
>>>
>>> Downloaded source zip from
>>> http://people.apache.org/~**rgoers/commons-vfs/staged/
>>>
>>>  From the root I ran "mvn site" which did not work. Fine, starting to
>>>
>> poke
>
>> around.
>>>
>>>  From the "dist" directory I ran "mvn site" which did not work:
>>>
>>> [INFO] Generating "Dependency Management" report---
>>> maven-project-info-reports-**plugin:2.3.1
>>> Downloading:
>>>
>>>
>>>
>  http://repo1.maven.org/maven2/**org/apache/commons/commons-**
>>> vfs-examples/2.0/commons-vfs-**examples-2.0.pom
>>>
 [WARNING] Unable to create Maven project from repository.
>>> org.apache.maven.project.**ProjectBuildingException: Error resolving
>>>
>> project
>
>> artifact: Failure to find
>>>
>> org.apache.commons:commons-**vfs-examples:pom:2.0
>
>>

Re: [Vote] Release Commons VFS 2.0

2011-08-17 Thread Luc Maisonobe

Le 17/08/2011 22:13, ralph.goers @dslextreme.com a écrit :

OK. I will take care of this, the MD5 issue and do something with the README
in a few hours after I get home from work and send out another release vote.

Was this vote offocially cancelled ?

Luc

In the meantime, if there are any other problems that should be corrected
I'd appreciate the feedback.

Ralph

On Wed, Aug 17, 2011 at 1:05 PM, Phil Steitz wrote:

On 8/17/11 12:43 PM, ralph.goers @dslextreme.com wrote:

The sandbox question I can't answer very well. The sandbox stuff was

there

long before I arrived to work on VFS, although I rewrote the webdav stuff
and moved it to core. The only real description is on the web site under
"File Systems" where it says they under in development (not by me :-) ).

None of the sandbox stuff appears to have been distributed with the 1.0
release, including in the source distribution. I don't know of a way I

can

stop Maven from deploying it to the staging repo, but I can certainly

delete

it from there just like I did the distribution zips. If desired, I'd have

do another release to remove that source from the release. It would also
stay on the web site.

Staying on the web site is fine. Releasing code and jars that we do
not intend to support is not, so I am -1 on this release. We used
to have an /experimental tree in [math] that we omitted from source
and binary releases. In the source assembly descriptor, this kind
of thing at least used to work:

src

**/mantissa/**
**/experimental/**

Phil

Ralph

On Wed, Aug 17, 2011 at 12:27 PM, Phil Steitz

wrote:

On 8/17/11 11:32 AM, ralph.goers @dslextreme.com wrote:

What do you mean "It did not work"? This is a multi-project site so in
general mvn site is useless. You have to run mvn site:stage-deply
-DstagingSiteURL="file url where I want the site to go". I suppose I

could

add that to the readme, but it is documented pretty well on the maven

site

plugin web site.

In a prior release candidate I wasn't generating the release notes and

had

the comment in the README. The release was vetoed due to the lack of
release notes. I simply forgot to delete the README.

Did you run announcement-generate from the core directory? That only

works

at the project root.

The build instructions consist of:

mvn clean install

Those instructions appear on the "Download and Build" paged linked
in the main site menu, so I don't see this as a a blocker.
Instructions on how to build the site are nice to have, but not
showstoppers, IMO - especially since they generally stop working as
incompatible plugin and / or maven versions change.

One question I have and I apologize if this has already been
discussed is are we sure we want to release the "sandbox" stuff?
There is no disclaimer of any kind on the web site or in the release
notes. If the contents of that jar are being released as normal
artifacts, why is it called "sandbox"? If not, why no explanation
anywhere of what "sandbox" means?

Phil

Ralph

On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory
Hi All:

I am not sure if I am building correctly, but here is what I found.

Some

build instructions in the readme.txt file would help.

Downloaded source zip from
http://people.apache.org/~rgoers/commons-vfs/staged/

From the root I ran "mvn site" which did not work. Fine, starting to

poke

around.

From the "dist" directory I ran "mvn site" which did not work:

[INFO] Generating "Dependency Management" report---
maven-project-info-reports-plugin:2.3.1
Downloading:

http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom

[WARNING] Unable to create Maven project from repository.
org.apache.maven.project.ProjectBuildingException: Error resolving

project

artifact: Failure to find

org.apache.commons:commons-vfs-examples:pom:2.0

in
http://r
epo1.maven.org/maven2 was cached in the local repository, resolution

will

not be reattempted until the update interval of central has elapsed or
updates are for
ced for project org.apache.commons:commons-vfs-examples:pom:2.0
at

org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272)

org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)

org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)

Why would building the site require an installed VFS2?

The README.txt says to run "mvn changes:announcement-generate" to get
release notes but there is a RELEASE-NOTES.txt file in the same dir.

Why

we need two?

When I do run "mvn changes:announcement-generate", I get:

[INFO] --- maven-changes-plugin:2.4:announcement-generate

(default-cli)

commons-vfs2 ---
[WARNING] changes.xml file
C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist.

There is no such file.

I do not kno

Re: [Vote] Release Commons VFS 2.0

OK. I will take care of this, the MD5 issue and do something with the README
in a few hours after I get home from work and send out another release vote.
In the meantime, if there are any other problems that should be corrected
I'd appreciate the feedback.

Ralph

On Wed, Aug 17, 2011 at 1:05 PM, Phil Steitz  wrote:

> On 8/17/11 12:43 PM, ralph.goers @dslextreme.com wrote:
> > The sandbox question I can't answer very well. The sandbox stuff was
> there
> > long before I arrived to work on VFS, although I rewrote the webdav stuff
> > and moved it to core. The only real description is on the web site under
> > "File Systems" where it says they under in development (not by me :-) ).
> >
> > None of the sandbox stuff appears to have been distributed with the 1.0
> > release, including in the source distribution. I don't know of a  way I
> can
> > stop Maven from deploying it to the staging repo, but I can certainly
> delete
> > it from there just like I did the distribution zips. If desired, I'd have
> to
> > do another release to remove that source from the release.  It would also
> > stay on the web site.
>
> Staying on the web site is fine.  Releasing code and jars that we do
> not intend to support is not, so I am -1 on this release.   We used
> to have an /experimental tree in [math] that we omitted from source
> and binary releases.  In the source assembly descriptor, this kind
> of thing at least used to work:
>
> 
>  src
>  
>**/mantissa/**
>**/experimental/**
>  
> 
>
> Phil
> >
> > Ralph
> >
> >
> > On Wed, Aug 17, 2011 at 12:27 PM, Phil Steitz 
> wrote:
> >
> >> On 8/17/11 11:32 AM, ralph.goers @dslextreme.com wrote:
> >>> What do you mean "It did not work"?  This is a multi-project site so in
> >>> general mvn site is useless.  You have to run mvn site:stage-deply
> >>> -DstagingSiteURL="file url where I want the site to go".  I suppose I
> >> could
> >>> add that to the readme, but it is documented pretty well on the maven
> >> site
> >>> plugin web site.
> >>>
> >>> In a prior release candidate I wasn't generating the release notes and
> I
> >> had
> >>> the comment in the README.  The release was vetoed due to the lack of
> >>> release notes. I simply forgot to delete the README.
> >>>
> >>> Did you run announcement-generate from the core directory? That only
> >> works
> >>> at the project root.
> >>>
> >>> The build instructions consist of:
> >>>
> >>> mvn clean install
> >> Those instructions appear on the "Download and Build" paged linked
> >> in the main site menu, so I don't see this as a a blocker.
> >> Instructions on how to build the site are nice to have, but not
> >> showstoppers, IMO - especially since they generally stop working as
> >> incompatible plugin and / or maven versions change.
> >>
> >> One question I have and I apologize if this has already been
> >> discussed is are we sure we want to release the "sandbox" stuff?
> >> There is no disclaimer of any kind on the web site or in the release
> >> notes.  If the contents of that jar are being released as normal
> >> artifacts, why is it called "sandbox"?  If not, why no explanation
> >> anywhere of what "sandbox" means?
> >>
> >> Phil
> >>> Ralph
> >>>
> >>> On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory  >>> wrote:
> >>>
>  Hi All:
> 
>  I am not sure if I am building correctly, but here is what I found.
> Some
>  build instructions in the readme.txt file would help.
> 
>  Downloaded source zip from
>  http://people.apache.org/~rgoers/commons-vfs/staged/
> 
>  From the root I ran "mvn site" which did not work. Fine, starting to
> >> poke
>  around.
> 
>  From the "dist" directory I ran "mvn site" which did not work:
> 
>  [INFO] Generating "Dependency Management" report---
>  maven-project-info-reports-plugin:2.3.1
>  Downloading:
> 
> 
> >>
> http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom
>  [WARNING] Unable to create Maven project from repository.
>  org.apache.maven.project.ProjectBuildingException: Error resolving
> >> project
>  artifact: Failure to find
> >> org.apache.commons:commons-vfs-examples:pom:2.0
>  in
>  http://r
>  epo1.maven.org/maven2 was cached in the local repository, resolution
> >> will
>  not be reattempted until the update interval of central has elapsed or
>  updates are for
>  ced for project org.apache.commons:commons-vfs-examples:pom:2.0
> at
> 
> 
> >>
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272)
> at
> 
> 
> >>
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
> at
> 
> 
> >>
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)
>  Why would building the site require an installed VFS

Re: [Vote] Release Commons VFS 2.0

2011-08-17 Thread Phil Steitz

On 8/17/11 12:43 PM, ralph.goers @dslextreme.com wrote:
> The sandbox question I can't answer very well. The sandbox stuff was there
> long before I arrived to work on VFS, although I rewrote the webdav stuff
> and moved it to core. The only real description is on the web site under
> "File Systems" where it says they under in development (not by me :-) ).
>
> None of the sandbox stuff appears to have been distributed with the 1.0
> release, including in the source distribution. I don't know of a  way I can
> stop Maven from deploying it to the staging repo, but I can certainly delete
> it from there just like I did the distribution zips. If desired, I'd have to
> do another release to remove that source from the release.  It would also
> stay on the web site.

Staying on the web site is fine.  Releasing code and jars that we do
not intend to support is not, so I am -1 on this release.   We used
to have an /experimental tree in [math] that we omitted from source
and binary releases.  In the source assembly descriptor, this kind
of thing at least used to work:


  src
  
**/mantissa/**
**/experimental/**
  


Phil
>
> Ralph
>
>
> On Wed, Aug 17, 2011 at 12:27 PM, Phil Steitz  wrote:
>
>> On 8/17/11 11:32 AM, ralph.goers @dslextreme.com wrote:
>>> What do you mean "It did not work"?  This is a multi-project site so in
>>> general mvn site is useless.  You have to run mvn site:stage-deply
>>> -DstagingSiteURL="file url where I want the site to go".  I suppose I
>> could
>>> add that to the readme, but it is documented pretty well on the maven
>> site
>>> plugin web site.
>>>
>>> In a prior release candidate I wasn't generating the release notes and I
>> had
>>> the comment in the README.  The release was vetoed due to the lack of
>>> release notes. I simply forgot to delete the README.
>>>
>>> Did you run announcement-generate from the core directory? That only
>> works
>>> at the project root.
>>>
>>> The build instructions consist of:
>>>
>>> mvn clean install
>> Those instructions appear on the "Download and Build" paged linked
>> in the main site menu, so I don't see this as a a blocker.
>> Instructions on how to build the site are nice to have, but not
>> showstoppers, IMO - especially since they generally stop working as
>> incompatible plugin and / or maven versions change.
>>
>> One question I have and I apologize if this has already been
>> discussed is are we sure we want to release the "sandbox" stuff?
>> There is no disclaimer of any kind on the web site or in the release
>> notes.  If the contents of that jar are being released as normal
>> artifacts, why is it called "sandbox"?  If not, why no explanation
>> anywhere of what "sandbox" means?
>>
>> Phil
>>> Ralph
>>>
>>> On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory >> wrote:
>>>
 Hi All:

 I am not sure if I am building correctly, but here is what I found. Some
 build instructions in the readme.txt file would help.

 Downloaded source zip from
 http://people.apache.org/~rgoers/commons-vfs/staged/

 From the root I ran "mvn site" which did not work. Fine, starting to
>> poke
 around.

 From the "dist" directory I ran "mvn site" which did not work:

 [INFO] Generating "Dependency Management" report---
 maven-project-info-reports-plugin:2.3.1
 Downloading:


>> http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom
 [WARNING] Unable to create Maven project from repository.
 org.apache.maven.project.ProjectBuildingException: Error resolving
>> project
 artifact: Failure to find
>> org.apache.commons:commons-vfs-examples:pom:2.0
 in
 http://r
 epo1.maven.org/maven2 was cached in the local repository, resolution
>> will
 not be reattempted until the update interval of central has elapsed or
 updates are for
 ced for project org.apache.commons:commons-vfs-examples:pom:2.0
at


>> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272)
at


>> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
at


>> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)
 Why would building the site require an installed VFS2?

 The README.txt says to run "mvn changes:announcement-generate" to get
 release notes but there is a RELEASE-NOTES.txt file in the same dir. Why
>> do
 we need two?

 When I do run "mvn changes:announcement-generate", I get:

 [INFO] --- maven-changes-plugin:2.4:announcement-generate (default-cli)
>> @
 commons-vfs2 ---
 [WARNING] changes.xml file
 C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist.

 There is no such file.

 I do not know if I should -1 this because there are no build

Re: [Vote] Release Commons VFS 2.0

Nope. That is my mistake.  Maven generated them when it uploaded them to the
Nexus staging repo. But I deleted that since we don't deliver them from
there. I then uploaded the artifacts from where they were built on my
machine to the directory on people.a.o rather than grabbing them from Nexus,
which is what I should have done.  I'll have to correct that.

Ralph

On Wed, Aug 17, 2011 at 12:45 PM, Oliver Heger  wrote:

> Build is now successful under Windows 7 with Java 1.5 and 1.6. Artifacts
> and site look good.
>
> The only thing I am missing are md5 files. Are they required (other
> components used to have them)? If not, you can count my +1.
>
> Oliver
>
> Am 17.08.2011 07:44, schrieb Ralph Goers:
>
>  This is a vote to release Apache Commons VFS 2.0.
>>
>> Changes made since the last candidate:
>>
>> * Fixed the manifest error that was causing the build to fail.
>> * Changed the copyright date in the Notice file from 2010 to 2011.
>> * Removed the references to javamail from the Notice file.
>> * Removed all the @version tags
>> * Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and
>> src/changes/announcement.vm (osgi/MANIFEST.MF has been removed).
>> * Modified the release notes to mention the code is not source compatible
>> with VFS 1.x and that the package name changed.
>> * Fixed the WARNING for the use of the deprecated tasks element.
>> * Fixed the WARNING for the use of the deprecated systemProperties
>> element.
>> * Made sure all jars have NOTICE.txt and LICENSE.txt
>>
>> The build message
>> [WARNING] Ignoring project type pom - supportedProjectTypes = [jar,
>> bundle]
>> was not fixed as that is due to commons parent causing the maven-bundle
>> plugin to run on all subprojects, including those that don't generate
>> bundles or jars.
>>
>> I have also removed files that shouldn't be present in the Maven
>> repository from the staging repo.
>>
>> [ ] +1 release it
>> [ ] +0 go ahead I don't care
>> [ ] -1 no, do not release it because.
>>
>> Ralph
>>
>>
>> Tag: https://svn.apache.org/repos/**asf/commons/proper/vfs/tags/**
>> commons-vfs2-project-2.0/
>>  (revision 1158401).
>>
>> Site: 
>> http://people.apache.org/~**rgoers/commons-vfs/site/
>>
>> Binaries: 
>> http://people.apache.org/~**rgoers/commons-vfs/staged/
>>
>> The following artifacts have been staged to the org.apache.commons-045
>> (u:rgoers, a:208.29.163.248) repository.
>>
>> The Maven artifacts are at:
>>
>> https://repository.apache.org/**content/groups/staging/org/**
>> apache/commons/commons-vfs2/
>> https://repository.apache.org/**content/groups/staging/org/**
>> apache/commons/commons-vfs2-**examples/
>> https://repository.apache.org/**content/groups/staging/org/**
>> apache/commons/commons-vfs2-**project/
>> https://repository.apache.org/**content/groups/staging/org/**
>> apache/commons/commons-vfs2-**sandbox/
>>
>> and consist of
>>
>> archetype-catalog.xml
>> commons-vfs2-examples-2.0-**javadoc.jar
>> commons-vfs2-examples-2.0-**sources.jar.asc
>> commons-vfs2-examples-2.0.pom
>> commons-vfs2-examples-2.0-**tests.jar
>> commons-vfs2-examples-2.0-**tests.jar.asc
>> commons-vfs2-examples-2.0.jar.**asc
>> commons-vfs2-examples-2.0.pom.**asc
>> commons-vfs2-examples-2.0-**javadoc.jar.asc
>> commons-vfs2-examples-2.0.jar
>> commons-vfs2-examples-2.0-**sources.jar
>> commons-vfs2-project-2.0.pom.**asc
>> commons-vfs2-project-2.0.pom
>> commons-vfs2-sandbox-2.0.pom.**asc
>> commons-vfs2-sandbox-2.0-**sources.jar.asc
>> commons-vfs2-sandbox-2.0-test-**sources.jar.asc
>> commons-vfs2-sandbox-2.0.jar
>> commons-vfs2-sandbox-2.0-**javadoc.jar
>> commons-vfs2-sandbox-2.0-test-**sources.jar
>> commons-vfs2-sandbox-2.0.jar.**asc
>> commons-vfs2-sandbox-2.0-**sources.jar
>> commons-vfs2-sandbox-2.0-**javadoc.jar.asc
>> commons-vfs2-sandbox-2.0-**tests.jar.asc
>> commons-vfs2-sandbox-2.0-**tests.jar
>> commons-vfs2-sandbox-2.0.pom
>> commons-vfs2-2.0.pom.asc
>> commons-vfs2-2.0-javadoc.jar
>> commons-vfs2-2.0-tests.jar.asc
>> commons-vfs2-2.0-tests.jar
>> commons-vfs2-2.0.pom
>> commons-vfs2-2.0.jar
>> commons-vfs2-2.0-sources.jar.**asc
>> commons-vfs2-2.0-test-sources.**jar.asc
>> commons-vfs2-2.0.jar.asc
>> commons-vfs2-2.0-sources.jar
>> commons-vfs2-2.0-test-sources.**jar
>> commons-vfs2-2.0-javadoc.jar.**asc
>>
>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@commons.**apache.org
> For additiona

Re: [Vote] Release Commons VFS 2.0

2011-08-17 Thread Phil Steitz

On 8/17/11 12:45 PM, Oliver Heger wrote:
> Build is now successful under Windows 7 with Java 1.5 and 1.6.
> Artifacts and site look good.
>
> The only thing I am missing are md5 files. Are they required
> (other components used to have them)? If not, you can count my +1.

The md5s are required and we should test them as part of validating
the release candidate.

Phil
>
> Oliver
>
> Am 17.08.2011 07:44, schrieb Ralph Goers:
>> This is a vote to release Apache Commons VFS 2.0.
>>
>> Changes made since the last candidate:
>>
>> * Fixed the manifest error that was causing the build to fail.
>> * Changed the copyright date in the Notice file from 2010 to 2011.
>> * Removed the references to javamail from the Notice file.
>> * Removed all the @version tags
>> * Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and
>> src/changes/announcement.vm (osgi/MANIFEST.MF has been removed).
>> * Modified the release notes to mention the code is not source
>> compatible with VFS 1.x and that the package name changed.
>> * Fixed the WARNING for the use of the deprecated tasks element.
>> * Fixed the WARNING for the use of the deprecated
>> systemProperties element.
>> * Made sure all jars have NOTICE.txt and LICENSE.txt
>>
>> The build message
>> [WARNING] Ignoring project type pom - supportedProjectTypes =
>> [jar, bundle]
>> was not fixed as that is due to commons parent causing the
>> maven-bundle plugin to run on all subprojects, including those
>> that don't generate bundles or jars.
>>
>> I have also removed files that shouldn't be present in the Maven
>> repository from the staging repo.
>>
>> [ ] +1 release it
>> [ ] +0 go ahead I don't care
>> [ ] -1 no, do not release it because.
>>
>> Ralph
>>
>>
>> Tag:
>> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/
>>  
>> (revision 1158401).
>>
>> Site: http://people.apache.org/~rgoers/commons-vfs/site/
>>
>> Binaries: http://people.apache.org/~rgoers/commons-vfs/staged/
>>
>> The following artifacts have been staged to the
>> org.apache.commons-045 (u:rgoers, a:208.29.163.248) repository.
>>
>> The Maven artifacts are at:
>>
>> https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2/
>>
>> https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-examples/
>>
>> https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-project/
>>
>> https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-sandbox/
>>
>>
>> and consist of
>>
>> archetype-catalog.xml
>> commons-vfs2-examples-2.0-javadoc.jar
>> commons-vfs2-examples-2.0-sources.jar.asc
>> commons-vfs2-examples-2.0.pom
>> commons-vfs2-examples-2.0-tests.jar
>> commons-vfs2-examples-2.0-tests.jar.asc
>> commons-vfs2-examples-2.0.jar.asc
>> commons-vfs2-examples-2.0.pom.asc
>> commons-vfs2-examples-2.0-javadoc.jar.asc
>> commons-vfs2-examples-2.0.jar
>> commons-vfs2-examples-2.0-sources.jar
>> commons-vfs2-project-2.0.pom.asc
>> commons-vfs2-project-2.0.pom
>> commons-vfs2-sandbox-2.0.pom.asc
>> commons-vfs2-sandbox-2.0-sources.jar.asc
>> commons-vfs2-sandbox-2.0-test-sources.jar.asc
>> commons-vfs2-sandbox-2.0.jar
>> commons-vfs2-sandbox-2.0-javadoc.jar
>> commons-vfs2-sandbox-2.0-test-sources.jar
>> commons-vfs2-sandbox-2.0.jar.asc
>> commons-vfs2-sandbox-2.0-sources.jar
>> commons-vfs2-sandbox-2.0-javadoc.jar.asc
>> commons-vfs2-sandbox-2.0-tests.jar.asc
>> commons-vfs2-sandbox-2.0-tests.jar
>> commons-vfs2-sandbox-2.0.pom
>> commons-vfs2-2.0.pom.asc
>> commons-vfs2-2.0-javadoc.jar
>> commons-vfs2-2.0-tests.jar.asc
>> commons-vfs2-2.0-tests.jar
>> commons-vfs2-2.0.pom
>> commons-vfs2-2.0.jar
>> commons-vfs2-2.0-sources.jar.asc
>> commons-vfs2-2.0-test-sources.jar.asc
>> commons-vfs2-2.0.jar.asc
>> commons-vfs2-2.0-sources.jar
>> commons-vfs2-2.0-test-sources.jar
>> commons-vfs2-2.0-javadoc.jar.asc
>
>
> -
> 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] Release Commons VFS 2.0

2011-08-17 Thread Oliver Heger

Build is now successful under Windows 7 with Java 1.5 and 1.6. Artifacts 
and site look good.


The only thing I am missing are md5 files. Are they required (other 
components used to have them)? If not, you can count my +1.


Oliver

Am 17.08.2011 07:44, schrieb Ralph Goers:

This is a vote to release Apache Commons VFS 2.0.

Changes made since the last candidate:

* Fixed the manifest error that was causing the build to fail.
* Changed the copyright date in the Notice file from 2010 to 2011.
* Removed the references to javamail from the Notice file.
* Removed all the @version tags
* Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and 
src/changes/announcement.vm (osgi/MANIFEST.MF has been removed).
* Modified the release notes to mention the code is not source compatible with 
VFS 1.x and that the package name changed.
* Fixed the WARNING for the use of the deprecated tasks element.
* Fixed the WARNING for the use of the deprecated systemProperties element.
* Made sure all jars have NOTICE.txt and LICENSE.txt

The build message
[WARNING] Ignoring project type pom - supportedProjectTypes = [jar, bundle]
was not fixed as that is due to commons parent causing the maven-bundle plugin 
to run on all subprojects, including those that don't generate bundles or jars.

I have also removed files that shouldn't be present in the Maven repository 
from the staging repo.

[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because.

Ralph


Tag: 
https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/
  (revision 1158401).

Site: http://people.apache.org/~rgoers/commons-vfs/site/

Binaries: http://people.apache.org/~rgoers/commons-vfs/staged/

The following artifacts have been staged to the org.apache.commons-045 
(u:rgoers, a:208.29.163.248) repository.

The Maven artifacts are at:

https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2/
https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-examples/
https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-project/
https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-sandbox/

and consist of

archetype-catalog.xml
commons-vfs2-examples-2.0-javadoc.jar
commons-vfs2-examples-2.0-sources.jar.asc
commons-vfs2-examples-2.0.pom
commons-vfs2-examples-2.0-tests.jar
commons-vfs2-examples-2.0-tests.jar.asc
commons-vfs2-examples-2.0.jar.asc
commons-vfs2-examples-2.0.pom.asc
commons-vfs2-examples-2.0-javadoc.jar.asc
commons-vfs2-examples-2.0.jar
commons-vfs2-examples-2.0-sources.jar
commons-vfs2-project-2.0.pom.asc
commons-vfs2-project-2.0.pom
commons-vfs2-sandbox-2.0.pom.asc
commons-vfs2-sandbox-2.0-sources.jar.asc
commons-vfs2-sandbox-2.0-test-sources.jar.asc
commons-vfs2-sandbox-2.0.jar
commons-vfs2-sandbox-2.0-javadoc.jar
commons-vfs2-sandbox-2.0-test-sources.jar
commons-vfs2-sandbox-2.0.jar.asc
commons-vfs2-sandbox-2.0-sources.jar
commons-vfs2-sandbox-2.0-javadoc.jar.asc
commons-vfs2-sandbox-2.0-tests.jar.asc
commons-vfs2-sandbox-2.0-tests.jar
commons-vfs2-sandbox-2.0.pom
commons-vfs2-2.0.pom.asc
commons-vfs2-2.0-javadoc.jar
commons-vfs2-2.0-tests.jar.asc
commons-vfs2-2.0-tests.jar
commons-vfs2-2.0.pom
commons-vfs2-2.0.jar
commons-vfs2-2.0-sources.jar.asc
commons-vfs2-2.0-test-sources.jar.asc
commons-vfs2-2.0.jar.asc
commons-vfs2-2.0-sources.jar
commons-vfs2-2.0-test-sources.jar
commons-vfs2-2.0-javadoc.jar.asc



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

Re: [Vote] Release Commons VFS 2.0

The sandbox question I can't answer very well. The sandbox stuff was there
long before I arrived to work on VFS, although I rewrote the webdav stuff
and moved it to core. The only real description is on the web site under
"File Systems" where it says they under in development (not by me :-) ).

None of the sandbox stuff appears to have been distributed with the 1.0
release, including in the source distribution. I don't know of a  way I can
stop Maven from deploying it to the staging repo, but I can certainly delete
it from there just like I did the distribution zips. If desired, I'd have to
do another release to remove that source from the release.  It would also
stay on the web site.

Ralph


On Wed, Aug 17, 2011 at 12:27 PM, Phil Steitz  wrote:

> On 8/17/11 11:32 AM, ralph.goers @dslextreme.com wrote:
> > What do you mean "It did not work"?  This is a multi-project site so in
> > general mvn site is useless.  You have to run mvn site:stage-deply
> > -DstagingSiteURL="file url where I want the site to go".  I suppose I
> could
> > add that to the readme, but it is documented pretty well on the maven
> site
> > plugin web site.
> >
> > In a prior release candidate I wasn't generating the release notes and I
> had
> > the comment in the README.  The release was vetoed due to the lack of
> > release notes. I simply forgot to delete the README.
> >
> > Did you run announcement-generate from the core directory? That only
> works
> > at the project root.
> >
> > The build instructions consist of:
> >
> > mvn clean install
>
> Those instructions appear on the "Download and Build" paged linked
> in the main site menu, so I don't see this as a a blocker.
> Instructions on how to build the site are nice to have, but not
> showstoppers, IMO - especially since they generally stop working as
> incompatible plugin and / or maven versions change.
>
> One question I have and I apologize if this has already been
> discussed is are we sure we want to release the "sandbox" stuff?
> There is no disclaimer of any kind on the web site or in the release
> notes.  If the contents of that jar are being released as normal
> artifacts, why is it called "sandbox"?  If not, why no explanation
> anywhere of what "sandbox" means?
>
> Phil
> >
> > Ralph
> >
> > On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory  >wrote:
> >
> >> Hi All:
> >>
> >> I am not sure if I am building correctly, but here is what I found. Some
> >> build instructions in the readme.txt file would help.
> >>
> >> Downloaded source zip from
> >> http://people.apache.org/~rgoers/commons-vfs/staged/
> >>
> >> From the root I ran "mvn site" which did not work. Fine, starting to
> poke
> >> around.
> >>
> >> From the "dist" directory I ran "mvn site" which did not work:
> >>
> >> [INFO] Generating "Dependency Management" report---
> >> maven-project-info-reports-plugin:2.3.1
> >> Downloading:
> >>
> >>
> http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom
> >> [WARNING] Unable to create Maven project from repository.
> >> org.apache.maven.project.ProjectBuildingException: Error resolving
> project
> >> artifact: Failure to find
> org.apache.commons:commons-vfs-examples:pom:2.0
> >> in
> >> http://r
> >> epo1.maven.org/maven2 was cached in the local repository, resolution
> will
> >> not be reattempted until the update interval of central has elapsed or
> >> updates are for
> >> ced for project org.apache.commons:commons-vfs-examples:pom:2.0
> >>at
> >>
> >>
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272)
> >>at
> >>
> >>
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
> >>at
> >>
> >>
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)
> >>
> >> Why would building the site require an installed VFS2?
> >>
> >> The README.txt says to run "mvn changes:announcement-generate" to get
> >> release notes but there is a RELEASE-NOTES.txt file in the same dir. Why
> do
> >> we need two?
> >>
> >> When I do run "mvn changes:announcement-generate", I get:
> >>
> >> [INFO] --- maven-changes-plugin:2.4:announcement-generate (default-cli)
> @
> >> commons-vfs2 ---
> >> [WARNING] changes.xml file
> >> C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist.
> >>
> >> There is no such file.
> >>
> >> I do not know if I should -1 this because there are no build
> instructions,
> >> or if there are, they are located in some non-obvious spot.
> >>
> >> Gary
> >>
> >> On Wed, Aug 17, 2011 at 1:44 AM, Ralph Goers <
> ralph.go...@dslextreme.com
> >>> wrote:
> >>> This is a vote to release Apache Commons VFS 2.0.
> >>>
> >>> Changes made since the last candidate:
> >>>
> >>> * Fixed the manifest error that was causing the build to fail.
> >>> * Changed the copyright date in the Notice file from 2010 to 2011.
> >>> * Removed the references to javamai

Re: [Vote] Release Commons VFS 2.0

2011-08-17 Thread Phil Steitz

On 8/17/11 11:32 AM, ralph.goers @dslextreme.com wrote:
> What do you mean "It did not work"?  This is a multi-project site so in
> general mvn site is useless.  You have to run mvn site:stage-deply
> -DstagingSiteURL="file url where I want the site to go".  I suppose I could
> add that to the readme, but it is documented pretty well on the maven site
> plugin web site.
>
> In a prior release candidate I wasn't generating the release notes and I had
> the comment in the README.  The release was vetoed due to the lack of
> release notes. I simply forgot to delete the README.
>
> Did you run announcement-generate from the core directory? That only works
> at the project root.
>
> The build instructions consist of:
>
> mvn clean install

Those instructions appear on the "Download and Build" paged linked
in the main site menu, so I don't see this as a a blocker. 
Instructions on how to build the site are nice to have, but not
showstoppers, IMO - especially since they generally stop working as
incompatible plugin and / or maven versions change.

One question I have and I apologize if this has already been
discussed is are we sure we want to release the "sandbox" stuff? 
There is no disclaimer of any kind on the web site or in the release
notes.  If the contents of that jar are being released as normal
artifacts, why is it called "sandbox"?  If not, why no explanation
anywhere of what "sandbox" means?

Phil
>
> Ralph
>
> On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory wrote:
>
>> Hi All:
>>
>> I am not sure if I am building correctly, but here is what I found. Some
>> build instructions in the readme.txt file would help.
>>
>> Downloaded source zip from
>> http://people.apache.org/~rgoers/commons-vfs/staged/
>>
>> From the root I ran "mvn site" which did not work. Fine, starting to poke
>> around.
>>
>> From the "dist" directory I ran "mvn site" which did not work:
>>
>> [INFO] Generating "Dependency Management" report---
>> maven-project-info-reports-plugin:2.3.1
>> Downloading:
>>
>> http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom
>> [WARNING] Unable to create Maven project from repository.
>> org.apache.maven.project.ProjectBuildingException: Error resolving project
>> artifact: Failure to find org.apache.commons:commons-vfs-examples:pom:2.0
>> in
>> http://r
>> epo1.maven.org/maven2 was cached in the local repository, resolution will
>> not be reattempted until the update interval of central has elapsed or
>> updates are for
>> ced for project org.apache.commons:commons-vfs-examples:pom:2.0
>>at
>>
>> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272)
>>at
>>
>> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
>>at
>>
>> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)
>>
>> Why would building the site require an installed VFS2?
>>
>> The README.txt says to run "mvn changes:announcement-generate" to get
>> release notes but there is a RELEASE-NOTES.txt file in the same dir. Why do
>> we need two?
>>
>> When I do run "mvn changes:announcement-generate", I get:
>>
>> [INFO] --- maven-changes-plugin:2.4:announcement-generate (default-cli) @
>> commons-vfs2 ---
>> [WARNING] changes.xml file
>> C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist.
>>
>> There is no such file.
>>
>> I do not know if I should -1 this because there are no build instructions,
>> or if there are, they are located in some non-obvious spot.
>>
>> Gary
>>
>> On Wed, Aug 17, 2011 at 1:44 AM, Ralph Goers >> wrote:
>>> This is a vote to release Apache Commons VFS 2.0.
>>>
>>> Changes made since the last candidate:
>>>
>>> * Fixed the manifest error that was causing the build to fail.
>>> * Changed the copyright date in the Notice file from 2010 to 2011.
>>> * Removed the references to javamail from the Notice file.
>>> * Removed all the @version tags
>>> * Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and
>>> src/changes/announcement.vm (osgi/MANIFEST.MF has been removed).
>>> * Modified the release notes to mention the code is not source compatible
>>> with VFS 1.x and that the package name changed.
>>> * Fixed the WARNING for the use of the deprecated tasks element.
>>> * Fixed the WARNING for the use of the deprecated systemProperties
>> element.
>>> * Made sure all jars have NOTICE.txt and LICENSE.txt
>>>
>>> The build message
>>> [WARNING] Ignoring project type pom - supportedProjectTypes = [jar,
>> bundle]
>>> was not fixed as that is due to commons parent causing the maven-bundle
>>> plugin to run on all subprojects, including those that don't generate
>>> bundles or jars.
>>>
>>> I have also removed files that shouldn't be present in the Maven
>> repository
>>> from the staging repo.
>>>
>>> [ ] +1 release it
>>> [ ] +0 go ahead I don't care
>>> [ ] -1 no, do not release it be

Re: [Vote] Release Commons VFS 2.0

Commons parent has both a "release" profile and an "apache-release" profile.
The apache-release profile is used by the release plugin as it is set up for
the ASF. I'm not sure what value-add (or value loss) the "release" profile
provides.

On Wed, Aug 17, 2011 at 12:12 PM, ralph.goers @dslextreme.com <
ralph.go...@dslextreme.com> wrote:

> The Maven release plugin uses the apache-release profile which is set up in
> the apache parent pom.
>
> Ralph
>
>
> On Wed, Aug 17, 2011 at 11:49 AM, sebb  wrote:
>
>> On 17 August 2011 19:37, ralph.goers @dslextreme.com
>>  wrote:
>> > Oh - and if for some non-obvious reason you want to create the
>> distribution
>> > jars when you do the build you can run
>> >
>> > mvn -P apache-release clean install.
>>
>> I though commons normally use their own release profile, which is
>> -Prelease ?
>>
>> > On Wed, Aug 17, 2011 at 11:35 AM, ralph.goers @dslextreme.com <
>> > ralph.go...@dslextreme.com> wrote:
>> >
>> >> Oops. That should be mvn site:stage-deploy.
>> >>
>> >> Ralph
>> >>
>> >>
>> >> On Wed, Aug 17, 2011 at 11:32 AM, ralph.goers @dslextreme.com <
>> >> ralph.go...@dslextreme.com> wrote:
>> >>
>> >>> What do you mean "It did not work"?  This is a multi-project site so
>> in
>> >>> general mvn site is useless.  You have to run mvn site:stage-deply
>> >>> -DstagingSiteURL="file url where I want the site to go".  I suppose I
>> could
>> >>> add that to the readme, but it is documented pretty well on the maven
>> site
>> >>> plugin web site.
>> >>>
>> >>> In a prior release candidate I wasn't generating the release notes and
>> I
>> >>> had the comment in the README.  The release was vetoed due to the lack
>> of
>> >>> release notes. I simply forgot to delete the README.
>> >>>
>> >>> Did you run announcement-generate from the core directory? That only
>> works
>> >>> at the project root.
>> >>>
>> >>> The build instructions consist of:
>> >>>
>> >>> mvn clean install
>> >>>
>> >>> Ralph
>> >>>
>> >>>
>> >>> On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory > >wrote:
>> >>>
>>  Hi All:
>> 
>>  I am not sure if I am building correctly, but here is what I found.
>> Some
>>  build instructions in the readme.txt file would help.
>> 
>>  Downloaded source zip from
>>  http://people.apache.org/~rgoers/commons-vfs/staged/
>> 
>>  From the root I ran "mvn site" which did not work. Fine, starting to
>> poke
>>  around.
>> 
>>  From the "dist" directory I ran "mvn site" which did not work:
>> 
>>  [INFO] Generating "Dependency Management" report---
>>  maven-project-info-reports-plugin:2.3.1
>>  Downloading:
>> 
>> 
>> http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom
>>  [WARNING] Unable to create Maven project from repository.
>>  org.apache.maven.project.ProjectBuildingException: Error resolving
>>  project
>>  artifact: Failure to find
>> org.apache.commons:commons-vfs-examples:pom:2.0
>>  in
>>  http://r
>>  epo1.maven.org/maven2 was cached in the local repository, resolution
>>  will
>>  not be reattempted until the update interval of central has elapsed
>> or
>>  updates are for
>>  ced for project org.apache.commons:commons-vfs-examples:pom:2.0
>> at
>> 
>> 
>> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272)
>> at
>> 
>> 
>> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
>> at
>> 
>> 
>> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)
>> 
>>  Why would building the site require an installed VFS2?
>> 
>>  The README.txt says to run "mvn changes:announcement-generate" to get
>>  release notes but there is a RELEASE-NOTES.txt file in the same dir.
>> Why
>>  do
>>  we need two?
>> 
>>  When I do run "mvn changes:announcement-generate", I get:
>> 
>>  [INFO] --- maven-changes-plugin:2.4:announcement-generate
>> (default-cli) @
>>  commons-vfs2 ---
>>  [WARNING] changes.xml file
>>  C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist.
>> 
>>  There is no such file.
>> 
>>  I do not know if I should -1 this because there are no build
>>  instructions,
>>  or if there are, they are located in some non-obvious spot.
>> 
>>  Gary
>> 
>>  On Wed, Aug 17, 2011 at 1:44 AM, Ralph Goers <
>> ralph.go...@dslextreme.com
>>  >wrote:
>> 
>>  > This is a vote to release Apache Commons VFS 2.0.
>>  >
>>  > Changes made since the last candidate:
>>  >
>>  > * Fixed the manifest error that was causing the build to fail.
>>  > * Changed the copyright date in the Notice file from 2010 to 2011.
>>  > * Removed the references to javamail from the Notice file.
>>  > *

Re: [Vote] Release Commons VFS 2.0

The Maven release plugin uses the apache-release profile which is set up in
the apache parent pom.

Ralph

On Wed, Aug 17, 2011 at 11:49 AM, sebb  wrote:

> On 17 August 2011 19:37, ralph.goers @dslextreme.com
>  wrote:
> > Oh - and if for some non-obvious reason you want to create the
> distribution
> > jars when you do the build you can run
> >
> > mvn -P apache-release clean install.
>
> I though commons normally use their own release profile, which is -Prelease
> ?
>
> > On Wed, Aug 17, 2011 at 11:35 AM, ralph.goers @dslextreme.com <
> > ralph.go...@dslextreme.com> wrote:
> >
> >> Oops. That should be mvn site:stage-deploy.
> >>
> >> Ralph
> >>
> >>
> >> On Wed, Aug 17, 2011 at 11:32 AM, ralph.goers @dslextreme.com <
> >> ralph.go...@dslextreme.com> wrote:
> >>
> >>> What do you mean "It did not work"?  This is a multi-project site so in
> >>> general mvn site is useless.  You have to run mvn site:stage-deply
> >>> -DstagingSiteURL="file url where I want the site to go".  I suppose I
> could
> >>> add that to the readme, but it is documented pretty well on the maven
> site
> >>> plugin web site.
> >>>
> >>> In a prior release candidate I wasn't generating the release notes and
> I
> >>> had the comment in the README.  The release was vetoed due to the lack
> of
> >>> release notes. I simply forgot to delete the README.
> >>>
> >>> Did you run announcement-generate from the core directory? That only
> works
> >>> at the project root.
> >>>
> >>> The build instructions consist of:
> >>>
> >>> mvn clean install
> >>>
> >>> Ralph
> >>>
> >>>
> >>> On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory  >wrote:
> >>>
>  Hi All:
> 
>  I am not sure if I am building correctly, but here is what I found.
> Some
>  build instructions in the readme.txt file would help.
> 
>  Downloaded source zip from
>  http://people.apache.org/~rgoers/commons-vfs/staged/
> 
>  From the root I ran "mvn site" which did not work. Fine, starting to
> poke
>  around.
> 
>  From the "dist" directory I ran "mvn site" which did not work:
> 
>  [INFO] Generating "Dependency Management" report---
>  maven-project-info-reports-plugin:2.3.1
>  Downloading:
> 
> 
> http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom
>  [WARNING] Unable to create Maven project from repository.
>  org.apache.maven.project.ProjectBuildingException: Error resolving
>  project
>  artifact: Failure to find
> org.apache.commons:commons-vfs-examples:pom:2.0
>  in
>  http://r
>  epo1.maven.org/maven2 was cached in the local repository, resolution
>  will
>  not be reattempted until the update interval of central has elapsed or
>  updates are for
>  ced for project org.apache.commons:commons-vfs-examples:pom:2.0
> at
> 
> 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272)
> at
> 
> 
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
> at
> 
> 
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)
> 
>  Why would building the site require an installed VFS2?
> 
>  The README.txt says to run "mvn changes:announcement-generate" to get
>  release notes but there is a RELEASE-NOTES.txt file in the same dir.
> Why
>  do
>  we need two?
> 
>  When I do run "mvn changes:announcement-generate", I get:
> 
>  [INFO] --- maven-changes-plugin:2.4:announcement-generate
> (default-cli) @
>  commons-vfs2 ---
>  [WARNING] changes.xml file
>  C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist.
> 
>  There is no such file.
> 
>  I do not know if I should -1 this because there are no build
>  instructions,
>  or if there are, they are located in some non-obvious spot.
> 
>  Gary
> 
>  On Wed, Aug 17, 2011 at 1:44 AM, Ralph Goers <
> ralph.go...@dslextreme.com
>  >wrote:
> 
>  > This is a vote to release Apache Commons VFS 2.0.
>  >
>  > Changes made since the last candidate:
>  >
>  > * Fixed the manifest error that was causing the build to fail.
>  > * Changed the copyright date in the Notice file from 2010 to 2011.
>  > * Removed the references to javamail from the Notice file.
>  > * Removed all the @version tags
>  > * Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and
>  > src/changes/announcement.vm (osgi/MANIFEST.MF has been removed).
>  > * Modified the release notes to mention the code is not source
>  compatible
>  > with VFS 1.x and that the package name changed.
>  > * Fixed the WARNING for the use of the deprecated tasks element.
>  > * Fixed the WARNING for the use of the deprecated systemProperties
>  element.
>

Re: [Vote] Release Commons VFS 2.0

On 17 August 2011 19:37, ralph.goers @dslextreme.com
 wrote:
> Oh - and if for some non-obvious reason you want to create the distribution
> jars when you do the build you can run
>
> mvn -P apache-release clean install.

I though commons normally use their own release profile, which is -Prelease ?

> On Wed, Aug 17, 2011 at 11:35 AM, ralph.goers @dslextreme.com <
> ralph.go...@dslextreme.com> wrote:
>
>> Oops. That should be mvn site:stage-deploy.
>>
>> Ralph
>>
>>
>> On Wed, Aug 17, 2011 at 11:32 AM, ralph.goers @dslextreme.com <
>> ralph.go...@dslextreme.com> wrote:
>>
>>> What do you mean "It did not work"?  This is a multi-project site so in
>>> general mvn site is useless.  You have to run mvn site:stage-deply
>>> -DstagingSiteURL="file url where I want the site to go".  I suppose I could
>>> add that to the readme, but it is documented pretty well on the maven site
>>> plugin web site.
>>>
>>> In a prior release candidate I wasn't generating the release notes and I
>>> had the comment in the README.  The release was vetoed due to the lack of
>>> release notes. I simply forgot to delete the README.
>>>
>>> Did you run announcement-generate from the core directory? That only works
>>> at the project root.
>>>
>>> The build instructions consist of:
>>>
>>> mvn clean install
>>>
>>> Ralph
>>>
>>>
>>> On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory wrote:
>>>
 Hi All:

 I am not sure if I am building correctly, but here is what I found. Some
 build instructions in the readme.txt file would help.

 Downloaded source zip from
 http://people.apache.org/~rgoers/commons-vfs/staged/

 From the root I ran "mvn site" which did not work. Fine, starting to poke
 around.

 From the "dist" directory I ran "mvn site" which did not work:

 [INFO] Generating "Dependency Management" report    ---
 maven-project-info-reports-plugin:2.3.1
 Downloading:

 http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom
 [WARNING] Unable to create Maven project from repository.
 org.apache.maven.project.ProjectBuildingException: Error resolving
 project
 artifact: Failure to find org.apache.commons:commons-vfs-examples:pom:2.0
 in
 http://r
 epo1.maven.org/maven2 was cached in the local repository, resolution
 will
 not be reattempted until the update interval of central has elapsed or
 updates are for
 ced for project org.apache.commons:commons-vfs-examples:pom:2.0
        at

 org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272)
        at

 org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
        at

 org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)

 Why would building the site require an installed VFS2?

 The README.txt says to run "mvn changes:announcement-generate" to get
 release notes but there is a RELEASE-NOTES.txt file in the same dir. Why
 do
 we need two?

 When I do run "mvn changes:announcement-generate", I get:

 [INFO] --- maven-changes-plugin:2.4:announcement-generate (default-cli) @
 commons-vfs2 ---
 [WARNING] changes.xml file
 C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist.

 There is no such file.

 I do not know if I should -1 this because there are no build
 instructions,
 or if there are, they are located in some non-obvious spot.

 Gary

 On Wed, Aug 17, 2011 at 1:44 AM, Ralph Goers >>> >wrote:

 > This is a vote to release Apache Commons VFS 2.0.
 >
 > Changes made since the last candidate:
 >
 > * Fixed the manifest error that was causing the build to fail.
 > * Changed the copyright date in the Notice file from 2010 to 2011.
 > * Removed the references to javamail from the Notice file.
 > * Removed all the @version tags
 > * Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and
 > src/changes/announcement.vm (osgi/MANIFEST.MF has been removed).
 > * Modified the release notes to mention the code is not source
 compatible
 > with VFS 1.x and that the package name changed.
 > * Fixed the WARNING for the use of the deprecated tasks element.
 > * Fixed the WARNING for the use of the deprecated systemProperties
 element.
 > * Made sure all jars have NOTICE.txt and LICENSE.txt
 >
 > The build message
 > [WARNING] Ignoring project type pom - supportedProjectTypes = [jar,
 bundle]
 > was not fixed as that is due to commons parent causing the maven-bundle
 > plugin to run on all subprojects, including those that don't generate
 > bundles or jars.
 >
 > I have also removed files that shouldn't be present in the Maven
 repository
 > fro

Re: [Vote] Release Commons VFS 2.0

Oh - and if for some non-obvious reason you want to create the distribution
jars when you do the build you can run

mvn -P apache-release clean install.

On Wed, Aug 17, 2011 at 11:35 AM, ralph.goers @dslextreme.com <
ralph.go...@dslextreme.com> wrote:

> Oops. That should be mvn site:stage-deploy.
>
> Ralph
>
>
> On Wed, Aug 17, 2011 at 11:32 AM, ralph.goers @dslextreme.com <
> ralph.go...@dslextreme.com> wrote:
>
>> What do you mean "It did not work"?  This is a multi-project site so in
>> general mvn site is useless.  You have to run mvn site:stage-deply
>> -DstagingSiteURL="file url where I want the site to go".  I suppose I could
>> add that to the readme, but it is documented pretty well on the maven site
>> plugin web site.
>>
>> In a prior release candidate I wasn't generating the release notes and I
>> had the comment in the README.  The release was vetoed due to the lack of
>> release notes. I simply forgot to delete the README.
>>
>> Did you run announcement-generate from the core directory? That only works
>> at the project root.
>>
>> The build instructions consist of:
>>
>> mvn clean install
>>
>> Ralph
>>
>>
>> On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory wrote:
>>
>>> Hi All:
>>>
>>> I am not sure if I am building correctly, but here is what I found. Some
>>> build instructions in the readme.txt file would help.
>>>
>>> Downloaded source zip from
>>> http://people.apache.org/~rgoers/commons-vfs/staged/
>>>
>>> From the root I ran "mvn site" which did not work. Fine, starting to poke
>>> around.
>>>
>>> From the "dist" directory I ran "mvn site" which did not work:
>>>
>>> [INFO] Generating "Dependency Management" report---
>>> maven-project-info-reports-plugin:2.3.1
>>> Downloading:
>>>
>>> http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom
>>> [WARNING] Unable to create Maven project from repository.
>>> org.apache.maven.project.ProjectBuildingException: Error resolving
>>> project
>>> artifact: Failure to find org.apache.commons:commons-vfs-examples:pom:2.0
>>> in
>>> http://r
>>> epo1.maven.org/maven2 was cached in the local repository, resolution
>>> will
>>> not be reattempted until the update interval of central has elapsed or
>>> updates are for
>>> ced for project org.apache.commons:commons-vfs-examples:pom:2.0
>>>at
>>>
>>> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272)
>>>at
>>>
>>> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
>>>at
>>>
>>> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)
>>>
>>> Why would building the site require an installed VFS2?
>>>
>>> The README.txt says to run "mvn changes:announcement-generate" to get
>>> release notes but there is a RELEASE-NOTES.txt file in the same dir. Why
>>> do
>>> we need two?
>>>
>>> When I do run "mvn changes:announcement-generate", I get:
>>>
>>> [INFO] --- maven-changes-plugin:2.4:announcement-generate (default-cli) @
>>> commons-vfs2 ---
>>> [WARNING] changes.xml file
>>> C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist.
>>>
>>> There is no such file.
>>>
>>> I do not know if I should -1 this because there are no build
>>> instructions,
>>> or if there are, they are located in some non-obvious spot.
>>>
>>> Gary
>>>
>>> On Wed, Aug 17, 2011 at 1:44 AM, Ralph Goers >> >wrote:
>>>
>>> > This is a vote to release Apache Commons VFS 2.0.
>>> >
>>> > Changes made since the last candidate:
>>> >
>>> > * Fixed the manifest error that was causing the build to fail.
>>> > * Changed the copyright date in the Notice file from 2010 to 2011.
>>> > * Removed the references to javamail from the Notice file.
>>> > * Removed all the @version tags
>>> > * Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and
>>> > src/changes/announcement.vm (osgi/MANIFEST.MF has been removed).
>>> > * Modified the release notes to mention the code is not source
>>> compatible
>>> > with VFS 1.x and that the package name changed.
>>> > * Fixed the WARNING for the use of the deprecated tasks element.
>>> > * Fixed the WARNING for the use of the deprecated systemProperties
>>> element.
>>> > * Made sure all jars have NOTICE.txt and LICENSE.txt
>>> >
>>> > The build message
>>> > [WARNING] Ignoring project type pom - supportedProjectTypes = [jar,
>>> bundle]
>>> > was not fixed as that is due to commons parent causing the maven-bundle
>>> > plugin to run on all subprojects, including those that don't generate
>>> > bundles or jars.
>>> >
>>> > I have also removed files that shouldn't be present in the Maven
>>> repository
>>> > from the staging repo.
>>> >
>>> > [ ] +1 release it
>>> > [ ] +0 go ahead I don't care
>>> > [ ] -1 no, do not release it because.
>>> >
>>> > Ralph
>>> >
>>> >
>>> > Tag:
>>> >
>>> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/(revision
>>

Re: [Vote] Release Commons VFS 2.0

Oops. That should be mvn site:stage-deploy.

Ralph

On Wed, Aug 17, 2011 at 11:32 AM, ralph.goers @dslextreme.com <
ralph.go...@dslextreme.com> wrote:

> What do you mean "It did not work"?  This is a multi-project site so in
> general mvn site is useless.  You have to run mvn site:stage-deply
> -DstagingSiteURL="file url where I want the site to go".  I suppose I could
> add that to the readme, but it is documented pretty well on the maven site
> plugin web site.
>
> In a prior release candidate I wasn't generating the release notes and I
> had the comment in the README.  The release was vetoed due to the lack of
> release notes. I simply forgot to delete the README.
>
> Did you run announcement-generate from the core directory? That only works
> at the project root.
>
> The build instructions consist of:
>
> mvn clean install
>
> Ralph
>
>
> On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory wrote:
>
>> Hi All:
>>
>> I am not sure if I am building correctly, but here is what I found. Some
>> build instructions in the readme.txt file would help.
>>
>> Downloaded source zip from
>> http://people.apache.org/~rgoers/commons-vfs/staged/
>>
>> From the root I ran "mvn site" which did not work. Fine, starting to poke
>> around.
>>
>> From the "dist" directory I ran "mvn site" which did not work:
>>
>> [INFO] Generating "Dependency Management" report---
>> maven-project-info-reports-plugin:2.3.1
>> Downloading:
>>
>> http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom
>> [WARNING] Unable to create Maven project from repository.
>> org.apache.maven.project.ProjectBuildingException: Error resolving project
>> artifact: Failure to find org.apache.commons:commons-vfs-examples:pom:2.0
>> in
>> http://r
>> epo1.maven.org/maven2 was cached in the local repository, resolution will
>> not be reattempted until the update interval of central has elapsed or
>> updates are for
>> ced for project org.apache.commons:commons-vfs-examples:pom:2.0
>>at
>>
>> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272)
>>at
>>
>> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
>>at
>>
>> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)
>>
>> Why would building the site require an installed VFS2?
>>
>> The README.txt says to run "mvn changes:announcement-generate" to get
>> release notes but there is a RELEASE-NOTES.txt file in the same dir. Why
>> do
>> we need two?
>>
>> When I do run "mvn changes:announcement-generate", I get:
>>
>> [INFO] --- maven-changes-plugin:2.4:announcement-generate (default-cli) @
>> commons-vfs2 ---
>> [WARNING] changes.xml file
>> C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist.
>>
>> There is no such file.
>>
>> I do not know if I should -1 this because there are no build instructions,
>> or if there are, they are located in some non-obvious spot.
>>
>> Gary
>>
>> On Wed, Aug 17, 2011 at 1:44 AM, Ralph Goers > >wrote:
>>
>> > This is a vote to release Apache Commons VFS 2.0.
>> >
>> > Changes made since the last candidate:
>> >
>> > * Fixed the manifest error that was causing the build to fail.
>> > * Changed the copyright date in the Notice file from 2010 to 2011.
>> > * Removed the references to javamail from the Notice file.
>> > * Removed all the @version tags
>> > * Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and
>> > src/changes/announcement.vm (osgi/MANIFEST.MF has been removed).
>> > * Modified the release notes to mention the code is not source
>> compatible
>> > with VFS 1.x and that the package name changed.
>> > * Fixed the WARNING for the use of the deprecated tasks element.
>> > * Fixed the WARNING for the use of the deprecated systemProperties
>> element.
>> > * Made sure all jars have NOTICE.txt and LICENSE.txt
>> >
>> > The build message
>> > [WARNING] Ignoring project type pom - supportedProjectTypes = [jar,
>> bundle]
>> > was not fixed as that is due to commons parent causing the maven-bundle
>> > plugin to run on all subprojects, including those that don't generate
>> > bundles or jars.
>> >
>> > I have also removed files that shouldn't be present in the Maven
>> repository
>> > from the staging repo.
>> >
>> > [ ] +1 release it
>> > [ ] +0 go ahead I don't care
>> > [ ] -1 no, do not release it because.
>> >
>> > Ralph
>> >
>> >
>> > Tag:
>> >
>> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/(revision
>>  1158401).
>> >
>> > Site: http://people.apache.org/~rgoers/commons-vfs/site/
>> >
>> > Binaries: http://people.apache.org/~rgoers/commons-vfs/staged/
>> >
>> > The following artifacts have been staged to the org.apache.commons-045
>> > (u:rgoers, a:208.29.163.248) repository.
>> >
>> > The Maven artifacts are at:
>> >
>> >
>> >
>> https://repository.apache.org/content/groups/staging/org/apache/co

Re: [Vote] Release Commons VFS 2.0

What do you mean "It did not work"?  This is a multi-project site so in
general mvn site is useless.  You have to run mvn site:stage-deply
-DstagingSiteURL="file url where I want the site to go".  I suppose I could
add that to the readme, but it is documented pretty well on the maven site
plugin web site.

In a prior release candidate I wasn't generating the release notes and I had
the comment in the README.  The release was vetoed due to the lack of
release notes. I simply forgot to delete the README.

Did you run announcement-generate from the core directory? That only works
at the project root.

The build instructions consist of:

mvn clean install

Ralph

On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory wrote:

> Hi All:
>
> I am not sure if I am building correctly, but here is what I found. Some
> build instructions in the readme.txt file would help.
>
> Downloaded source zip from
> http://people.apache.org/~rgoers/commons-vfs/staged/
>
> From the root I ran "mvn site" which did not work. Fine, starting to poke
> around.
>
> From the "dist" directory I ran "mvn site" which did not work:
>
> [INFO] Generating "Dependency Management" report---
> maven-project-info-reports-plugin:2.3.1
> Downloading:
>
> http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom
> [WARNING] Unable to create Maven project from repository.
> org.apache.maven.project.ProjectBuildingException: Error resolving project
> artifact: Failure to find org.apache.commons:commons-vfs-examples:pom:2.0
> in
> http://r
> epo1.maven.org/maven2 was cached in the local repository, resolution will
> not be reattempted until the update interval of central has elapsed or
> updates are for
> ced for project org.apache.commons:commons-vfs-examples:pom:2.0
>at
>
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272)
>at
>
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
>at
>
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)
>
> Why would building the site require an installed VFS2?
>
> The README.txt says to run "mvn changes:announcement-generate" to get
> release notes but there is a RELEASE-NOTES.txt file in the same dir. Why do
> we need two?
>
> When I do run "mvn changes:announcement-generate", I get:
>
> [INFO] --- maven-changes-plugin:2.4:announcement-generate (default-cli) @
> commons-vfs2 ---
> [WARNING] changes.xml file
> C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist.
>
> There is no such file.
>
> I do not know if I should -1 this because there are no build instructions,
> or if there are, they are located in some non-obvious spot.
>
> Gary
>
> On Wed, Aug 17, 2011 at 1:44 AM, Ralph Goers  >wrote:
>
> > This is a vote to release Apache Commons VFS 2.0.
> >
> > Changes made since the last candidate:
> >
> > * Fixed the manifest error that was causing the build to fail.
> > * Changed the copyright date in the Notice file from 2010 to 2011.
> > * Removed the references to javamail from the Notice file.
> > * Removed all the @version tags
> > * Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and
> > src/changes/announcement.vm (osgi/MANIFEST.MF has been removed).
> > * Modified the release notes to mention the code is not source compatible
> > with VFS 1.x and that the package name changed.
> > * Fixed the WARNING for the use of the deprecated tasks element.
> > * Fixed the WARNING for the use of the deprecated systemProperties
> element.
> > * Made sure all jars have NOTICE.txt and LICENSE.txt
> >
> > The build message
> > [WARNING] Ignoring project type pom - supportedProjectTypes = [jar,
> bundle]
> > was not fixed as that is due to commons parent causing the maven-bundle
> > plugin to run on all subprojects, including those that don't generate
> > bundles or jars.
> >
> > I have also removed files that shouldn't be present in the Maven
> repository
> > from the staging repo.
> >
> > [ ] +1 release it
> > [ ] +0 go ahead I don't care
> > [ ] -1 no, do not release it because.
> >
> > Ralph
> >
> >
> > Tag:
> >
> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/(revision
>  1158401).
> >
> > Site: http://people.apache.org/~rgoers/commons-vfs/site/
> >
> > Binaries: http://people.apache.org/~rgoers/commons-vfs/staged/
> >
> > The following artifacts have been staged to the org.apache.commons-045
> > (u:rgoers, a:208.29.163.248) repository.
> >
> > The Maven artifacts are at:
> >
> >
> >
> https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2/
> >
> >
> https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-examples/
> >
> >
> https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-project/
> >
> >
> https://repository.apache.org/content/groups/staging/org/apache/comm

Re: [Vote] Release Commons VFS 2.0

2011-08-17 Thread Gary Gregory

Hi All:

I am not sure if I am building correctly, but here is what I found. Some
build instructions in the readme.txt file would help.

Downloaded source zip from
http://people.apache.org/~rgoers/commons-vfs/staged/

>From the root I ran "mvn site" which did not work. Fine, starting to poke
around.

>From the "dist" directory I ran "mvn site" which did not work:

[INFO] Generating "Dependency Management" report---
maven-project-info-reports-plugin:2.3.1
Downloading:
http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom
[WARNING] Unable to create Maven project from repository.
org.apache.maven.project.ProjectBuildingException: Error resolving project
artifact: Failure to find org.apache.commons:commons-vfs-examples:pom:2.0 in
http://r
epo1.maven.org/maven2 was cached in the local repository, resolution will
not be reattempted until the update interval of central has elapsed or
updates are for
ced for project org.apache.commons:commons-vfs-examples:pom:2.0
at
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)

Why would building the site require an installed VFS2?

The README.txt says to run "mvn changes:announcement-generate" to get
release notes but there is a RELEASE-NOTES.txt file in the same dir. Why do
we need two?

When I do run "mvn changes:announcement-generate", I get:

[INFO] --- maven-changes-plugin:2.4:announcement-generate (default-cli) @
commons-vfs2 ---
[WARNING] changes.xml file
C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist.

There is no such file.

I do not know if I should -1 this because there are no build instructions,
or if there are, they are located in some non-obvious spot.

Gary

On Wed, Aug 17, 2011 at 1:44 AM, Ralph Goers wrote:

> This is a vote to release Apache Commons VFS 2.0.
>
> Changes made since the last candidate:
>
> * Fixed the manifest error that was causing the build to fail.
> * Changed the copyright date in the Notice file from 2010 to 2011.
> * Removed the references to javamail from the Notice file.
> * Removed all the @version tags
> * Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and
> src/changes/announcement.vm (osgi/MANIFEST.MF has been removed).
> * Modified the release notes to mention the code is not source compatible
> with VFS 1.x and that the package name changed.
> * Fixed the WARNING for the use of the deprecated tasks element.
> * Fixed the WARNING for the use of the deprecated systemProperties element.
> * Made sure all jars have NOTICE.txt and LICENSE.txt
>
> The build message
> [WARNING] Ignoring project type pom - supportedProjectTypes = [jar, bundle]
> was not fixed as that is due to commons parent causing the maven-bundle
> plugin to run on all subprojects, including those that don't generate
> bundles or jars.
>
> I have also removed files that shouldn't be present in the Maven repository
> from the staging repo.
>
> [ ] +1 release it
> [ ] +0 go ahead I don't care
> [ ] -1 no, do not release it because.
>
> Ralph
>
>
> Tag:
> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/
>  (revision 1158401).
>
> Site: http://people.apache.org/~rgoers/commons-vfs/site/
>
> Binaries: http://people.apache.org/~rgoers/commons-vfs/staged/
>
> The following artifacts have been staged to the org.apache.commons-045
> (u:rgoers, a:208.29.163.248) repository.
>
> The Maven artifacts are at:
>
>
> https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2/
>
> https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-examples/
>
> https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-project/
>
> https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-sandbox/
>
> and consist of
>
> archetype-catalog.xml
> commons-vfs2-examples-2.0-javadoc.jar
> commons-vfs2-examples-2.0-sources.jar.asc
> commons-vfs2-examples-2.0.pom
> commons-vfs2-examples-2.0-tests.jar
> commons-vfs2-examples-2.0-tests.jar.asc
> commons-vfs2-examples-2.0.jar.asc
> commons-vfs2-examples-2.0.pom.asc
> commons-vfs2-examples-2.0-javadoc.jar.asc
> commons-vfs2-examples-2.0.jar
> commons-vfs2-examples-2.0-sources.jar
> commons-vfs2-project-2.0.pom.asc
> commons-vfs2-project-2.0.pom
> commons-vfs2-sandbox-2.0.pom.asc
> commons-vfs2-sandbox-2.0-sources.jar.asc
> commons-vfs2-sandbox-2.0-test-sources.jar.asc
> commons-vfs2-sandbox-2.0.jar
> commons-vfs2-sandbox-2.0-javadoc.jar
> commons-vfs2-sandbox-2.0-test-sources.jar
> commons-vfs2-sandbox-2.0.jar.asc
> commons-vfs2-sandbox-2.0-sources.jar
> commons-vfs2-sandbox-2.0-javadoc.jar.asc
> commons-vfs2-sandbox-2.0-tests.jar.asc
> commons-vfs2-sandbox-

Re: [Vote] Release Commons VFS 2.0

On 14 August 2011 18:49, Ralph Goers  wrote:
>
> On Aug 14, 2011, at 10:09 AM, sebb wrote:
>
>> On 14 August 2011 18:03, Ralph Goers  wrote:
>>> Thanks, Sebb. See below.
>>>
>>> On Aug 14, 2011, at 9:50 AM, sebb wrote:
>>>
 On 14 August 2011 16:25, Ralph Goers  wrote:
> This is a vote to release Apache Commons VFS 2.0.
>
> Since the last candidate the package name was changed from vfs to vfs2. 
> Many of the Jira issues were reviewed and those that required a possibly 
> incompatible API change were addressed. Most instances of StringBuffer 
> were replaced with StringBuilder. Some synchronization issues were 
> addressed. Many javadoc and some checkstyle issues were addressed. The 
> filesystem documentation was improved to list file system capabilities.
>
> [ ] +1 release it
> [ ] +0 go ahead I don't care
> [X] -1 no, do not release it because...

 Notice file still shows 2010.

 It also refers to the (optional) Javamail library.
 Since that is not actually included in any of the archives, it should
 not be mentioned.

 [If it were necessary to include a mention of JavaMail in NOTICE, then
 it would be necessary to include the corresponding license in LICENSE]

 ==

 Not a blocker, but a pain for checking the release:
 - lots of source files contain @version $Revision $. This uses local
 time, which means my checkout of SVN does not match the source
 archives.

 There are some EOL issues:

 svn ps svn:eol-style native README.txt
 svn ps svn:eol-style native RELEASE-NOTES.txt
 svn ps svn:eol-style native osgi/MANIFEST.MF
 svn ps svn:eol-style native src/changes/announcement.vm

 I'm not convinced that the code really needs to be
 binary-incompatible, but that is a separate discussion.

 However, the release notes ought to mention code is not source
 compatible with VFS 1.x and that the package name has changed.

 mvn install produces some warnings:

 [WARNING] Ignoring project type pom - supportedProjectTypes = [jar, bundle]
 [WARNING] DEPRECATED [tasks]: Use target instead
>>>
>>> I can't fix the above two lines. They are caused by changes in 
>>> commons-parent version 21.
>>
>> Huh?
>>
>> The second warning is caused by using  instead of ; you
>> can fix that easily.
>
> You are right. That was the antrun plugin.
>
>>
>> Not sure about the first, but I would be suprised if it is anything to
>> do with Commons Parent (except that later plugins may be more picky
>> about obsolete syntax).
>
> Commons Parent added the maven-bundle plugin.

As far as I can tell, that was added in version 8.
It was certainly earlier than version 21.
Experimentation with CP versions shows that the warning message starts
with version 13, which coincides with updating from Apache pom v4 to
v7.

> The Warning you are seeing there is because it applies to all projects in a 
> multi-project build, some of which may be declared as a type other than 
> bundle or jar.  It also added the jar plugin to generate the test jar. This 
> required me to create a bogus MANIFEST.MF in the parent project since the 
> maven-bundle plugin doesn't generate a manifest.

No idea how to solve that; perhaps Dennis L can help?

> Ralph
>
>
> -
> 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] Release Commons VFS 2.0


On Aug 14, 2011, at 10:09 AM, sebb wrote:

> On 14 August 2011 18:03, Ralph Goers  wrote:
>> Thanks, Sebb. See below.
>> 
>> On Aug 14, 2011, at 9:50 AM, sebb wrote:
>> 
>>> On 14 August 2011 16:25, Ralph Goers  wrote:
 This is a vote to release Apache Commons VFS 2.0.
 
 Since the last candidate the package name was changed from vfs to vfs2. 
 Many of the Jira issues were reviewed and those that required a possibly 
 incompatible API change were addressed. Most instances of StringBuffer 
 were replaced with StringBuilder. Some synchronization issues were 
 addressed. Many javadoc and some checkstyle issues were addressed. The 
 filesystem documentation was improved to list file system capabilities.
 
 [ ] +1 release it
 [ ] +0 go ahead I don't care
 [X] -1 no, do not release it because...
>>> 
>>> Notice file still shows 2010.
>>> 
>>> It also refers to the (optional) Javamail library.
>>> Since that is not actually included in any of the archives, it should
>>> not be mentioned.
>>> 
>>> [If it were necessary to include a mention of JavaMail in NOTICE, then
>>> it would be necessary to include the corresponding license in LICENSE]
>>> 
>>> ==
>>> 
>>> Not a blocker, but a pain for checking the release:
>>> - lots of source files contain @version $Revision $. This uses local
>>> time, which means my checkout of SVN does not match the source
>>> archives.
>>> 
>>> There are some EOL issues:
>>> 
>>> svn ps svn:eol-style native README.txt
>>> svn ps svn:eol-style native RELEASE-NOTES.txt
>>> svn ps svn:eol-style native osgi/MANIFEST.MF
>>> svn ps svn:eol-style native src/changes/announcement.vm
>>> 
>>> I'm not convinced that the code really needs to be
>>> binary-incompatible, but that is a separate discussion.
>>> 
>>> However, the release notes ought to mention code is not source
>>> compatible with VFS 1.x and that the package name has changed.
>>> 
>>> mvn install produces some warnings:
>>> 
>>> [WARNING] Ignoring project type pom - supportedProjectTypes = [jar, bundle]
>>> [WARNING] DEPRECATED [tasks]: Use target instead
>> 
>> I can't fix the above two lines. They are caused by changes in 
>> commons-parent version 21.
> 
> Huh?
> 
> The second warning is caused by using  instead of ; you
> can fix that easily.

You are right. That was the antrun plugin.

> 
> Not sure about the first, but I would be suprised if it is anything to
> do with Commons Parent (except that later plugins may be more picky
> about obsolete syntax).

Commons Parent added the maven-bundle plugin. The Warning you are seeing there 
is because it applies to all projects in a multi-project build, some of which 
may be declared as a type other than bundle or jar.  It also added the jar 
plugin to generate the test jar. This required me to create a bogus MANIFEST.MF 
in the parent project since the maven-bundle plugin doesn't generate a manifest.

Ralph


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

Re: [Vote] Release Commons VFS 2.0

On 14 August 2011 18:03, Ralph Goers  wrote:
> Thanks, Sebb. See below.
>
> On Aug 14, 2011, at 9:50 AM, sebb wrote:
>
>> On 14 August 2011 16:25, Ralph Goers  wrote:
>>> This is a vote to release Apache Commons VFS 2.0.
>>>
>>> Since the last candidate the package name was changed from vfs to vfs2. 
>>> Many of the Jira issues were reviewed and those that required a possibly 
>>> incompatible API change were addressed. Most instances of StringBuffer were 
>>> replaced with StringBuilder. Some synchronization issues were addressed. 
>>> Many javadoc and some checkstyle issues were addressed. The filesystem 
>>> documentation was improved to list file system capabilities.
>>>
>>> [ ] +1 release it
>>> [ ] +0 go ahead I don't care
>>> [X] -1 no, do not release it because...
>>
>> Notice file still shows 2010.
>>
>> It also refers to the (optional) Javamail library.
>> Since that is not actually included in any of the archives, it should
>> not be mentioned.
>>
>> [If it were necessary to include a mention of JavaMail in NOTICE, then
>> it would be necessary to include the corresponding license in LICENSE]
>>
>> ==
>>
>> Not a blocker, but a pain for checking the release:
>> - lots of source files contain @version $Revision $. This uses local
>> time, which means my checkout of SVN does not match the source
>> archives.
>>
>> There are some EOL issues:
>>
>> svn ps svn:eol-style native README.txt
>> svn ps svn:eol-style native RELEASE-NOTES.txt
>> svn ps svn:eol-style native osgi/MANIFEST.MF
>> svn ps svn:eol-style native src/changes/announcement.vm
>>
>> I'm not convinced that the code really needs to be
>> binary-incompatible, but that is a separate discussion.
>>
>> However, the release notes ought to mention code is not source
>> compatible with VFS 1.x and that the package name has changed.
>>
>> mvn install produces some warnings:
>>
>> [WARNING] Ignoring project type pom - supportedProjectTypes = [jar, bundle]
>> [WARNING] DEPRECATED [tasks]: Use target instead
>
> I can't fix the above two lines. They are caused by changes in commons-parent 
> version 21.

Huh?

The second warning is caused by using  instead of ; you
can fix that easily.

Not sure about the first, but I would be suprised if it is anything to
do with Commons Parent (except that later plugins may be more picky
about obsolete syntax).

>> [WARNING] DEPRECATED [systemProperties]: Use systemPropertyVariables instead.
>>
>> also the error
>>
>> [ERROR] BUILD ERROR
>> [INFO] 
>> 
>> [INFO] Error assembling JAR
>>
>> Embedded error: Manifest file:
>> D:\RC\commons-vfs2-distribution-2.0-src-zip\commons-vfs-2.0\core\org.apache.maven.model.Model@718242
>> does not exist.
>
> I got a response from Dennis Lundberg. I forwarded that. It appears I will 
> have to create yet another module to put the common resources such as 
> checkstyle.xml. This, of course, is also going to end up being a new artifact 
> in the Maven repo. .
>
>>
>> This is a blocker.
>>
>> -
>> 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] Release Commons VFS 2.0

Thanks, Sebb. See below.

On Aug 14, 2011, at 9:50 AM, sebb wrote:

> On 14 August 2011 16:25, Ralph Goers  wrote:
>> This is a vote to release Apache Commons VFS 2.0.
>> 
>> Since the last candidate the package name was changed from vfs to vfs2. Many 
>> of the Jira issues were reviewed and those that required a possibly 
>> incompatible API change were addressed. Most instances of StringBuffer were 
>> replaced with StringBuilder. Some synchronization issues were addressed. 
>> Many javadoc and some checkstyle issues were addressed. The filesystem 
>> documentation was improved to list file system capabilities.
>> 
>> [ ] +1 release it
>> [ ] +0 go ahead I don't care
>> [X] -1 no, do not release it because...
> 
> Notice file still shows 2010.
> 
> It also refers to the (optional) Javamail library.
> Since that is not actually included in any of the archives, it should
> not be mentioned.
> 
> [If it were necessary to include a mention of JavaMail in NOTICE, then
> it would be necessary to include the corresponding license in LICENSE]
> 
> ==
> 
> Not a blocker, but a pain for checking the release:
> - lots of source files contain @version $Revision $. This uses local
> time, which means my checkout of SVN does not match the source
> archives.
> 
> There are some EOL issues:
> 
> svn ps svn:eol-style native README.txt
> svn ps svn:eol-style native RELEASE-NOTES.txt
> svn ps svn:eol-style native osgi/MANIFEST.MF
> svn ps svn:eol-style native src/changes/announcement.vm
> 
> I'm not convinced that the code really needs to be
> binary-incompatible, but that is a separate discussion.
> 
> However, the release notes ought to mention code is not source
> compatible with VFS 1.x and that the package name has changed.
> 
> mvn install produces some warnings:
> 
> [WARNING] Ignoring project type pom - supportedProjectTypes = [jar, bundle]
> [WARNING] DEPRECATED [tasks]: Use target instead

I can't fix the above two lines. They are caused by changes in commons-parent 
version 21.

> [WARNING] DEPRECATED [systemProperties]: Use systemPropertyVariables instead.
> 
> also the error
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Error assembling JAR
> 
> Embedded error: Manifest file:
> D:\RC\commons-vfs2-distribution-2.0-src-zip\commons-vfs-2.0\core\org.apache.maven.model.Model@718242
> does not exist.

I got a response from Dennis Lundberg. I forwarded that. It appears I will have 
to create yet another module to put the common resources such as 
checkstyle.xml. This, of course, is also going to end up being a new artifact 
in the Maven repo. .

> 
> This is a blocker.
> 
> -
> 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] Release Commons VFS 2.0

On 14 August 2011 16:25, Ralph Goers  wrote:
> This is a vote to release Apache Commons VFS 2.0.
>
> Since the last candidate the package name was changed from vfs to vfs2. Many 
> of the Jira issues were reviewed and those that required a possibly 
> incompatible API change were addressed. Most instances of StringBuffer were 
> replaced with StringBuilder. Some synchronization issues were addressed. Many 
> javadoc and some checkstyle issues were addressed. The filesystem 
> documentation was improved to list file system capabilities.
>
> [ ] +1 release it
> [ ] +0 go ahead I don't care
> [X] -1 no, do not release it because...

Notice file still shows 2010.

It also refers to the (optional) Javamail library.
Since that is not actually included in any of the archives, it should
not be mentioned.

[If it were necessary to include a mention of JavaMail in NOTICE, then
it would be necessary to include the corresponding license in LICENSE]

==

Not a blocker, but a pain for checking the release:
- lots of source files contain @version $Revision $. This uses local
time, which means my checkout of SVN does not match the source
archives.

There are some EOL issues:

svn ps svn:eol-style native README.txt
svn ps svn:eol-style native RELEASE-NOTES.txt
svn ps svn:eol-style native osgi/MANIFEST.MF
svn ps svn:eol-style native src/changes/announcement.vm

I'm not convinced that the code really needs to be
binary-incompatible, but that is a separate discussion.

However, the release notes ought to mention code is not source
compatible with VFS 1.x and that the package name has changed.

mvn install produces some warnings:

[WARNING] Ignoring project type pom - supportedProjectTypes = [jar, bundle]
[WARNING] DEPRECATED [tasks]: Use target instead
[WARNING] DEPRECATED [systemProperties]: Use systemPropertyVariables instead.

also the error

[ERROR] BUILD ERROR
[INFO] 
[INFO] Error assembling JAR

Embedded error: Manifest file:
D:\RC\commons-vfs2-distribution-2.0-src-zip\commons-vfs-2.0\core\org.apache.maven.model.Model@718242
does not exist.

This is a blocker.

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

Re: [Vote] Release Commons VFS 2.0

2011-08-14 Thread Gary Gregory

My mistake then.

Gary

On Aug 14, 2011, at 12:28, Ralph Goers  wrote:

> Why?  The source has a dist directory with a pom.xml in it.  I thought the 
> source zip was supposed to capture what was tagged?
>
> Ralph
>
> On Aug 14, 2011, at 9:09 AM, Gary Gregory wrote:
>
>> FWIW, the source zip has a dist folder with a pom.xml in it. Not a
>> blocker but should be fixed.
>>
>> Gary
>>
>> On Sun, Aug 14, 2011 at 11:25 AM, Ralph Goers
>>  wrote:
>>> This is a vote to release Apache Commons VFS 2.0.
>>>
>>> Since the last candidate the package name was changed from vfs to vfs2. 
>>> Many of the Jira issues were reviewed and those that required a possibly 
>>> incompatible API change were addressed. Most instances of StringBuffer were 
>>> replaced with StringBuilder. Some synchronization issues were addressed. 
>>> Many javadoc and some checkstyle issues were addressed. The filesystem 
>>> documentation was improved to list file system capabilities.
>>>
>>> [ ] +1 release it
>>> [ ] +0 go ahead I don't care
>>> [ ] -1 no, do not release it because...
>>>
>>> Ralph
>>>
>>> tag: 
>>> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/
>>>   (revision 1157490).
>>>
>>> site: http://people.apache.org/~rgoers/commons-vfs/index.html
>>>
>>> The following artifacts have been staged to the org.apache.commons-035 
>>> (u:rgoers, a:99.180.69.21) repository.
>>>
>>> archetype-catalog.xml
>>> commons-vfs2-examples-2.0-javadoc.jar
>>> commons-vfs2-examples-2.0-sources.jar.asc
>>> commons-vfs2-examples-2.0.pom
>>> commons-vfs2-examples-2.0-site.xml.asc
>>> commons-vfs2-examples-2.0-tests.jar
>>> commons-vfs2-examples-2.0-tests.jar.asc
>>> commons-vfs2-examples-2.0.jar.asc
>>> commons-vfs2-examples-2.0.pom.asc
>>> commons-vfs2-examples-2.0-site.xml
>>> commons-vfs2-examples-2.0-javadoc.jar.asc
>>> commons-vfs2-examples-2.0.jar
>>> commons-vfs2-examples-2.0-sources.jar
>>> commons-vfs2-project-2.0-tests.jar.asc
>>> commons-vfs2-project-2.0-site.xml
>>> commons-vfs2-project-2.0.pom.asc
>>> commons-vfs2-project-2.0-tests.jar
>>> commons-vfs2-project-2.0.pom
>>> commons-vfs2-project-2.0-site.xml.asc
>>> commons-vfs2-sandbox-2.0.pom.asc
>>> commons-vfs2-sandbox-2.0-sources.jar.asc
>>> commons-vfs2-sandbox-2.0-test-sources.jar.asc
>>> commons-vfs2-sandbox-2.0.jar
>>> commons-vfs2-sandbox-2.0-javadoc.jar
>>> commons-vfs2-sandbox-2.0-site.xml.asc
>>> commons-vfs2-sandbox-2.0-test-sources.jar
>>> commons-vfs2-sandbox-2.0.jar.asc
>>> commons-vfs2-sandbox-2.0-site.xml
>>> commons-vfs2-sandbox-2.0-sources.jar
>>> commons-vfs2-sandbox-2.0-javadoc.jar.asc
>>> commons-vfs2-sandbox-2.0-tests.jar.asc
>>> commons-vfs2-sandbox-2.0-tests.jar
>>> commons-vfs2-sandbox-2.0.pom
>>> commons-vfs2-distribution-2.0-src.tar.gz
>>> commons-vfs2-distribution-2.0-src.tar.gz.asc
>>> commons-vfs2-distribution-2.0-src.zip.asc
>>> commons-vfs2-distribution-2.0.pom.asc
>>> commons-vfs2-distribution-2.0-bin.zip
>>> commons-vfs2-distribution-2.0-bin.tar.gz
>>> commons-vfs2-distribution-2.0-tests.jar.asc
>>> commons-vfs2-distribution-2.0-bin.tar.gz.asc
>>> commons-vfs2-distribution-2.0-src.zip
>>> commons-vfs2-distribution-2.0-tests.jar
>>> commons-vfs2-distribution-2.0-bin.zip.asc
>>> commons-vfs2-distribution-2.0.pom
>>> commons-vfs2-2.0.pom.asc
>>> commons-vfs2-2.0-javadoc.jar
>>> commons-vfs2-2.0-tests.jar.asc
>>> commons-vfs2-2.0-tests.jar
>>> commons-vfs2-2.0.pom
>>> commons-vfs2-2.0.jar
>>> commons-vfs2-2.0-sources.jar.asc
>>> commons-vfs2-2.0-test-sources.jar.asc
>>> commons-vfs2-2.0.jar.asc
>>> commons-vfs2-2.0-site.xml
>>> commons-vfs2-2.0-sources.jar
>>> commons-vfs2-2.0-test-sources.jar
>>> commons-vfs2-2.0-site.xml.asc
>>> commons-vfs2-2.0-javadoc.jar.asc
>>
>>
>>
>> --
>> Thank you,
>> Gary
>>
>> http://garygregory.wordpress.com/
>> http://garygregory.com/
>> http://people.apache.org/~ggregory/
>> 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
>

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

Re: [Vote] Release Commons VFS 2.0

Interesting. That is the same error that Continuum reported. I have no idea 
what it is and can't seem reproduce it on my MacBook. I will give it a try on 
Ubuntu.

The surefire report will look strange. This is a multi-module project. You need 
to go to the "Core" component to see real reports.

Ralph

On Aug 14, 2011, at 9:22 AM, Oliver Heger wrote:

> When building the source distribution I get the following error:
> 
> Tests run: 975, Failures: 0, Errors: 0, Skipped: 0
> 
> [INFO] [jar:jar {execution: default-jar}]
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Error assembling JAR
> 
> Embedded error: Manifest file: 
> D:\data\projects\OpenSource\vfs-release\commons-v
> fs-2.0-src\core\org.apache.maven.model.Model@ec4a87 does not exist.
> 
> Platform info is below:
> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.5.0_21
> Java home: C:\Program Files\Java\jdk1.5.0_21\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7" version: "6.1" arch: "x86" Family: "windows"
> 
> In addition, I found some other (minor) problems:
> - Both the binary and the source distribution are deflated in a directory 
> commons-vfs-2.0. It is common habit to have a different directory for the 
> source distribution (ending of -src).
> - The copyright date in NOTICE.txt is still 2010.
> - In the binary distribution some jars (I assume all javadocs) are missing 
> the license and NOTICE in their META-INF folder.
> - On the site the surefire report looks strange. It seems that no tests have 
> been executed.
> 
> Oliver
> 
> Am 14.08.2011 17:25, schrieb Ralph Goers:
>> This is a vote to release Apache Commons VFS 2.0.
>> 
>> Since the last candidate the package name was changed from vfs to vfs2. Many 
>> of the Jira issues were reviewed and those that required a possibly 
>> incompatible API change were addressed. Most instances of StringBuffer were 
>> replaced with StringBuilder. Some synchronization issues were addressed. 
>> Many javadoc and some checkstyle issues were addressed. The filesystem 
>> documentation was improved to list file system capabilities.
>> 
>> [ ] +1 release it
>> [ ] +0 go ahead I don't care
>> [ ] -1 no, do not release it because...
>> 
>> Ralph
>> 
>> tag: 
>> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/
>>   (revision 1157490).
>> 
>> site: http://people.apache.org/~rgoers/commons-vfs/index.html
>> 
>> The following artifacts have been staged to the org.apache.commons-035 
>> (u:rgoers, a:99.180.69.21) repository.
>> 
>> archetype-catalog.xml
>> commons-vfs2-examples-2.0-javadoc.jar
>> commons-vfs2-examples-2.0-sources.jar.asc
>> commons-vfs2-examples-2.0.pom
>> commons-vfs2-examples-2.0-site.xml.asc
>> commons-vfs2-examples-2.0-tests.jar
>> commons-vfs2-examples-2.0-tests.jar.asc
>> commons-vfs2-examples-2.0.jar.asc
>> commons-vfs2-examples-2.0.pom.asc
>> commons-vfs2-examples-2.0-site.xml
>> commons-vfs2-examples-2.0-javadoc.jar.asc
>> commons-vfs2-examples-2.0.jar
>> commons-vfs2-examples-2.0-sources.jar
>> commons-vfs2-project-2.0-tests.jar.asc
>> commons-vfs2-project-2.0-site.xml
>> commons-vfs2-project-2.0.pom.asc
>> commons-vfs2-project-2.0-tests.jar
>> commons-vfs2-project-2.0.pom
>> commons-vfs2-project-2.0-site.xml.asc
>> commons-vfs2-sandbox-2.0.pom.asc
>> commons-vfs2-sandbox-2.0-sources.jar.asc
>> commons-vfs2-sandbox-2.0-test-sources.jar.asc
>> commons-vfs2-sandbox-2.0.jar
>> commons-vfs2-sandbox-2.0-javadoc.jar
>> commons-vfs2-sandbox-2.0-site.xml.asc
>> commons-vfs2-sandbox-2.0-test-sources.jar
>> commons-vfs2-sandbox-2.0.jar.asc
>> commons-vfs2-sandbox-2.0-site.xml
>> commons-vfs2-sandbox-2.0-sources.jar
>> commons-vfs2-sandbox-2.0-javadoc.jar.asc
>> commons-vfs2-sandbox-2.0-tests.jar.asc
>> commons-vfs2-sandbox-2.0-tests.jar
>> commons-vfs2-sandbox-2.0.pom
>> commons-vfs2-distribution-2.0-src.tar.gz
>> commons-vfs2-distribution-2.0-src.tar.gz.asc
>> commons-vfs2-distribution-2.0-src.zip.asc
>> commons-vfs2-distribution-2.0.pom.asc
>> commons-vfs2-distribution-2.0-bin.zip
>> commons-vfs2-distribution-2.0-bin.tar.gz
>> commons-vfs2-distribution-2.0-tests.jar.asc
>> commons-vfs2-distribution-2.0-bin.tar.gz.asc
>> commons-vfs2-distribution-2.0-src.zip
>> commons-vfs2-distribution-2.0-tests.jar
>> commons-vfs2-distribution-2.0-bin.zip.asc
>> commons-vfs2-distribution-2.0.pom
>> commons-vfs2-2.0.pom.asc
>> commons-vfs2-2.0-javadoc.jar
>> commons-vfs2-2.0-tests.jar.asc
>> commons-vfs2-2.0-tests.jar
>> commons-vfs2-2.0.pom
>> commons-vfs2-2.0.jar
>> commons-vfs2-2.0-sources.jar.asc
>> commons-vfs2-2.0-test-sources.jar.asc
>> commons-vfs2-2.0.jar.asc
>> commons-vfs2-2.0-site.xml
>> commons-vfs2-2.0-sources.jar
>> commons-vfs2-2.0-test-sources.jar
>> commons-vfs2-2.0-site.xml.asc
>> commons-vfs2-2.0-javadoc.jar.asc
> 
> 
>

Re: [Vote] Release Commons VFS 2.0

Why?  The source has a dist directory with a pom.xml in it.  I thought the 
source zip was supposed to capture what was tagged?

Ralph

On Aug 14, 2011, at 9:09 AM, Gary Gregory wrote:

> FWIW, the source zip has a dist folder with a pom.xml in it. Not a
> blocker but should be fixed.
> 
> Gary
> 
> On Sun, Aug 14, 2011 at 11:25 AM, Ralph Goers
>  wrote:
>> This is a vote to release Apache Commons VFS 2.0.
>> 
>> Since the last candidate the package name was changed from vfs to vfs2. Many 
>> of the Jira issues were reviewed and those that required a possibly 
>> incompatible API change were addressed. Most instances of StringBuffer were 
>> replaced with StringBuilder. Some synchronization issues were addressed. 
>> Many javadoc and some checkstyle issues were addressed. The filesystem 
>> documentation was improved to list file system capabilities.
>> 
>> [ ] +1 release it
>> [ ] +0 go ahead I don't care
>> [ ] -1 no, do not release it because...
>> 
>> Ralph
>> 
>> tag: 
>> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/
>>   (revision 1157490).
>> 
>> site: http://people.apache.org/~rgoers/commons-vfs/index.html
>> 
>> The following artifacts have been staged to the org.apache.commons-035 
>> (u:rgoers, a:99.180.69.21) repository.
>> 
>> archetype-catalog.xml
>> commons-vfs2-examples-2.0-javadoc.jar
>> commons-vfs2-examples-2.0-sources.jar.asc
>> commons-vfs2-examples-2.0.pom
>> commons-vfs2-examples-2.0-site.xml.asc
>> commons-vfs2-examples-2.0-tests.jar
>> commons-vfs2-examples-2.0-tests.jar.asc
>> commons-vfs2-examples-2.0.jar.asc
>> commons-vfs2-examples-2.0.pom.asc
>> commons-vfs2-examples-2.0-site.xml
>> commons-vfs2-examples-2.0-javadoc.jar.asc
>> commons-vfs2-examples-2.0.jar
>> commons-vfs2-examples-2.0-sources.jar
>> commons-vfs2-project-2.0-tests.jar.asc
>> commons-vfs2-project-2.0-site.xml
>> commons-vfs2-project-2.0.pom.asc
>> commons-vfs2-project-2.0-tests.jar
>> commons-vfs2-project-2.0.pom
>> commons-vfs2-project-2.0-site.xml.asc
>> commons-vfs2-sandbox-2.0.pom.asc
>> commons-vfs2-sandbox-2.0-sources.jar.asc
>> commons-vfs2-sandbox-2.0-test-sources.jar.asc
>> commons-vfs2-sandbox-2.0.jar
>> commons-vfs2-sandbox-2.0-javadoc.jar
>> commons-vfs2-sandbox-2.0-site.xml.asc
>> commons-vfs2-sandbox-2.0-test-sources.jar
>> commons-vfs2-sandbox-2.0.jar.asc
>> commons-vfs2-sandbox-2.0-site.xml
>> commons-vfs2-sandbox-2.0-sources.jar
>> commons-vfs2-sandbox-2.0-javadoc.jar.asc
>> commons-vfs2-sandbox-2.0-tests.jar.asc
>> commons-vfs2-sandbox-2.0-tests.jar
>> commons-vfs2-sandbox-2.0.pom
>> commons-vfs2-distribution-2.0-src.tar.gz
>> commons-vfs2-distribution-2.0-src.tar.gz.asc
>> commons-vfs2-distribution-2.0-src.zip.asc
>> commons-vfs2-distribution-2.0.pom.asc
>> commons-vfs2-distribution-2.0-bin.zip
>> commons-vfs2-distribution-2.0-bin.tar.gz
>> commons-vfs2-distribution-2.0-tests.jar.asc
>> commons-vfs2-distribution-2.0-bin.tar.gz.asc
>> commons-vfs2-distribution-2.0-src.zip
>> commons-vfs2-distribution-2.0-tests.jar
>> commons-vfs2-distribution-2.0-bin.zip.asc
>> commons-vfs2-distribution-2.0.pom
>> commons-vfs2-2.0.pom.asc
>> commons-vfs2-2.0-javadoc.jar
>> commons-vfs2-2.0-tests.jar.asc
>> commons-vfs2-2.0-tests.jar
>> commons-vfs2-2.0.pom
>> commons-vfs2-2.0.jar
>> commons-vfs2-2.0-sources.jar.asc
>> commons-vfs2-2.0-test-sources.jar.asc
>> commons-vfs2-2.0.jar.asc
>> commons-vfs2-2.0-site.xml
>> commons-vfs2-2.0-sources.jar
>> commons-vfs2-2.0-test-sources.jar
>> commons-vfs2-2.0-site.xml.asc
>> commons-vfs2-2.0-javadoc.jar.asc
> 
> 
> 
> -- 
> Thank you,
> Gary
> 
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> 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

Re: [Vote] Release Commons VFS 2.0

On 14 August 2011 17:09, Gary Gregory  wrote:
> FWIW, the source zip has a dist folder with a pom.xml in it. Not a
> blocker but should be fixed.

I think that's intentional - it's the distribution module, which is also in SVN.

> Gary
>
> On Sun, Aug 14, 2011 at 11:25 AM, Ralph Goers
>  wrote:
>> This is a vote to release Apache Commons VFS 2.0.
>>
>> Since the last candidate the package name was changed from vfs to vfs2. Many 
>> of the Jira issues were reviewed and those that required a possibly 
>> incompatible API change were addressed. Most instances of StringBuffer were 
>> replaced with StringBuilder. Some synchronization issues were addressed. 
>> Many javadoc and some checkstyle issues were addressed. The filesystem 
>> documentation was improved to list file system capabilities.
>>
>> [ ] +1 release it
>> [ ] +0 go ahead I don't care
>> [ ] -1 no, do not release it because...
>>
>> Ralph
>>
>> tag: 
>> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/
>>   (revision 1157490).
>>
>> site: http://people.apache.org/~rgoers/commons-vfs/index.html
>>
>> The following artifacts have been staged to the org.apache.commons-035 
>> (u:rgoers, a:99.180.69.21) repository.
>>
>> archetype-catalog.xml
>> commons-vfs2-examples-2.0-javadoc.jar
>> commons-vfs2-examples-2.0-sources.jar.asc
>> commons-vfs2-examples-2.0.pom
>> commons-vfs2-examples-2.0-site.xml.asc
>> commons-vfs2-examples-2.0-tests.jar
>> commons-vfs2-examples-2.0-tests.jar.asc
>> commons-vfs2-examples-2.0.jar.asc
>> commons-vfs2-examples-2.0.pom.asc
>> commons-vfs2-examples-2.0-site.xml
>> commons-vfs2-examples-2.0-javadoc.jar.asc
>> commons-vfs2-examples-2.0.jar
>> commons-vfs2-examples-2.0-sources.jar
>> commons-vfs2-project-2.0-tests.jar.asc
>> commons-vfs2-project-2.0-site.xml
>> commons-vfs2-project-2.0.pom.asc
>> commons-vfs2-project-2.0-tests.jar
>> commons-vfs2-project-2.0.pom
>> commons-vfs2-project-2.0-site.xml.asc
>> commons-vfs2-sandbox-2.0.pom.asc
>> commons-vfs2-sandbox-2.0-sources.jar.asc
>> commons-vfs2-sandbox-2.0-test-sources.jar.asc
>> commons-vfs2-sandbox-2.0.jar
>> commons-vfs2-sandbox-2.0-javadoc.jar
>> commons-vfs2-sandbox-2.0-site.xml.asc
>> commons-vfs2-sandbox-2.0-test-sources.jar
>> commons-vfs2-sandbox-2.0.jar.asc
>> commons-vfs2-sandbox-2.0-site.xml
>> commons-vfs2-sandbox-2.0-sources.jar
>> commons-vfs2-sandbox-2.0-javadoc.jar.asc
>> commons-vfs2-sandbox-2.0-tests.jar.asc
>> commons-vfs2-sandbox-2.0-tests.jar
>> commons-vfs2-sandbox-2.0.pom
>> commons-vfs2-distribution-2.0-src.tar.gz
>> commons-vfs2-distribution-2.0-src.tar.gz.asc
>> commons-vfs2-distribution-2.0-src.zip.asc
>> commons-vfs2-distribution-2.0.pom.asc
>> commons-vfs2-distribution-2.0-bin.zip
>> commons-vfs2-distribution-2.0-bin.tar.gz
>> commons-vfs2-distribution-2.0-tests.jar.asc
>> commons-vfs2-distribution-2.0-bin.tar.gz.asc
>> commons-vfs2-distribution-2.0-src.zip
>> commons-vfs2-distribution-2.0-tests.jar
>> commons-vfs2-distribution-2.0-bin.zip.asc
>> commons-vfs2-distribution-2.0.pom
>> commons-vfs2-2.0.pom.asc
>> commons-vfs2-2.0-javadoc.jar
>> commons-vfs2-2.0-tests.jar.asc
>> commons-vfs2-2.0-tests.jar
>> commons-vfs2-2.0.pom
>> commons-vfs2-2.0.jar
>> commons-vfs2-2.0-sources.jar.asc
>> commons-vfs2-2.0-test-sources.jar.asc
>> commons-vfs2-2.0.jar.asc
>> commons-vfs2-2.0-site.xml
>> commons-vfs2-2.0-sources.jar
>> commons-vfs2-2.0-test-sources.jar
>> commons-vfs2-2.0-site.xml.asc
>> commons-vfs2-2.0-javadoc.jar.asc
>
>
>
> --
> Thank you,
> Gary
>
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> 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

Re: [Vote] Release Commons VFS 2.0

2011-08-14 Thread Oliver Heger


When building the source distribution I get the following error:

Tests run: 975, Failures: 0, Errors: 0, Skipped: 0

[INFO] [jar:jar {execution: default-jar}]
[INFO] 


[ERROR] BUILD ERROR
[INFO] 


[INFO] Error assembling JAR

Embedded error: Manifest file: 
D:\data\projects\OpenSource\vfs-release\commons-v

fs-2.0-src\core\org.apache.maven.model.Model@ec4a87 does not exist.

Platform info is below:
Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.5.0_21
Java home: C:\Program Files\Java\jdk1.5.0_21\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 7" version: "6.1" arch: "x86" Family: "windows"

In addition, I found some other (minor) problems:
- Both the binary and the source distribution are deflated in a 
directory commons-vfs-2.0. It is common habit to have a different 
directory for the source distribution (ending of -src).

- The copyright date in NOTICE.txt is still 2010.
- In the binary distribution some jars (I assume all javadocs) are 
missing the license and NOTICE in their META-INF folder.
- On the site the surefire report looks strange. It seems that no tests 
have been executed.


Oliver

Am 14.08.2011 17:25, schrieb Ralph Goers:

This is a vote to release Apache Commons VFS 2.0.

Since the last candidate the package name was changed from vfs to vfs2. Many of 
the Jira issues were reviewed and those that required a possibly incompatible 
API change were addressed. Most instances of StringBuffer were replaced with 
StringBuilder. Some synchronization issues were addressed. Many javadoc and 
some checkstyle issues were addressed. The filesystem documentation was 
improved to list file system capabilities.

[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because...

Ralph

tag: 
https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/
  (revision 1157490).

site: http://people.apache.org/~rgoers/commons-vfs/index.html

The following artifacts have been staged to the org.apache.commons-035 
(u:rgoers, a:99.180.69.21) repository.

archetype-catalog.xml
commons-vfs2-examples-2.0-javadoc.jar
commons-vfs2-examples-2.0-sources.jar.asc
commons-vfs2-examples-2.0.pom
commons-vfs2-examples-2.0-site.xml.asc
commons-vfs2-examples-2.0-tests.jar
commons-vfs2-examples-2.0-tests.jar.asc
commons-vfs2-examples-2.0.jar.asc
commons-vfs2-examples-2.0.pom.asc
commons-vfs2-examples-2.0-site.xml
commons-vfs2-examples-2.0-javadoc.jar.asc
commons-vfs2-examples-2.0.jar
commons-vfs2-examples-2.0-sources.jar
commons-vfs2-project-2.0-tests.jar.asc
commons-vfs2-project-2.0-site.xml
commons-vfs2-project-2.0.pom.asc
commons-vfs2-project-2.0-tests.jar
commons-vfs2-project-2.0.pom
commons-vfs2-project-2.0-site.xml.asc
commons-vfs2-sandbox-2.0.pom.asc
commons-vfs2-sandbox-2.0-sources.jar.asc
commons-vfs2-sandbox-2.0-test-sources.jar.asc
commons-vfs2-sandbox-2.0.jar
commons-vfs2-sandbox-2.0-javadoc.jar
commons-vfs2-sandbox-2.0-site.xml.asc
commons-vfs2-sandbox-2.0-test-sources.jar
commons-vfs2-sandbox-2.0.jar.asc
commons-vfs2-sandbox-2.0-site.xml
commons-vfs2-sandbox-2.0-sources.jar
commons-vfs2-sandbox-2.0-javadoc.jar.asc
commons-vfs2-sandbox-2.0-tests.jar.asc
commons-vfs2-sandbox-2.0-tests.jar
commons-vfs2-sandbox-2.0.pom
commons-vfs2-distribution-2.0-src.tar.gz
commons-vfs2-distribution-2.0-src.tar.gz.asc
commons-vfs2-distribution-2.0-src.zip.asc
commons-vfs2-distribution-2.0.pom.asc
commons-vfs2-distribution-2.0-bin.zip
commons-vfs2-distribution-2.0-bin.tar.gz
commons-vfs2-distribution-2.0-tests.jar.asc
commons-vfs2-distribution-2.0-bin.tar.gz.asc
commons-vfs2-distribution-2.0-src.zip
commons-vfs2-distribution-2.0-tests.jar
commons-vfs2-distribution-2.0-bin.zip.asc
commons-vfs2-distribution-2.0.pom
commons-vfs2-2.0.pom.asc
commons-vfs2-2.0-javadoc.jar
commons-vfs2-2.0-tests.jar.asc
commons-vfs2-2.0-tests.jar
commons-vfs2-2.0.pom
commons-vfs2-2.0.jar
commons-vfs2-2.0-sources.jar.asc
commons-vfs2-2.0-test-sources.jar.asc
commons-vfs2-2.0.jar.asc
commons-vfs2-2.0-site.xml
commons-vfs2-2.0-sources.jar
commons-vfs2-2.0-test-sources.jar
commons-vfs2-2.0-site.xml.asc
commons-vfs2-2.0-javadoc.jar.asc



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

Re: [Vote] Release Commons VFS 2.0

Yes.

On Aug 14, 2011, at 9:07 AM, sebb wrote:

> On 14 August 2011 16:25, Ralph Goers  wrote:
>> This is a vote to release Apache Commons VFS 2.0.
>> 
>> Since the last candidate the package name was changed from vfs to vfs2. Many 
>> of the Jira issues were reviewed and those that required a possibly 
>> incompatible API change were addressed. Most instances of StringBuffer were 
>> replaced with StringBuilder. Some synchronization issues were addressed. 
>> Many javadoc and some checkstyle issues were addressed. The filesystem 
>> documentation was improved to list file system capabilities.
>> 
>> [ ] +1 release it
>> [ ] +0 go ahead I don't care
>> [ ] -1 no, do not release it because...
>> 
>> Ralph
>> 
>> tag: 
>> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/
>>   (revision 1157490).
>> 
>> site: http://people.apache.org/~rgoers/commons-vfs/index.html
>> 
>> The following artifacts have been staged to the org.apache.commons-035 
>> (u:rgoers, a:99.180.69.21) repository.
> 
> It would be helpful to know the URL(s) ...
> 
> I found:
> 
> https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2/
> https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-distribution/
> https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-examples/
> https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-project/
> https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-sandbox/
> 
> Are these all part of the release vote?
> 
>> archetype-catalog.xml
>> commons-vfs2-examples-2.0-javadoc.jar
>> commons-vfs2-examples-2.0-sources.jar.asc
>> commons-vfs2-examples-2.0.pom
>> commons-vfs2-examples-2.0-site.xml.asc
>> commons-vfs2-examples-2.0-tests.jar
>> commons-vfs2-examples-2.0-tests.jar.asc
>> commons-vfs2-examples-2.0.jar.asc
>> commons-vfs2-examples-2.0.pom.asc
>> commons-vfs2-examples-2.0-site.xml
>> commons-vfs2-examples-2.0-javadoc.jar.asc
>> commons-vfs2-examples-2.0.jar
>> commons-vfs2-examples-2.0-sources.jar
>> commons-vfs2-project-2.0-tests.jar.asc
>> commons-vfs2-project-2.0-site.xml
>> commons-vfs2-project-2.0.pom.asc
>> commons-vfs2-project-2.0-tests.jar
>> commons-vfs2-project-2.0.pom
>> commons-vfs2-project-2.0-site.xml.asc
>> commons-vfs2-sandbox-2.0.pom.asc
>> commons-vfs2-sandbox-2.0-sources.jar.asc
>> commons-vfs2-sandbox-2.0-test-sources.jar.asc
>> commons-vfs2-sandbox-2.0.jar
>> commons-vfs2-sandbox-2.0-javadoc.jar
>> commons-vfs2-sandbox-2.0-site.xml.asc
>> commons-vfs2-sandbox-2.0-test-sources.jar
>> commons-vfs2-sandbox-2.0.jar.asc
>> commons-vfs2-sandbox-2.0-site.xml
>> commons-vfs2-sandbox-2.0-sources.jar
>> commons-vfs2-sandbox-2.0-javadoc.jar.asc
>> commons-vfs2-sandbox-2.0-tests.jar.asc
>> commons-vfs2-sandbox-2.0-tests.jar
>> commons-vfs2-sandbox-2.0.pom
>> commons-vfs2-distribution-2.0-src.tar.gz
>> commons-vfs2-distribution-2.0-src.tar.gz.asc
>> commons-vfs2-distribution-2.0-src.zip.asc
>> commons-vfs2-distribution-2.0.pom.asc
>> commons-vfs2-distribution-2.0-bin.zip
>> commons-vfs2-distribution-2.0-bin.tar.gz
>> commons-vfs2-distribution-2.0-tests.jar.asc
>> commons-vfs2-distribution-2.0-bin.tar.gz.asc
>> commons-vfs2-distribution-2.0-src.zip
>> commons-vfs2-distribution-2.0-tests.jar
>> commons-vfs2-distribution-2.0-bin.zip.asc
>> commons-vfs2-distribution-2.0.pom
>> commons-vfs2-2.0.pom.asc
>> commons-vfs2-2.0-javadoc.jar
>> commons-vfs2-2.0-tests.jar.asc
>> commons-vfs2-2.0-tests.jar
>> commons-vfs2-2.0.pom
>> commons-vfs2-2.0.jar
>> commons-vfs2-2.0-sources.jar.asc
>> commons-vfs2-2.0-test-sources.jar.asc
>> commons-vfs2-2.0.jar.asc
>> commons-vfs2-2.0-site.xml
>> commons-vfs2-2.0-sources.jar
>> commons-vfs2-2.0-test-sources.jar
>> commons-vfs2-2.0-site.xml.asc
>> commons-vfs2-2.0-javadoc.jar.asc
> 
> -
> 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] Release Commons VFS 2.0

2011-08-14 Thread Gary Gregory

FWIW, the source zip has a dist folder with a pom.xml in it. Not a
blocker but should be fixed.

Gary

On Sun, Aug 14, 2011 at 11:25 AM, Ralph Goers
 wrote:
> This is a vote to release Apache Commons VFS 2.0.
>
> Since the last candidate the package name was changed from vfs to vfs2. Many 
> of the Jira issues were reviewed and those that required a possibly 
> incompatible API change were addressed. Most instances of StringBuffer were 
> replaced with StringBuilder. Some synchronization issues were addressed. Many 
> javadoc and some checkstyle issues were addressed. The filesystem 
> documentation was improved to list file system capabilities.
>
> [ ] +1 release it
> [ ] +0 go ahead I don't care
> [ ] -1 no, do not release it because...
>
> Ralph
>
> tag: 
> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/
>   (revision 1157490).
>
> site: http://people.apache.org/~rgoers/commons-vfs/index.html
>
> The following artifacts have been staged to the org.apache.commons-035 
> (u:rgoers, a:99.180.69.21) repository.
>
> archetype-catalog.xml
> commons-vfs2-examples-2.0-javadoc.jar
> commons-vfs2-examples-2.0-sources.jar.asc
> commons-vfs2-examples-2.0.pom
> commons-vfs2-examples-2.0-site.xml.asc
> commons-vfs2-examples-2.0-tests.jar
> commons-vfs2-examples-2.0-tests.jar.asc
> commons-vfs2-examples-2.0.jar.asc
> commons-vfs2-examples-2.0.pom.asc
> commons-vfs2-examples-2.0-site.xml
> commons-vfs2-examples-2.0-javadoc.jar.asc
> commons-vfs2-examples-2.0.jar
> commons-vfs2-examples-2.0-sources.jar
> commons-vfs2-project-2.0-tests.jar.asc
> commons-vfs2-project-2.0-site.xml
> commons-vfs2-project-2.0.pom.asc
> commons-vfs2-project-2.0-tests.jar
> commons-vfs2-project-2.0.pom
> commons-vfs2-project-2.0-site.xml.asc
> commons-vfs2-sandbox-2.0.pom.asc
> commons-vfs2-sandbox-2.0-sources.jar.asc
> commons-vfs2-sandbox-2.0-test-sources.jar.asc
> commons-vfs2-sandbox-2.0.jar
> commons-vfs2-sandbox-2.0-javadoc.jar
> commons-vfs2-sandbox-2.0-site.xml.asc
> commons-vfs2-sandbox-2.0-test-sources.jar
> commons-vfs2-sandbox-2.0.jar.asc
> commons-vfs2-sandbox-2.0-site.xml
> commons-vfs2-sandbox-2.0-sources.jar
> commons-vfs2-sandbox-2.0-javadoc.jar.asc
> commons-vfs2-sandbox-2.0-tests.jar.asc
> commons-vfs2-sandbox-2.0-tests.jar
> commons-vfs2-sandbox-2.0.pom
> commons-vfs2-distribution-2.0-src.tar.gz
> commons-vfs2-distribution-2.0-src.tar.gz.asc
> commons-vfs2-distribution-2.0-src.zip.asc
> commons-vfs2-distribution-2.0.pom.asc
> commons-vfs2-distribution-2.0-bin.zip
> commons-vfs2-distribution-2.0-bin.tar.gz
> commons-vfs2-distribution-2.0-tests.jar.asc
> commons-vfs2-distribution-2.0-bin.tar.gz.asc
> commons-vfs2-distribution-2.0-src.zip
> commons-vfs2-distribution-2.0-tests.jar
> commons-vfs2-distribution-2.0-bin.zip.asc
> commons-vfs2-distribution-2.0.pom
> commons-vfs2-2.0.pom.asc
> commons-vfs2-2.0-javadoc.jar
> commons-vfs2-2.0-tests.jar.asc
> commons-vfs2-2.0-tests.jar
> commons-vfs2-2.0.pom
> commons-vfs2-2.0.jar
> commons-vfs2-2.0-sources.jar.asc
> commons-vfs2-2.0-test-sources.jar.asc
> commons-vfs2-2.0.jar.asc
> commons-vfs2-2.0-site.xml
> commons-vfs2-2.0-sources.jar
> commons-vfs2-2.0-test-sources.jar
> commons-vfs2-2.0-site.xml.asc
> commons-vfs2-2.0-javadoc.jar.asc



-- 
Thank you,
Gary

http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory

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

Re: [Vote] Release Commons VFS 2.0

On 14 August 2011 16:25, Ralph Goers  wrote:
> This is a vote to release Apache Commons VFS 2.0.
>
> Since the last candidate the package name was changed from vfs to vfs2. Many 
> of the Jira issues were reviewed and those that required a possibly 
> incompatible API change were addressed. Most instances of StringBuffer were 
> replaced with StringBuilder. Some synchronization issues were addressed. Many 
> javadoc and some checkstyle issues were addressed. The filesystem 
> documentation was improved to list file system capabilities.
>
> [ ] +1 release it
> [ ] +0 go ahead I don't care
> [ ] -1 no, do not release it because...
>
> Ralph
>
> tag: 
> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/
>   (revision 1157490).
>
> site: http://people.apache.org/~rgoers/commons-vfs/index.html
>
> The following artifacts have been staged to the org.apache.commons-035 
> (u:rgoers, a:99.180.69.21) repository.

It would be helpful to know the URL(s) ...

I found:

https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2/
https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-distribution/
https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-examples/
https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-project/
https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-sandbox/

Are these all part of the release vote?

> archetype-catalog.xml
> commons-vfs2-examples-2.0-javadoc.jar
> commons-vfs2-examples-2.0-sources.jar.asc
> commons-vfs2-examples-2.0.pom
> commons-vfs2-examples-2.0-site.xml.asc
> commons-vfs2-examples-2.0-tests.jar
> commons-vfs2-examples-2.0-tests.jar.asc
> commons-vfs2-examples-2.0.jar.asc
> commons-vfs2-examples-2.0.pom.asc
> commons-vfs2-examples-2.0-site.xml
> commons-vfs2-examples-2.0-javadoc.jar.asc
> commons-vfs2-examples-2.0.jar
> commons-vfs2-examples-2.0-sources.jar
> commons-vfs2-project-2.0-tests.jar.asc
> commons-vfs2-project-2.0-site.xml
> commons-vfs2-project-2.0.pom.asc
> commons-vfs2-project-2.0-tests.jar
> commons-vfs2-project-2.0.pom
> commons-vfs2-project-2.0-site.xml.asc
> commons-vfs2-sandbox-2.0.pom.asc
> commons-vfs2-sandbox-2.0-sources.jar.asc
> commons-vfs2-sandbox-2.0-test-sources.jar.asc
> commons-vfs2-sandbox-2.0.jar
> commons-vfs2-sandbox-2.0-javadoc.jar
> commons-vfs2-sandbox-2.0-site.xml.asc
> commons-vfs2-sandbox-2.0-test-sources.jar
> commons-vfs2-sandbox-2.0.jar.asc
> commons-vfs2-sandbox-2.0-site.xml
> commons-vfs2-sandbox-2.0-sources.jar
> commons-vfs2-sandbox-2.0-javadoc.jar.asc
> commons-vfs2-sandbox-2.0-tests.jar.asc
> commons-vfs2-sandbox-2.0-tests.jar
> commons-vfs2-sandbox-2.0.pom
> commons-vfs2-distribution-2.0-src.tar.gz
> commons-vfs2-distribution-2.0-src.tar.gz.asc
> commons-vfs2-distribution-2.0-src.zip.asc
> commons-vfs2-distribution-2.0.pom.asc
> commons-vfs2-distribution-2.0-bin.zip
> commons-vfs2-distribution-2.0-bin.tar.gz
> commons-vfs2-distribution-2.0-tests.jar.asc
> commons-vfs2-distribution-2.0-bin.tar.gz.asc
> commons-vfs2-distribution-2.0-src.zip
> commons-vfs2-distribution-2.0-tests.jar
> commons-vfs2-distribution-2.0-bin.zip.asc
> commons-vfs2-distribution-2.0.pom
> commons-vfs2-2.0.pom.asc
> commons-vfs2-2.0-javadoc.jar
> commons-vfs2-2.0-tests.jar.asc
> commons-vfs2-2.0-tests.jar
> commons-vfs2-2.0.pom
> commons-vfs2-2.0.jar
> commons-vfs2-2.0-sources.jar.asc
> commons-vfs2-2.0-test-sources.jar.asc
> commons-vfs2-2.0.jar.asc
> commons-vfs2-2.0-site.xml
> commons-vfs2-2.0-sources.jar
> commons-vfs2-2.0-test-sources.jar
> commons-vfs2-2.0-site.xml.asc
> commons-vfs2-2.0-javadoc.jar.asc

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

Re: [VOTE] Release Commons VFS 2.0

2010-12-23 Thread Ralph Goers


On Dec 23, 2010, at 12:11 AM, Jörg Schaible wrote:

> Ralph Goers wrote:
> 
>> 
>> On Dec 21, 2010, at 11:43 PM, Jörg Schaible wrote:
>> 
> 
> But the RM should definitely *look at* the generated release notes and,
 IMO, intentionally committing them is a good thing.  Nothing generated
 directly from maven has ever met my expectations in terms of formatting
 and
 content, so I have always ended up tweaking the generated files.  I
 don't see this as onerous, personally.
>>> 
>>> Then why not generating it directly before the release manually,
>>> "finalize" it and commit it? After a release it can be deleted again in
>>> svn.
>> 
>> This is exactly what I'm thinking of doing with an enhancement to the
>> release plugin, changes plugin or a new plugin. release-prepare would then
>> do this automatically.
> 
> Well, I thought "finalize" to be a manual task in accordance with Phil's 
> comment about tweaking the generated stuff before the release.

If I wanted to perform the release from Hudson (which I would find to be highly 
desirable) these manual steps would make it more difficult. In many cases the 
release note template won't need to be changed, although the list of fixes and 
enhancements that will be integrated by the changes plugin certainly will.

Ralph


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

Re: [VOTE] Release Commons VFS 2.0

2010-12-23 Thread Jörg Schaible

Ralph Goers wrote:

> 
> On Dec 21, 2010, at 11:43 PM, Jörg Schaible wrote:
> 
 
 But the RM should definitely *look at* the generated release notes and,
>>> IMO, intentionally committing them is a good thing.  Nothing generated
>>> directly from maven has ever met my expectations in terms of formatting
>>> and
>>> content, so I have always ended up tweaking the generated files.  I
>>> don't see this as onerous, personally.
>> 
>> Then why not generating it directly before the release manually,
>> "finalize" it and commit it? After a release it can be deleted again in
>> svn.
> 
> This is exactly what I'm thinking of doing with an enhancement to the
> release plugin, changes plugin or a new plugin. release-prepare would then
> do this automatically.

Well, I thought "finalize" to be a manual task in accordance with Phil's 
comment about tweaking the generated stuff before the release.

>> All we need then is a verification that the file exists while releasing.
>> This can be done by the verifier plugin (best to bind the goal to the
>> validation phase) in the release profile.
> 
> This wouldn't be necessary since the above plugin would fail if it can't
> generate the release notes.

It would be a different process then. For me it would be enough if the 
release can check if the changes.xml and release notes handle the current 
version. Whatever this means ;-)

- Jörg


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

Re: [VOTE] Release Commons VFS 2.0

2010-12-22 Thread Ralph Goers


On Dec 21, 2010, at 11:43 PM, Jörg Schaible wrote:

>>> 
>>> But the RM should definitely *look at* the generated release notes and,
>> IMO, intentionally committing them is a good thing.  Nothing generated
>> directly from maven has ever met my expectations in terms of formatting
>> and
>> content, so I have always ended up tweaking the generated files.  I don't
>> see this as onerous, personally.
> 
> Then why not generating it directly before the release manually, "finalize" 
> it and commit it? After a release it can be deleted again in svn.

This is exactly what I'm thinking of doing with an enhancement to the release 
plugin, changes plugin or a new plugin. release-prepare would then do this 
automatically.

> 
> All we need then is a verification that the file exists while releasing. 
> This can be done by the verifier plugin (best to bind the goal to the 
> validation phase) in the release profile.

This wouldn't be necessary since the above plugin would fail if it can't 
generate the release notes.

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

Re: [VOTE] Release Commons VFS 2.0

2010-12-22 Thread sebb

On 22 December 2010 07:43, Jörg Schaible  wrote:
> Hi,
>
> Phil Steitz wrote:
>
>> On Tue, Dec 21, 2010 at 7:48 PM, sebb  wrote:
>>
>>> On 22 December 2010 00:11, Phil Steitz  wrote:
>>> > On Tue, Dec 21, 2010 at 7:00 PM, Ralph Goers
>>> > >> >wrote:
>>> >
>>> >>
>>> >> On Dec 21, 2010, at 2:55 PM, sebb wrote:
>>> >>
>>> >> > On 21 December 2010 05:21, Ralph Goers 
>>> >> wrote
>>> >> >
>>> >> >> I have not included release notes in the src zip since my
>>> understanding
>>> >> is the src zip should contain the directories pretty much as they
>>> >> exist
>>> in
>>> >> SVN.  Instead I have added a README.txt that tells a user how to
>>> generate
>>> >> the announcement file.
>>> >> >
>>> >> > I would prefer to see the release notes generated and checked into
>>> >> > SVN; they can then be included in both source and binary archives.
>>> >> >
>>> >> > See for example MATH and NET (2.0)
>>> >>
>>> >> I looked at net/trunk. I would prefer that the release notes be
>>> generated
>>> >> during mvn release:prepare instead of requiring a manual mvn
>>> >> invocation
>>> to
>>> >> create the release notes and then a commit. I have that working for
>>> >> the binary distribution but I don't want to do it for the source
>>> distribution
>>> >> since they shouldn't be included if they aren't in svn and, in my
>>> >> view,
>>> they
>>> >> shouldn't be in svn because they will generally be out of sync with
>>> >> changes.xml in trunk.
>>> >>
>>> >> I would say that is up to the RM :)
>>> >
>>> > I personally don't have a problem with the out-of-synch condition.
>>> > What
>>> is
>>> > important is, like changes.xml or any other file, what gets tagged and
>>> > released.
>>>
>>> +1
>>>
>>> I think it's vital that the release notes are included in the source
>>> release.
>>>
>>> The user should not be required to run a command to create the release
>>> notes.
>>>
>>> But the RM should definitely *look at* the generated release notes and,
>> IMO, intentionally committing them is a good thing.  Nothing generated
>> directly from maven has ever met my expectations in terms of formatting
>> and
>> content, so I have always ended up tweaking the generated files.

BTW, I did a bit of work with the MATH vm file which makes it possible
to produce better formatting, by adjusting the spacing in the
changes.xml file.

It's a bit tedious getting it correct initially but the output can
look quite acceptable.

Once set up, adding new entries is easy - just follow the existing spacing.

> > I don't see this as onerous, personally.

+1

> Then why not generating it directly before the release manually, "finalize"
> it and commit it? After a release it can be deleted again in svn.

Why delete it?

So long as the RN are uptodate for the release, it does not matter if
it gets a bit stale later.
Changes.xml is not always kept up to date between releases either.

> All we need then is a verification that the file exists while releasing.
> This can be done by the verifier plugin (best to bind the goal to the
> validation phase) in the release profile.

The verification that is needed is that changes.xml is uptodate, and
the RN file corresponds.

> - Jörg
>
>
> -
> 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] Release Commons VFS 2.0

2010-12-21 Thread Jörg Schaible

Hi,

Phil Steitz wrote:

> On Tue, Dec 21, 2010 at 7:48 PM, sebb  wrote:
> 
>> On 22 December 2010 00:11, Phil Steitz  wrote:
>> > On Tue, Dec 21, 2010 at 7:00 PM, Ralph Goers
>> > > >wrote:
>> >
>> >>
>> >> On Dec 21, 2010, at 2:55 PM, sebb wrote:
>> >>
>> >> > On 21 December 2010 05:21, Ralph Goers 
>> >> wrote
>> >> >
>> >> >> I have not included release notes in the src zip since my
>> understanding
>> >> is the src zip should contain the directories pretty much as they
>> >> exist
>> in
>> >> SVN.  Instead I have added a README.txt that tells a user how to
>> generate
>> >> the announcement file.
>> >> >
>> >> > I would prefer to see the release notes generated and checked into
>> >> > SVN; they can then be included in both source and binary archives.
>> >> >
>> >> > See for example MATH and NET (2.0)
>> >>
>> >> I looked at net/trunk. I would prefer that the release notes be
>> generated
>> >> during mvn release:prepare instead of requiring a manual mvn
>> >> invocation
>> to
>> >> create the release notes and then a commit. I have that working for
>> >> the binary distribution but I don't want to do it for the source
>> distribution
>> >> since they shouldn't be included if they aren't in svn and, in my
>> >> view,
>> they
>> >> shouldn't be in svn because they will generally be out of sync with
>> >> changes.xml in trunk.
>> >>
>> >> I would say that is up to the RM :)
>> >
>> > I personally don't have a problem with the out-of-synch condition. 
>> > What
>> is
>> > important is, like changes.xml or any other file, what gets tagged and
>> > released.
>>
>> +1
>>
>> I think it's vital that the release notes are included in the source
>> release.
>>
>> The user should not be required to run a command to create the release
>> notes.
>>
>> But the RM should definitely *look at* the generated release notes and,
> IMO, intentionally committing them is a good thing.  Nothing generated
> directly from maven has ever met my expectations in terms of formatting
> and
> content, so I have always ended up tweaking the generated files.  I don't
> see this as onerous, personally.

Then why not generating it directly before the release manually, "finalize" 
it and commit it? After a release it can be deleted again in svn.

All we need then is a verification that the file exists while releasing. 
This can be done by the verifier plugin (best to bind the goal to the 
validation phase) in the release profile.

- Jörg


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

Re: [VOTE] Release Commons VFS 2.0

2010-12-21 Thread Phil Steitz

On Tue, Dec 21, 2010 at 7:48 PM, sebb  wrote:

> On 22 December 2010 00:11, Phil Steitz  wrote:
> > On Tue, Dec 21, 2010 at 7:00 PM, Ralph Goers  >wrote:
> >
> >>
> >> On Dec 21, 2010, at 2:55 PM, sebb wrote:
> >>
> >> > On 21 December 2010 05:21, Ralph Goers 
> >> wrote
> >> >
> >> >> I have not included release notes in the src zip since my
> understanding
> >> is the src zip should contain the directories pretty much as they exist
> in
> >> SVN.  Instead I have added a README.txt that tells a user how to
> generate
> >> the announcement file.
> >> >
> >> > I would prefer to see the release notes generated and checked into
> >> > SVN; they can then be included in both source and binary archives.
> >> >
> >> > See for example MATH and NET (2.0)
> >>
> >> I looked at net/trunk. I would prefer that the release notes be
> generated
> >> during mvn release:prepare instead of requiring a manual mvn invocation
> to
> >> create the release notes and then a commit. I have that working for the
> >> binary distribution but I don't want to do it for the source
> distribution
> >> since they shouldn't be included if they aren't in svn and, in my view,
> they
> >> shouldn't be in svn because they will generally be out of sync with
> >> changes.xml in trunk.
> >>
> >> I would say that is up to the RM :)
> >
> > I personally don't have a problem with the out-of-synch condition.  What
> is
> > important is, like changes.xml or any other file, what gets tagged and
> > released.
>
> +1
>
> I think it's vital that the release notes are included in the source
> release.
>
> The user should not be required to run a command to create the release
> notes.
>
> But the RM should definitely *look at* the generated release notes and,
IMO, intentionally committing them is a good thing.  Nothing generated
directly from maven has ever met my expectations in terms of formatting and
content, so I have always ended up tweaking the generated files.  I don't
see this as onerous, personally.

Phil


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

Re: [VOTE] Release Commons VFS 2.0

2010-12-21 Thread Gary Gregory

On Dec 21, 2010, at 18:49, "sebb"  wrote:

> On 22 December 2010 00:11, Phil Steitz  wrote:
>> On Tue, Dec 21, 2010 at 7:00 PM, Ralph Goers 
>> wrote:
>> 
>>> 
>>> On Dec 21, 2010, at 2:55 PM, sebb wrote:
>>> 
 On 21 December 2010 05:21, Ralph Goers 
>>> wrote
 
> I have not included release notes in the src zip since my understanding
>>> is the src zip should contain the directories pretty much as they exist in
>>> SVN.  Instead I have added a README.txt that tells a user how to generate
>>> the announcement file.
 
 I would prefer to see the release notes generated and checked into
 SVN; they can then be included in both source and binary archives.
 
 See for example MATH and NET (2.0)
>>> 
>>> I looked at net/trunk. I would prefer that the release notes be generated
>>> during mvn release:prepare instead of requiring a manual mvn invocation to
>>> create the release notes and then a commit. I have that working for the
>>> binary distribution but I don't want to do it for the source distribution
>>> since they shouldn't be included if they aren't in svn and, in my view, they
>>> shouldn't be in svn because they will generally be out of sync with
>>> changes.xml in trunk.
>>> 
>>> I would say that is up to the RM :)
>> 
>> I personally don't have a problem with the out-of-synch condition.  What is
>> important is, like changes.xml or any other file, what gets tagged and
>> released.
> 
> +1
> 
> I think it's vital that the release notes are included in the source release.
> 
> The user should not be required to run a command to create the release notes.

+1
Gary 

> 
>> Phil
>> 
>> 
>>> Ralph
>>> 
>>> 
>> 
> 
> -
> 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] Release Commons VFS 2.0

2010-12-21 Thread sebb

On 22 December 2010 00:11, Phil Steitz  wrote:
> On Tue, Dec 21, 2010 at 7:00 PM, Ralph Goers 
> wrote:
>
>>
>> On Dec 21, 2010, at 2:55 PM, sebb wrote:
>>
>> > On 21 December 2010 05:21, Ralph Goers 
>> wrote
>> >
>> >> I have not included release notes in the src zip since my understanding
>> is the src zip should contain the directories pretty much as they exist in
>> SVN.  Instead I have added a README.txt that tells a user how to generate
>> the announcement file.
>> >
>> > I would prefer to see the release notes generated and checked into
>> > SVN; they can then be included in both source and binary archives.
>> >
>> > See for example MATH and NET (2.0)
>>
>> I looked at net/trunk. I would prefer that the release notes be generated
>> during mvn release:prepare instead of requiring a manual mvn invocation to
>> create the release notes and then a commit. I have that working for the
>> binary distribution but I don't want to do it for the source distribution
>> since they shouldn't be included if they aren't in svn and, in my view, they
>> shouldn't be in svn because they will generally be out of sync with
>> changes.xml in trunk.
>>
>> I would say that is up to the RM :)
>
> I personally don't have a problem with the out-of-synch condition.  What is
> important is, like changes.xml or any other file, what gets tagged and
> released.

+1

I think it's vital that the release notes are included in the source release.

The user should not be required to run a command to create the release notes.

> Phil
>
>
>> Ralph
>>
>>
>

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

Re: [VOTE] Release Commons VFS 2.0

2010-12-21 Thread Phil Steitz

On Tue, Dec 21, 2010 at 7:00 PM, Ralph Goers wrote:

>
> On Dec 21, 2010, at 2:55 PM, sebb wrote:
>
> > On 21 December 2010 05:21, Ralph Goers 
> wrote
> >
> >> I have not included release notes in the src zip since my understanding
> is the src zip should contain the directories pretty much as they exist in
> SVN.  Instead I have added a README.txt that tells a user how to generate
> the announcement file.
> >
> > I would prefer to see the release notes generated and checked into
> > SVN; they can then be included in both source and binary archives.
> >
> > See for example MATH and NET (2.0)
>
> I looked at net/trunk. I would prefer that the release notes be generated
> during mvn release:prepare instead of requiring a manual mvn invocation to
> create the release notes and then a commit. I have that working for the
> binary distribution but I don't want to do it for the source distribution
> since they shouldn't be included if they aren't in svn and, in my view, they
> shouldn't be in svn because they will generally be out of sync with
> changes.xml in trunk.
>
> I would say that is up to the RM :)

I personally don't have a problem with the out-of-synch condition.  What is
important is, like changes.xml or any other file, what gets tagged and
released.

Phil


> Ralph
>
>

Re: [VOTE] Release Commons VFS 2.0

2010-12-21 Thread Ralph Goers

On Dec 21, 2010, at 2:55 PM, sebb wrote:

> On 21 December 2010 05:21, Ralph Goers  wrote
> 
>> I have not included release notes in the src zip since my understanding is 
>> the src zip should contain the directories pretty much as they exist in SVN. 
>>  Instead I have added a README.txt that tells a user how to generate the 
>> announcement file.
> 
> I would prefer to see the release notes generated and checked into
> SVN; they can then be included in both source and binary archives.
> 
> See for example MATH and NET (2.0)

I looked at net/trunk. I would prefer that the release notes be generated 
during mvn release:prepare instead of requiring a manual mvn invocation to 
create the release notes and then a commit. I have that working for the binary 
distribution but I don't want to do it for the source distribution since they 
shouldn't be included if they aren't in svn and, in my view, they shouldn't be 
in svn because they will generally be out of sync with changes.xml in trunk.

Ralph

Re: [VOTE] Release Commons VFS 2.0

2010-12-21 Thread sebb

On 21 December 2010 05:21, Ralph Goers  wrote:
> I have modified the release packaging so that the binary release includes 
> release notes generated by the maven-changes-plugin announcement generator.
> I've excluded doap_vfs.rdf from the src zip, although it isn't clear to me 
> why this is necessary, especially if there is some Maven plugin designed to 
> process it.

Afaik, there isn't a plugin. The DOAPs are processed by a script
running on people.a.o.

The DOAP does not make sense in release archives (binary or source)
because it is updated after the release is created.

[The DOAP files contain meta-data about a component, and it's
confusing to have copies in trunk, branches and tags, so IMO they
should be stored elsewhere.]

> I have not included release notes in the src zip since my understanding is 
> the src zip should contain the directories pretty much as they exist in SVN.  
> Instead I have added a README.txt that tells a user how to generate the 
> announcement file.

I would prefer to see the release notes generated and checked into
SVN; they can then be included in both source and binary archives.

See for example MATH and NET (2.0)

> I've also updated the site main page to document the compatibility break.

> Is there anything else that should be done before attempting a final release?
>
> Ralph
>
> On Dec 6, 2010, at 7:49 AM, sebb wrote:
>
>> On 6 December 2010 02:04, Ralph Goers  wrote:
>>> This is a vote to release Apache Commons VFS 2.0.
>>>
>>> Since the last candidate the package name was changed from vfs to vfs2. 
>>> Many of the Jira issues were reviewed and those that required a possibly 
>>> incompatible API change were addressed. Most instances of StringBuffer were 
>>> replaced with StringBuilder. Some synchronization issues were addressed. 
>>> Many javadoc and some checkstyle issues were addressed. The filesystem 
>>> documentation was improved to list file system capabilities.
>>>
>>> [ ] +1 release it
>>> [ ] +0 go ahead I don't care
>>> [X] -1 no, do not release it because...
>>>
>>> Ralph
>>>
>>> tag: 
>>> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/
>>>   (revision 1042381).
>>>
>>> site: http://people.apache.org/~rgoers/commons-vfs/index.html
>>
>> Does not mention that the new release uses a new package name and
>> requires source updates to use.
>> Ditto the Maven changes.
>>
>> changes.xml has not been updated with a description of the release.
>> Also, the date will need to be changed at some point.
>>
>> I still think we should have tried to maintain binary compatibility -
>> which I think would have been possible.
>> However, assuming that the compatibility break is what the majority
>> wants, this needs to be made very obvious, and there should be upgrade
>> notes describing how to perform the change.
>>
>> IMO there should be some RELEASE_NOTES in the source and binary archives.
>>
>> The source archive should probably exclude the DOAP.
>>
>>>
>>> The following artifacts have been staged to the Apache Nexus Staging 
>>> repository org.apache.commons-051 (u:rgoers, a:75.82.178.177) 
>>> https://repository.apache.org/content/repositories/orgapachecommons-051/
>>>
>>> commons-vfs2-examples-2.0-sources.jar
>>> commons-vfs2-examples-2.0.jar.asc
>>> commons-vfs2-examples-2.0.pom
>>> commons-vfs2-examples-2.0-javadoc.jar.asc
>>> commons-vfs2-examples-2.0.jar
>>> commons-vfs2-examples-2.0-javadoc.jar
>>> commons-vfs2-examples-2.0.pom.asc
>>> commons-vfs2-examples-2.0-sources.jar.asc
>>> commons-vfs2-project-2.0-site.xml
>>> commons-vfs2-project-2.0.pom.asc
>>> commons-vfs2-project-2.0.pom
>>> commons-vfs2-project-2.0-site.xml.asc
>>> commons-vfs2-2.0-sources.jar.asc
>>> commons-vfs2-2.0-tests.jar.asc
>>> commons-vfs2-2.0-javadoc.jar
>>> commons-vfs2-2.0.jar.asc
>>> commons-vfs2-2.0-test-sources.jar.asc
>>> commons-vfs2-2.0-javadoc.jar.asc
>>> commons-vfs2-2.0-test-sources.jar
>>> commons-vfs2-2.0.pom.asc
>>> commons-vfs2-2.0.jar
>>> commons-vfs2-2.0.pom
>>> commons-vfs2-2.0-sources.jar
>>> commons-vfs2-2.0-tests.jar
>>> commons-vfs2-sandbox-2.0.pom.asc
>>> commons-vfs2-sandbox-2.0-javadoc.jar
>>> commons-vfs2-sandbox-2.0-tests.jar
>>> commons-vfs2-sandbox-2.0.jar.asc
>>> commons-vfs2-sandbox-2.0-sources.jar
>>> commons-vfs2-sandbox-2.0-sources.jar.asc
>>> commons-vfs2-sandbox-2.0-tests.jar.asc
>>> commons-vfs2-sandbox-2.0.pom
>>> commons-vfs2-sandbox-2.0.jar
>>> commons-vfs2-sandbox-2.0-test-sources.jar.asc
>>> commons-vfs2-sandbox-2.0-test-sources.jar
>>> commons-vfs2-sandbox-2.0-javadoc.jar.asc
>>> commons-vfs2-distribution-2.0-bin.tar.gz.asc
>>> commons-vfs2-distribution-2.0-src.tar.gz
>>> commons-vfs2-distribution-2.0-src.zip
>>> commons-vfs2-distribution-2.0-src.zip.asc
>>> commons-vfs2-distribution-2.0.pom.asc
>>> commons-vfs2-distribution-2.0.pom
>>> commons-vfs2-distribution-2.0-bin.zip
>>> commons-vfs2-distribution-2.0-src.tar.gz.asc
>>> commons-vfs2-distribution-2.0-bin.tar.gz
>>> commons-vfs2-distribution-2.0-bin.zip.as

Re: [VOTE] Release Commons VFS 2.0

2010-12-20 Thread Ralph Goers

I have modified the release packaging so that the binary release includes 
release notes generated by the maven-changes-plugin announcement generator. 
I've excluded doap_vfs.rdf from the src zip, although it isn't clear to me why 
this is necessary, especially if there is some Maven plugin designed to process 
it.  I have not included release notes in the src zip since my understanding is 
the src zip should contain the directories pretty much as they exist in SVN.  
Instead I have added a README.txt that tells a user how to generate the 
announcement file.  I've also updated the site main page to document the 
compatibility break.

Is there anything else that should be done before attempting a final release?

Ralph

On Dec 6, 2010, at 7:49 AM, sebb wrote:

> On 6 December 2010 02:04, Ralph Goers  wrote:
>> This is a vote to release Apache Commons VFS 2.0.
>> 
>> Since the last candidate the package name was changed from vfs to vfs2. Many 
>> of the Jira issues were reviewed and those that required a possibly 
>> incompatible API change were addressed. Most instances of StringBuffer were 
>> replaced with StringBuilder. Some synchronization issues were addressed. 
>> Many javadoc and some checkstyle issues were addressed. The filesystem 
>> documentation was improved to list file system capabilities.
>> 
>> [ ] +1 release it
>> [ ] +0 go ahead I don't care
>> [X] -1 no, do not release it because...
>> 
>> Ralph
>> 
>> tag: 
>> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/
>>   (revision 1042381).
>> 
>> site: http://people.apache.org/~rgoers/commons-vfs/index.html
> 
> Does not mention that the new release uses a new package name and
> requires source updates to use.
> Ditto the Maven changes.
> 
> changes.xml has not been updated with a description of the release.
> Also, the date will need to be changed at some point.
> 
> I still think we should have tried to maintain binary compatibility -
> which I think would have been possible.
> However, assuming that the compatibility break is what the majority
> wants, this needs to be made very obvious, and there should be upgrade
> notes describing how to perform the change.
> 
> IMO there should be some RELEASE_NOTES in the source and binary archives.
> 
> The source archive should probably exclude the DOAP.
> 
>> 
>> The following artifacts have been staged to the Apache Nexus Staging 
>> repository org.apache.commons-051 (u:rgoers, a:75.82.178.177) 
>> https://repository.apache.org/content/repositories/orgapachecommons-051/
>> 
>> commons-vfs2-examples-2.0-sources.jar
>> commons-vfs2-examples-2.0.jar.asc
>> commons-vfs2-examples-2.0.pom
>> commons-vfs2-examples-2.0-javadoc.jar.asc
>> commons-vfs2-examples-2.0.jar
>> commons-vfs2-examples-2.0-javadoc.jar
>> commons-vfs2-examples-2.0.pom.asc
>> commons-vfs2-examples-2.0-sources.jar.asc
>> commons-vfs2-project-2.0-site.xml
>> commons-vfs2-project-2.0.pom.asc
>> commons-vfs2-project-2.0.pom
>> commons-vfs2-project-2.0-site.xml.asc
>> commons-vfs2-2.0-sources.jar.asc
>> commons-vfs2-2.0-tests.jar.asc
>> commons-vfs2-2.0-javadoc.jar
>> commons-vfs2-2.0.jar.asc
>> commons-vfs2-2.0-test-sources.jar.asc
>> commons-vfs2-2.0-javadoc.jar.asc
>> commons-vfs2-2.0-test-sources.jar
>> commons-vfs2-2.0.pom.asc
>> commons-vfs2-2.0.jar
>> commons-vfs2-2.0.pom
>> commons-vfs2-2.0-sources.jar
>> commons-vfs2-2.0-tests.jar
>> commons-vfs2-sandbox-2.0.pom.asc
>> commons-vfs2-sandbox-2.0-javadoc.jar
>> commons-vfs2-sandbox-2.0-tests.jar
>> commons-vfs2-sandbox-2.0.jar.asc
>> commons-vfs2-sandbox-2.0-sources.jar
>> commons-vfs2-sandbox-2.0-sources.jar.asc
>> commons-vfs2-sandbox-2.0-tests.jar.asc
>> commons-vfs2-sandbox-2.0.pom
>> commons-vfs2-sandbox-2.0.jar
>> commons-vfs2-sandbox-2.0-test-sources.jar.asc
>> commons-vfs2-sandbox-2.0-test-sources.jar
>> commons-vfs2-sandbox-2.0-javadoc.jar.asc
>> commons-vfs2-distribution-2.0-bin.tar.gz.asc
>> commons-vfs2-distribution-2.0-src.tar.gz
>> commons-vfs2-distribution-2.0-src.zip
>> commons-vfs2-distribution-2.0-src.zip.asc
>> commons-vfs2-distribution-2.0.pom.asc
>> commons-vfs2-distribution-2.0.pom
>> commons-vfs2-distribution-2.0-bin.zip
>> commons-vfs2-distribution-2.0-src.tar.gz.asc
>> commons-vfs2-distribution-2.0-bin.tar.gz
>> commons-vfs2-distribution-2.0-bin.zip.asc
> 
> -
> 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] Release Commons VFS 2.0

2010-12-06 Thread Ralph Goers

On Dec 6, 2010, at 7:07 AM, Gary Gregory wrote:

> Hi Ralph:
> 
> While the src distro ran the Maven test goal OK for me on Vista + Java 6, I 
> see that no tests ran (0% success rate) according to 
> http://people.apache.org/~rgoers/commons-vfs/surefire-report.html
> 
> How can that be?
> 
> 

VFS is a multi-module project. The parent project has no unit tests. You would 
want to look at 
http://people.apache.org/~rgoers/commons-vfs/commons-vfs2/surefire-report.html.

Ralph

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

Re: [VOTE] Release Commons VFS 2.0

2010-12-06 Thread Gary Gregory

On Dec 6, 2010, at 10:49, "sebb"  wrote:

> On 6 December 2010 02:04, Ralph Goers  wrote:
>> This is a vote to release Apache Commons VFS 2.0.
>> 
>> Since the last candidate the package name was changed from vfs to vfs2. Many 
>> of the Jira issues were reviewed and those that required a possibly 
>> incompatible API change were addressed. Most instances of StringBuffer were 
>> replaced with StringBuilder. Some synchronization issues were addressed. 
>> Many javadoc and some checkstyle issues were addressed. The filesystem 
>> documentation was improved to list file system capabilities.
>> 
>> [ ] +1 release it
>> [ ] +0 go ahead I don't care
>> [X] -1 no, do not release it because...
>> 
>> Ralph
>> 
>> tag: 
>> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/
>>   (revision 1042381).
>> 
>> site: http://people.apache.org/~rgoers/commons-vfs/index.html
> 
> Does not mention that the new release uses a new package name and
> requires source updates to use.
> Ditto the Maven changes.
> 
> changes.xml has not been updated with a description of the release.
> Also, the date will need to be changed at some point.
> 
> I still think we should have tried to maintain binary compatibility -
> which I think would have been possible.
> However, assuming that the compatibility break is what the majority
> wants, this needs to be made very obvious, and there should be upgrade
> notes describing how to perform the change.
> 
> IMO there should be some RELEASE_NOTES in the source and binary archives.

+1  I've come to expect release notes in bin releases.

Gary

> 
> The source archive should probably exclude the DOAP.
> 
>> 
>> The following artifacts have been staged to the Apache Nexus Staging 
>> repository org.apache.commons-051 (u:rgoers, a:75.82.178.177) 
>> https://repository.apache.org/content/repositories/orgapachecommons-051/
>> 
>> commons-vfs2-examples-2.0-sources.jar
>> commons-vfs2-examples-2.0.jar.asc
>> commons-vfs2-examples-2.0.pom
>> commons-vfs2-examples-2.0-javadoc.jar.asc
>> commons-vfs2-examples-2.0.jar
>> commons-vfs2-examples-2.0-javadoc.jar
>> commons-vfs2-examples-2.0.pom.asc
>> commons-vfs2-examples-2.0-sources.jar.asc
>> commons-vfs2-project-2.0-site.xml
>> commons-vfs2-project-2.0.pom.asc
>> commons-vfs2-project-2.0.pom
>> commons-vfs2-project-2.0-site.xml.asc
>> commons-vfs2-2.0-sources.jar.asc
>> commons-vfs2-2.0-tests.jar.asc
>> commons-vfs2-2.0-javadoc.jar
>> commons-vfs2-2.0.jar.asc
>> commons-vfs2-2.0-test-sources.jar.asc
>> commons-vfs2-2.0-javadoc.jar.asc
>> commons-vfs2-2.0-test-sources.jar
>> commons-vfs2-2.0.pom.asc
>> commons-vfs2-2.0.jar
>> commons-vfs2-2.0.pom
>> commons-vfs2-2.0-sources.jar
>> commons-vfs2-2.0-tests.jar
>> commons-vfs2-sandbox-2.0.pom.asc
>> commons-vfs2-sandbox-2.0-javadoc.jar
>> commons-vfs2-sandbox-2.0-tests.jar
>> commons-vfs2-sandbox-2.0.jar.asc
>> commons-vfs2-sandbox-2.0-sources.jar
>> commons-vfs2-sandbox-2.0-sources.jar.asc
>> commons-vfs2-sandbox-2.0-tests.jar.asc
>> commons-vfs2-sandbox-2.0.pom
>> commons-vfs2-sandbox-2.0.jar
>> commons-vfs2-sandbox-2.0-test-sources.jar.asc
>> commons-vfs2-sandbox-2.0-test-sources.jar
>> commons-vfs2-sandbox-2.0-javadoc.jar.asc
>> commons-vfs2-distribution-2.0-bin.tar.gz.asc
>> commons-vfs2-distribution-2.0-src.tar.gz
>> commons-vfs2-distribution-2.0-src.zip
>> commons-vfs2-distribution-2.0-src.zip.asc
>> commons-vfs2-distribution-2.0.pom.asc
>> commons-vfs2-distribution-2.0.pom
>> commons-vfs2-distribution-2.0-bin.zip
>> commons-vfs2-distribution-2.0-src.tar.gz.asc
>> commons-vfs2-distribution-2.0-bin.tar.gz
>> commons-vfs2-distribution-2.0-bin.zip.asc
> 
> -
> 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] Release Commons VFS 2.0

2010-12-06 Thread sebb

On 6 December 2010 02:04, Ralph Goers  wrote:
> This is a vote to release Apache Commons VFS 2.0.
>
> Since the last candidate the package name was changed from vfs to vfs2. Many 
> of the Jira issues were reviewed and those that required a possibly 
> incompatible API change were addressed. Most instances of StringBuffer were 
> replaced with StringBuilder. Some synchronization issues were addressed. Many 
> javadoc and some checkstyle issues were addressed. The filesystem 
> documentation was improved to list file system capabilities.
>
> [ ] +1 release it
> [ ] +0 go ahead I don't care
> [X] -1 no, do not release it because...
>
> Ralph
>
> tag: 
> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/
>   (revision 1042381).
>
> site: http://people.apache.org/~rgoers/commons-vfs/index.html

Does not mention that the new release uses a new package name and
requires source updates to use.
Ditto the Maven changes.

changes.xml has not been updated with a description of the release.
Also, the date will need to be changed at some point.

I still think we should have tried to maintain binary compatibility -
which I think would have been possible.
However, assuming that the compatibility break is what the majority
wants, this needs to be made very obvious, and there should be upgrade
notes describing how to perform the change.

IMO there should be some RELEASE_NOTES in the source and binary archives.

The source archive should probably exclude the DOAP.

>
> The following artifacts have been staged to the Apache Nexus Staging 
> repository org.apache.commons-051 (u:rgoers, a:75.82.178.177) 
> https://repository.apache.org/content/repositories/orgapachecommons-051/
>
> commons-vfs2-examples-2.0-sources.jar
> commons-vfs2-examples-2.0.jar.asc
> commons-vfs2-examples-2.0.pom
> commons-vfs2-examples-2.0-javadoc.jar.asc
> commons-vfs2-examples-2.0.jar
> commons-vfs2-examples-2.0-javadoc.jar
> commons-vfs2-examples-2.0.pom.asc
> commons-vfs2-examples-2.0-sources.jar.asc
> commons-vfs2-project-2.0-site.xml
> commons-vfs2-project-2.0.pom.asc
> commons-vfs2-project-2.0.pom
> commons-vfs2-project-2.0-site.xml.asc
> commons-vfs2-2.0-sources.jar.asc
> commons-vfs2-2.0-tests.jar.asc
> commons-vfs2-2.0-javadoc.jar
> commons-vfs2-2.0.jar.asc
> commons-vfs2-2.0-test-sources.jar.asc
> commons-vfs2-2.0-javadoc.jar.asc
> commons-vfs2-2.0-test-sources.jar
> commons-vfs2-2.0.pom.asc
> commons-vfs2-2.0.jar
> commons-vfs2-2.0.pom
> commons-vfs2-2.0-sources.jar
> commons-vfs2-2.0-tests.jar
> commons-vfs2-sandbox-2.0.pom.asc
> commons-vfs2-sandbox-2.0-javadoc.jar
> commons-vfs2-sandbox-2.0-tests.jar
> commons-vfs2-sandbox-2.0.jar.asc
> commons-vfs2-sandbox-2.0-sources.jar
> commons-vfs2-sandbox-2.0-sources.jar.asc
> commons-vfs2-sandbox-2.0-tests.jar.asc
> commons-vfs2-sandbox-2.0.pom
> commons-vfs2-sandbox-2.0.jar
> commons-vfs2-sandbox-2.0-test-sources.jar.asc
> commons-vfs2-sandbox-2.0-test-sources.jar
> commons-vfs2-sandbox-2.0-javadoc.jar.asc
> commons-vfs2-distribution-2.0-bin.tar.gz.asc
> commons-vfs2-distribution-2.0-src.tar.gz
> commons-vfs2-distribution-2.0-src.zip
> commons-vfs2-distribution-2.0-src.zip.asc
> commons-vfs2-distribution-2.0.pom.asc
> commons-vfs2-distribution-2.0.pom
> commons-vfs2-distribution-2.0-bin.zip
> commons-vfs2-distribution-2.0-src.tar.gz.asc
> commons-vfs2-distribution-2.0-bin.tar.gz
> commons-vfs2-distribution-2.0-bin.zip.asc

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

RE: [VOTE] Release Commons VFS 2.0

2010-12-06 Thread Gary Gregory

Hi Ralph:

While the src distro ran the Maven test goal OK for me on Vista + Java 6, I see 
that no tests ran (0% success rate) according to 
http://people.apache.org/~rgoers/commons-vfs/surefire-report.html

How can that be?

Gary Gregory
Senior Software Engineer
Rocket Software
3340 Peachtree Road, Suite 820 . Atlanta, GA 30326 . USA
Tel: +1.404.760.1560
Email: ggreg...@seagullsoftware.com
Web: seagull.rocketsoftware.com  



> -Original Message-
> From: Ralph Goers [mailto:ralph.go...@dslextreme.com]
> Sent: Sunday, December 05, 2010 21:05
> To: Commons Developers List
> Subject: [VOTE] Release Commons VFS 2.0
> 
> This is a vote to release Apache Commons VFS 2.0.
> 
> Since the last candidate the package name was changed from vfs to vfs2. Many
> of the Jira issues were reviewed and those that required a possibly
> incompatible API change were addressed. Most instances of StringBuffer were
> replaced with StringBuilder. Some synchronization issues were addressed. Many
> javadoc and some checkstyle issues were addressed. The filesystem
> documentation was improved to list file system capabilities.
> 
> [ ] +1 release it
> [ ] +0 go ahead I don't care
> [ ] -1 no, do not release it because...
> 
> Ralph
> 
> tag: https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-
> project-2.0/  (revision 1042381).
> 
> site: http://people.apache.org/~rgoers/commons-vfs/index.html
> 
> The following artifacts have been staged to the Apache Nexus Staging
> repository org.apache.commons-051 (u:rgoers, a:75.82.178.177)
> https://repository.apache.org/content/repositories/orgapachecommons-051/
> 
> commons-vfs2-examples-2.0-sources.jar
> commons-vfs2-examples-2.0.jar.asc
> commons-vfs2-examples-2.0.pom
> commons-vfs2-examples-2.0-javadoc.jar.asc
> commons-vfs2-examples-2.0.jar
> commons-vfs2-examples-2.0-javadoc.jar
> commons-vfs2-examples-2.0.pom.asc
> commons-vfs2-examples-2.0-sources.jar.asc
> commons-vfs2-project-2.0-site.xml
> commons-vfs2-project-2.0.pom.asc
> commons-vfs2-project-2.0.pom
> commons-vfs2-project-2.0-site.xml.asc
> commons-vfs2-2.0-sources.jar.asc
> commons-vfs2-2.0-tests.jar.asc
> commons-vfs2-2.0-javadoc.jar
> commons-vfs2-2.0.jar.asc
> commons-vfs2-2.0-test-sources.jar.asc
> commons-vfs2-2.0-javadoc.jar.asc
> commons-vfs2-2.0-test-sources.jar
> commons-vfs2-2.0.pom.asc
> commons-vfs2-2.0.jar
> commons-vfs2-2.0.pom
> commons-vfs2-2.0-sources.jar
> commons-vfs2-2.0-tests.jar
> commons-vfs2-sandbox-2.0.pom.asc
> commons-vfs2-sandbox-2.0-javadoc.jar
> commons-vfs2-sandbox-2.0-tests.jar
> commons-vfs2-sandbox-2.0.jar.asc
> commons-vfs2-sandbox-2.0-sources.jar
> commons-vfs2-sandbox-2.0-sources.jar.asc
> commons-vfs2-sandbox-2.0-tests.jar.asc
> commons-vfs2-sandbox-2.0.pom
> commons-vfs2-sandbox-2.0.jar
> commons-vfs2-sandbox-2.0-test-sources.jar.asc
> commons-vfs2-sandbox-2.0-test-sources.jar
> commons-vfs2-sandbox-2.0-javadoc.jar.asc
> commons-vfs2-distribution-2.0-bin.tar.gz.asc
> commons-vfs2-distribution-2.0-src.tar.gz
> commons-vfs2-distribution-2.0-src.zip
> commons-vfs2-distribution-2.0-src.zip.asc
> commons-vfs2-distribution-2.0.pom.asc
> commons-vfs2-distribution-2.0.pom
> commons-vfs2-distribution-2.0-bin.zip
> commons-vfs2-distribution-2.0-src.tar.gz.asc
> commons-vfs2-distribution-2.0-bin.tar.gz
> commons-vfs2-distribution-2.0-bin.zip.asc

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

RE: [VOTE] Release Commons VFS 2.0

2010-11-08 Thread Ronan KERDUDOU - VirageGroup

"+1 release it"
I don't like using a build named "commons-vfs-20070611.jar" because no
official release exists...

Also, if VFS2 isn't backward compatible and lists all changes to make during
upgrade, we should consider patching FileContentInputStream to return false
in method markSupported()
See https://issues.apache.org/jira/browse/VFS-301

And no problem for me if you change the package or not
and no problem if you're going to java 6.

Regards,

KERDUDOU Ronan
VIRAGE Group (France)
R&D : +33 (0)2 53 55 10 22
r...@viragegroup.com
www.viragegroup.com

-Message d'origine-
De : Ralph Goers [mailto:ralph.go...@dslextreme.com]
Envoyé : jeudi 4 novembre 2010 00:23
À : Commons Developers List
Objet : [VOTE] Release Commons VFS 2.0

This is a vote to release Apache Commons VFS 2.0.

[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because...

Ralph

tag:
https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project
-2.0/

site: http://people.apache.org/~rgoers/commons-vfs/index.html

The following artifacts have been staged to the Apache Nexus Staging
repository org.apache.commons-028 (u:rgoers, a:38.101.196.246).

commons-vfs-project-2.0-src.zip
commons-vfs-project-2.0-src.tar.gz
commons-vfs-project-2.0-source-release.zip.asc
commons-vfs-project-2.0-bin.tar.gz.asc
commons-vfs-project-2.0.pom
commons-vfs-project-2.0-site.xml
commons-vfs-project-2.0-bin.zip
commons-vfs-project-2.0-src.zip.asc
commons-vfs-project-2.0-source-release.zip
commons-vfs-project-2.0-site.xml.asc
commons-vfs-project-2.0-src.tar.gz.asc
commons-vfs-project-2.0.pom.asc
commons-vfs-project-2.0-bin.zip.asc
commons-vfs-project-2.0-bin.tar.gz
commons-vfs-2.0.pom.asc
commons-vfs-2.0-tests.jar.asc
commons-vfs-2.0-sources.jar
commons-vfs-2.0-sources.jar.asc
commons-vfs-2.0.jar
commons-vfs-2.0.jar.asc
commons-vfs-2.0.pom
commons-vfs-2.0-javadoc.jar.asc
commons-vfs-2.0-tests.jar
commons-vfs-2.0-javadoc.jar
commons-vfs-sandbox-2.0-sources.jar
commons-vfs-sandbox-2.0-sources.jar.asc
commons-vfs-sandbox-2.0-javadoc.jar
commons-vfs-sandbox-2.0.jar.asc
commons-vfs-sandbox-2.0.pom
commons-vfs-sandbox-2.0.jar
commons-vfs-sandbox-2.0.pom.asc
commons-vfs-sandbox-2.0-javadoc.jar.asc
commons-vfs-examples-2.0-javadoc.jar.asc
commons-vfs-examples-2.0-javadoc.jar
commons-vfs-examples-2.0-sources.jar.asc
commons-vfs-examples-2.0-sources.jar
commons-vfs-examples-2.0.jar.asc
commons-vfs-examples-2.0.pom
commons-vfs-examples-2.0.jar
commons-vfs-examples-2.0.pom.asc




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

Re: Backwards incompatible changes and package names (was: Re: [VOTE] Release Commons VFS 2.0)

2010-11-08 Thread sebb

On 8 November 2010 07:32, Gary Gregory  wrote:
>> -Original Message-
>> From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On
>> Behalf Of James Carman
>> Sent: Sunday, November 07, 2010 18:14
>> To: Commons Developers List
>> Subject: Re: Backwards incompatible changes and package names (was: Re: 
>> [VOTE]
>> Release Commons VFS 2.0)
>>
>> On Sun, Nov 7, 2010 at 9:02 PM, Phil Steitz  wrote:
>> > I would not -1 the release, but I would encourage the RM to consider making
>> > it 1.x if there are no compat breaks.
>> >
>>
>> So, how about now that we know there are compat breaks?  I would -1
>> the release now that we know the API is in fact "broken" between 1 and
>> 2 and they're not doing the package/artifactId change (barring any
>> justification why we think it's okay).
>
> Well, that should settle it. API-breakage -> new major version -> 
> package/artifactId change.
>
> So we can take this RC, do the above changes, then keep move on to a Java 5 
> themed release for 2.1.

I think we ought to remove the deprecations as well, otherwise they
cannot be removed until 3.0, which I assume will require yet another
package/artid change.

>
> Gary
>
>>
>> -
>> 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] Release Commons VFS 2.0

2010-11-08 Thread Jörg Schaible

Jörg Schaible wrote:

> Ralph Goers wrote:
> 
>> This is a vote to release Apache Commons VFS 2.0.
>> 
>> Since the last candidate the jdk version has been changed to 1.5 and the
>> requirement has been added to the web site main page. The test file for
>> LargeTarTestCase has been added to the test-data directory, greatly
>> improving the build time. Many of the messages from the test cases have
>> been removed.
>> 
>> [ ] +1 release it
>> [ ] +0 go ahead I don't care
>> [ ] -1 no, do not release it because...
> 
> +1

-1

I revert this vote now, since it is clear that it's no longer binary 
compatible. And when you look at the long list of project using vfs it is a 
bad idea to release it th this way (see "This artifact is used by ..."): 
http://mvnrepository.com/artifact/commons-vfs/commons-vfs/1.0

- Jörg

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

RE: Backwards incompatible changes and package names (was: Re: [VOTE] Release Commons VFS 2.0)

2010-11-07 Thread Gary Gregory

> -Original Message-
> From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On
> Behalf Of James Carman
> Sent: Sunday, November 07, 2010 18:14
> To: Commons Developers List
> Subject: Re: Backwards incompatible changes and package names (was: Re: [VOTE]
> Release Commons VFS 2.0)
> 
> On Sun, Nov 7, 2010 at 9:02 PM, Phil Steitz  wrote:
> > I would not -1 the release, but I would encourage the RM to consider making
> > it 1.x if there are no compat breaks.
> >
> 
> So, how about now that we know there are compat breaks?  I would -1
> the release now that we know the API is in fact "broken" between 1 and
> 2 and they're not doing the package/artifactId change (barring any
> justification why we think it's okay).

Well, that should settle it. API-breakage -> new major version -> 
package/artifactId change.

So we can take this RC, do the above changes, then keep move on to a Java 5 
themed release for 2.1.

Gary 

> 
> -
> 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] Release Commons VFS 2.0

On Nov 7, 2010, at 6:49 PM, James Carman wrote:

> On Sun, Nov 7, 2010 at 8:41 PM, Ralph Goers  
> wrote:
>> 
>> I'm not sure whether I agree. I think I mentioned that Java 7 has a new 
>> FileSystem abstraction. 
>> http://download.oracle.com/javase/7/docs/api/java/nio/file/package-summary.html.
>>   I  would think VFS 3.0 would remove the API and just provide FileSystem 
>> implementations. So I'm not sure how much effort is worth investing in V2.0 
>> to move it to Java 6.
>> 
> 
> I saw something about this recently (if I had more sleep I could
> probably recall where) and wondered about VFS.  Does this new API look
> like it would do everything that VFS currently does?  If so, it's a
> great step forward for the language, IMHO.
> 

I've not investigated it extensively, but the new API seems to have a lot of 
similarity to VFS. Instead of a File the new API uses a FileChannel, which is 
an abstract class. It wouldn't be a stretch to imagine all the various 
FileObjects extending that. The SPI also has a FileSystemProvider which is used 
to create a FileSystem and a FileStore.  It also includes a WatchService to 
listen for changes and events.

Ralph

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

Re: [VOTE] Release Commons VFS 2.0

On Sun, Nov 7, 2010 at 8:41 PM, Ralph Goers  wrote:
>
> I'm not sure whether I agree. I think I mentioned that Java 7 has a new 
> FileSystem abstraction. 
> http://download.oracle.com/javase/7/docs/api/java/nio/file/package-summary.html.
>   I  would think VFS 3.0 would remove the API and just provide FileSystem 
> implementations. So I'm not sure how much effort is worth investing in V2.0 
> to move it to Java 6.
>

I saw something about this recently (if I had more sleep I could
probably recall where) and wondered about VFS.  Does this new API look
like it would do everything that VFS currently does?  If so, it's a
great step forward for the language, IMHO.

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

Re: [VOTE] Release Commons VFS 2.0

I'd say that Java7 is still at least 12 months out and another 6-12
months to general adoption.

-h

On Sun, Nov 7, 2010 at 17:41, Ralph Goers  wrote:
>
> On Nov 7, 2010, at 8:37 AM, Henning Schmiedehausen wrote:
>
>> I would suggest that we (and in fact I started hacking around with
>> this) release a vfs2 which is Java6+ only and fully generified.
>>
>
> I'm not sure whether I agree. I think I mentioned that Java 7 has a new 
> FileSystem abstraction. 
> http://download.oracle.com/javase/7/docs/api/java/nio/file/package-summary.html.
>   I  would think VFS 3.0 would remove the API and just provide FileSystem 
> implementations. So I'm not sure how much effort is worth investing in V2.0 
> to move it to Java 6.
>
> Ralph
> -
> 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: Backwards incompatible changes and package names (was: Re: [VOTE] Release Commons VFS 2.0)

On Sun, Nov 7, 2010 at 9:27 PM, Ralph Goers  wrote:
> If this is rushing I'd hate to see slow. Releasing VFS 2.0 has been discussed 
> several times over the last year or more. None of this is new information.
>

Rushing as in doing something before it's time to do it, not rushing
as in doing something quickly.

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

Re: Backwards incompatible changes and package names (was: Re: [VOTE] Release Commons VFS 2.0)


On Nov 7, 2010, at 6:18 PM, James Carman wrote:

> On Sun, Nov 7, 2010 at 9:15 PM, Ralph Goers  
> wrote:
>> 
>> Is the goal to never do a release?
>> 
> 
> No, the goal is to not rush a release just to get something out there.
> If we will be knowingly setting our users up for failure (or worse
> "jar hell"), then I don't want to do a release that way.
> 
If this is rushing I'd hate to see slow. Releasing VFS 2.0 has been discussed 
several times over the last year or more. None of this is new information.

Ralph


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

Re: Backwards incompatible changes and package names (was: Re: [VOTE] Release Commons VFS 2.0)

On Sun, Nov 7, 2010 at 9:15 PM, Ralph Goers  wrote:
>
> Is the goal to never do a release?
>

No, the goal is to not rush a release just to get something out there.
 If we will be knowingly setting our users up for failure (or worse
"jar hell"), then I don't want to do a release that way.

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

Re: Backwards incompatible changes and package names (was: Re: [VOTE] Release Commons VFS 2.0)

On Nov 7, 2010, at 6:02 PM, Phil Steitz wrote:

> On 11/7/10 8:19 PM, James Carman wrote:
>> So you think that if there is no API break, then you don't bump major
>> version numbers?  So what about vfs 2.0?  Would you vote against it?
> 
> I would not -1 the release, but I would encourage the RM to consider making 
> it 1.x if there are no compat breaks.
> 

As Sebb has shown there are compatibility breaks.  The real issue here is that 
it has been far too long since a VFS release has been done. 

I'm not sure why the version was bumped from 1.1 to 2.0, but it happened in 
March 2008, at least 8 months before I started working on the code.  That 
change was 16 months after the prior release.

Is the goal to never do a release?

Ralph

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

Re: Backwards incompatible changes and package names (was: Re: [VOTE] Release Commons VFS 2.0)

On Sun, Nov 7, 2010 at 9:02 PM, Phil Steitz  wrote:
> I would not -1 the release, but I would encourage the RM to consider making
> it 1.x if there are no compat breaks.
>

So, how about now that we know there are compat breaks?  I would -1
the release now that we know the API is in fact "broken" between 1 and
2 and they're not doing the package/artifactId change (barring any
justification why we think it's okay).

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

Re: Backwards incompatible changes and package names (was: Re: [VOTE] Release Commons VFS 2.0)

2010-11-07 Thread Phil Steitz


On 11/7/10 8:19 PM, James Carman wrote:

So you think that if there is no API break, then you don't bump major
version numbers?  So what about vfs 2.0?  Would you vote against it?


I would not -1 the release, but I would encourage the RM to consider 
making it 1.x if there are no compat breaks.


Phil


On Nov 7, 2010 7:18 PM, "Phil Steitz"  wrote:

On 11/7/10 7:03 PM, sebb wrote:

On 7 November 2010 23:56, James Carman  wrote:

It's not a new subproject. It's just a new version of the same
subproject. Trust me, I know about how the maven artifactId/package
name/classpath stuff works. I've had this discussion many times
before on this list. VFS is releasing its 2.0 release right now. If
you want to make binary incompatible changes, it has to bump its major
version number to 3 (along with artifactId/package change).


Agreed.


This is
why I've argued that VFS 2.0 should actually be 1.1, so that we don't
introduce an inconsistency. The 2.x stuff should be in a vfs2
package, per our naming conventions. In my opinion, it's not enough


AFAIK, we have not agreed that package name suffix == major version

number.


I used to be among those resisting this, but James' admirable
persistence has won me over :) For the components that are likely to
have any possibility of needing to appear twice on the classpath of
an application at least, I think the following convention makes sense:

Major version bump<->  compatibility break in API<->  change package
name<->  change maven artifactId

Bumping required JDK does not by itself force a compat break. I
guess it is possible that so much can be accomplished without any
breaks that a major version bump is warranted in some cases; but I
have never seen that happen. So I am +1 on trying to adhere to this
convention or at least explaining why not (in [math] for example we
perhaps lamely argue that classpath multiplicity is not likely).

Phil



different to merit a 2.0 release. Not enough has been done.
Especially when you consider the version numbering madness that this
is going to cause.

On Sun, Nov 7, 2010 at 5:05 PM, Henning Schmiedehausen
  wrote:

It will be a new sub-project. commons-vfs-2.  and commons-vfs2-1.0
should be able to co-exist on the same classpath.

For maven reasons, it is not desirable to have  shift its
internal packages (because Maven does not understand that 2.0 and 3.0
are not compatible) and commons-vfs and commons-vfs2 should not use
use the same packages.

So commons-vfs will continue to use org.apache.commons.vfs.* and
commons-vfs2 will use org.apache.commons.vfs2.*

And it must be possible to have both versions on the classpath without
clashing.

-h




On Sun, Nov 7, 2010 at 13:45, James Carman

wrote:

If we release vfs2 and then we make changes that make it binary
incompatible, then we have to go to 3 to do a new release. Am I
missing something?

On Sun, Nov 7, 2010 at 4:20 PM, Henning Schmiedehausen
  wrote:

No, that would be a vfs2. With new package names and everything. It
would not be intended to be drop in compatible.

-h

On Sun, Nov 7, 2010 at 10:53, James Carman

wrote:

Make sure you stay compatible or it'll have to go to 3.0
On Nov 7, 2010 11:44 AM, "Gary Gregory"


wrote:

On Nov 7, 2010, at 8:37, "Henning Schmiedehausen"<

henn...@schmiedehausen.org>  wrote:



I would suggest that we (and in fact I started hacking around with
this) release a vfs2 which is Java6+ only and fully generified.



That's fine with me and my current work projects but I like a more

iterative process where we can generify the code on java 5 for a

2.1. Then

we can do a java 6 release.


Gary


-h

On Sun, Nov 7, 2010 at 08:22, Gary Gregory<

ggreg...@seagullsoftware.com>

wrote:

On Nov 7, 2010, at 7:45, "sebb"  wrote:


On 7 November 2010 02:17, Gary Gregory<

ggreg...@seagullsoftware.com>

wrote:

-Original Message-
From: Henning Schmiedehausen [mailto:

henn...@schmiedehausen.org]

Sent: Saturday, November 06, 2010 19:03
To: Commons Developers List
Subject: Re: [VOTE] Release Commons VFS 2.0

+1

- I don't think that "has warnings" is a problem
- If deprecated APIs are still around, we can always remove

them

later.


Yes, release early, release often.

I would encourage work to proceed immediately to implement

this,

generics, and whatever Java 5 changes we can take advantage of.


I've already done the main annotations (@Override and

@Deprecation)


I've started looking at generics.

There's rather a lot of changes to fix all the Java 1.5

warnings, so

it will probably have to be done in stages, but I can start

committing

soon


Great news. It would be nice to release early release often a la

XP with

a 2.1 themed release 'java 5 optimized'


Gary




Gary



-h

On Fri, Nov 5, 2010 at 13:12, Ralph Goers<

ralph.go...@dslextreme.com>

wrote:

This is a vo

Re: [VOTE] Release Commons VFS 2.0

On Nov 7, 2010, at 8:37 AM, Henning Schmiedehausen wrote:

> I would suggest that we (and in fact I started hacking around with
> this) release a vfs2 which is Java6+ only and fully generified.
> 

I'm not sure whether I agree. I think I mentioned that Java 7 has a new 
FileSystem abstraction. 
http://download.oracle.com/javase/7/docs/api/java/nio/file/package-summary.html.
  I  would think VFS 3.0 would remove the API and just provide FileSystem 
implementations. So I'm not sure how much effort is worth investing in V2.0 to 
move it to Java 6.

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

Re: [VOTE] Release Commons VFS 2.0

Ok, so change package, artifactid (group has already changed), and take the
opportunity to modernize the API unless you can do it in a compatible way in
a later 2.x release.  Otherwise you will need to go to 3.x.
On Nov 7, 2010 8:21 PM, "sebb"  wrote:
> I've just run Clirr on VFS 2.0 (had to cheat and change the Maven
> GroupId). There are quite a few errors, which mean that the code is
> not binary compatible:
>
> ERROR: 7012: org.apache.commons.vfs.FileContent: Method 'public
> boolean hasAttribute(java.lang.String)' has been added to an interface
> ERROR: 7012: org.apache.commons.vfs.FileContent: Method 'public void
> removeAttribute(java.lang.String)' has been added to an interface
> ERROR: 7012: org.apache.commons.vfs.FileSystem: Method 'public
> java.lang.String getRootURI()' has been added to an interface
> ERROR: 7009: org.apache.commons.vfs.FileSystemConfigBuilder:
> Accessibility of method 'public FileSystemConfigBuilder()' has been
> decreased from public to protected
> ERROR: 7012: org.apache.commons.vfs.FileSystemManager: Method 'public
> boolean hasProvider(java.lang.String)' has been added to an interface
> ERROR: 3003: org.apache.commons.vfs.FileSystemOptions: Added final
> modifier to class
> ERROR: 2001: org.apache.commons.vfs.Selectors: Changed from interface to
class
> ERROR: 6010: org.apache.commons.vfs.provider.HostFileNameParser$Authority:
> Accessibility of field hostName has been weakened from public to
> private
> ERROR: 6010: org.apache.commons.vfs.provider.HostFileNameParser$Authority:
> Accessibility of field password has been weakened from public to
> private
> ERROR: 6010: org.apache.commons.vfs.provider.HostFileNameParser$Authority:
> Accessibility of field port has been weakened from public to private
> ERROR: 6010: org.apache.commons.vfs.provider.HostFileNameParser$Authority:
> Accessibility of field scheme has been weakened from public to private
> ERROR: 6010: org.apache.commons.vfs.provider.HostFileNameParser$Authority:
> Accessibility of field userName has been weakened from public to
> private
> ERROR: 3003: org.apache.commons.vfs.util.UserAuthenticatorUtils: Added
> final modifier to class
> ERROR: 7009: org.apache.commons.vfs.util.UserAuthenticatorUtils:
> Accessibility of method 'public UserAuthenticatorUtils()' has been
> decreased from public to private
>
> On 5 November 2010 20:12, Ralph Goers  wrote:
>> This is a vote to release Apache Commons VFS 2.0.
>>
>> Since the last candidate the jdk version has been changed to 1.5 and the
requirement has been added to the web site main page. The test file for
LargeTarTestCase has been added to the test-data directory, greatly
improving the build time. Many of the messages from the test cases have been
removed.
>>
>> [ ] +1 release it
>> [ ] +0 go ahead I don't care
>> [ ] -1 no, do not release it because...
>>
>> Ralph
>>
>> tag:
https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project-2.0/
(revision 1031749)
>>
>> site: http://people.apache.org/~rgoers/commons-vfs/index.html
>>
>> The following artifacts have been staged to the Apache Nexus Staging
repository org.apache.commons-038 (u:rgoers, a:38.101.196.246)
https://repository.apache.org/content/repositories/orgapachecommons-038/
>>
>> commons-vfs-examples-2.0.jar
>> commons-vfs-examples-2.0.pom
>> commons-vfs-examples-2.0-javadoc.jar
>> commons-vfs-examples-2.0-sources.jar
>> commons-vfs-examples-2.0.jar.asc
>> commons-vfs-examples-2.0-sources.jar.asc
>> commons-vfs-examples-2.0.pom.asc
>> commons-vfs-examples-2.0-javadoc.jar.asc
>> commons-vfs-2.0-tests.jar
>> commons-vfs-2.0-test-sources.jar.asc
>> commons-vfs-2.0-sources.jar.asc
>> commons-vfs-2.0.jar
>> commons-vfs-2.0.pom
>> commons-vfs-2.0-test-sources.jar
>> commons-vfs-2.0-javadoc.jar
>> commons-vfs-2.0-javadoc.jar.asc
>> commons-vfs-2.0-tests.jar.asc
>> commons-vfs-2.0.pom.asc
>> commons-vfs-2.0-sources.jar
>> commons-vfs-2.0.jar.asc
>> commons-vfs-sandbox-2.0-tests.jar.asc
>> commons-vfs-sandbox-2.0-sources.jar
>> commons-vfs-sandbox-2.0-tests.jar
>> commons-vfs-sandbox-2.0-test-sources.jar.asc
>> commons-vfs-sandbox-2.0-sources.jar.asc
>> commons-vfs-sandbox-2.0.jar.asc
>> commons-vfs-sandbox-2.0-test-sources.jar
>> commons-vfs-sandbox-2.0-javadoc.jar
>> commons-vfs-sandbox-2.0.pom
>> commons-vfs-sandbox-2.0.jar
>> commons-vfs-sandbox-2.0-javadoc.jar.asc
>> commons-vfs-sandbox-2.0.pom.asc
>> commons-vfs-distribution-2.0-src.zip
>> commons-vfs-distribution-2.0.pom
>> commons-vfs-distribution-2.0-src.tar.gz.asc
>> commons-vfs-distribution-2.0-src.tar.gz
>> commons-vfs-distribution-2.0-bin.zip
>> commons-vfs-distribution-2.0-bin.zip.asc
>> commons-vfs-distribution-2.0-bin.tar.gz
>> commons-vfs-distribution-2.0-src.zip.asc
>> commons-vfs-distribution-2.0-bin.tar.gz.asc
>> commons-vfs-distribution-2.0.pom.asc
>> commons-vfs-project-2.0-site.xml.asc
>> commons-vfs-project-2.0.pom
>> commons-vfs-project-2.0-site.xml
>> commons-vfs-project-2.0.pom.asc
>
> --

Re: [VOTE] Release Commons VFS 2.0

2010-11-07 Thread sebb

I've just run Clirr on VFS 2.0 (had to cheat and change the Maven
GroupId). There are quite a few errors, which mean that the code is
not binary compatible:

ERROR: 7012: org.apache.commons.vfs.FileContent: Method 'public
boolean hasAttribute(java.lang.String)' has been added to an interface
ERROR: 7012: org.apache.commons.vfs.FileContent: Method 'public void
removeAttribute(java.lang.String)' has been added to an interface
ERROR: 7012: org.apache.commons.vfs.FileSystem: Method 'public
java.lang.String getRootURI()' has been added to an interface
ERROR: 7009: org.apache.commons.vfs.FileSystemConfigBuilder:
Accessibility of method 'public FileSystemConfigBuilder()' has been
decreased from public to protected
ERROR: 7012: org.apache.commons.vfs.FileSystemManager: Method 'public
boolean hasProvider(java.lang.String)' has been added to an interface
ERROR: 3003: org.apache.commons.vfs.FileSystemOptions: Added final
modifier to class
ERROR: 2001: org.apache.commons.vfs.Selectors: Changed from interface to class
ERROR: 6010: org.apache.commons.vfs.provider.HostFileNameParser$Authority:
Accessibility of field hostName has been weakened from public to
private
ERROR: 6010: org.apache.commons.vfs.provider.HostFileNameParser$Authority:
Accessibility of field password has been weakened from public to
private
ERROR: 6010: org.apache.commons.vfs.provider.HostFileNameParser$Authority:
Accessibility of field port has been weakened from public to private
ERROR: 6010: org.apache.commons.vfs.provider.HostFileNameParser$Authority:
Accessibility of field scheme has been weakened from public to private
ERROR: 6010: org.apache.commons.vfs.provider.HostFileNameParser$Authority:
Accessibility of field userName has been weakened from public to
private
ERROR: 3003: org.apache.commons.vfs.util.UserAuthenticatorUtils: Added
final modifier to class
ERROR: 7009: org.apache.commons.vfs.util.UserAuthenticatorUtils:
Accessibility of method 'public UserAuthenticatorUtils()' has been
decreased from public to private

On 5 November 2010 20:12, Ralph Goers  wrote:
> This is a vote to release Apache Commons VFS 2.0.
>
> Since the last candidate the jdk version has been changed to 1.5 and the 
> requirement has been added to the web site main page. The test file for 
> LargeTarTestCase has been added to the test-data directory, greatly improving 
> the build time. Many of the messages from the test cases have been removed.
>
> [ ] +1 release it
> [ ] +0 go ahead I don't care
> [ ] -1 no, do not release it because...
>
> Ralph
>
> tag: 
> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project-2.0/
>   (revision 1031749)
>
> site: http://people.apache.org/~rgoers/commons-vfs/index.html
>
> The following artifacts have been staged to the Apache Nexus Staging 
> repository org.apache.commons-038 (u:rgoers, a:38.101.196.246) 
> https://repository.apache.org/content/repositories/orgapachecommons-038/
>
> commons-vfs-examples-2.0.jar
> commons-vfs-examples-2.0.pom
> commons-vfs-examples-2.0-javadoc.jar
> commons-vfs-examples-2.0-sources.jar
> commons-vfs-examples-2.0.jar.asc
> commons-vfs-examples-2.0-sources.jar.asc
> commons-vfs-examples-2.0.pom.asc
> commons-vfs-examples-2.0-javadoc.jar.asc
> commons-vfs-2.0-tests.jar
> commons-vfs-2.0-test-sources.jar.asc
> commons-vfs-2.0-sources.jar.asc
> commons-vfs-2.0.jar
> commons-vfs-2.0.pom
> commons-vfs-2.0-test-sources.jar
> commons-vfs-2.0-javadoc.jar
> commons-vfs-2.0-javadoc.jar.asc
> commons-vfs-2.0-tests.jar.asc
> commons-vfs-2.0.pom.asc
> commons-vfs-2.0-sources.jar
> commons-vfs-2.0.jar.asc
> commons-vfs-sandbox-2.0-tests.jar.asc
> commons-vfs-sandbox-2.0-sources.jar
> commons-vfs-sandbox-2.0-tests.jar
> commons-vfs-sandbox-2.0-test-sources.jar.asc
> commons-vfs-sandbox-2.0-sources.jar.asc
> commons-vfs-sandbox-2.0.jar.asc
> commons-vfs-sandbox-2.0-test-sources.jar
> commons-vfs-sandbox-2.0-javadoc.jar
> commons-vfs-sandbox-2.0.pom
> commons-vfs-sandbox-2.0.jar
> commons-vfs-sandbox-2.0-javadoc.jar.asc
> commons-vfs-sandbox-2.0.pom.asc
> commons-vfs-distribution-2.0-src.zip
> commons-vfs-distribution-2.0.pom
> commons-vfs-distribution-2.0-src.tar.gz.asc
> commons-vfs-distribution-2.0-src.tar.gz
> commons-vfs-distribution-2.0-bin.zip
> commons-vfs-distribution-2.0-bin.zip.asc
> commons-vfs-distribution-2.0-bin.tar.gz
> commons-vfs-distribution-2.0-src.zip.asc
> commons-vfs-distribution-2.0-bin.tar.gz.asc
> commons-vfs-distribution-2.0.pom.asc
> commons-vfs-project-2.0-site.xml.asc
> commons-vfs-project-2.0.pom
> commons-vfs-project-2.0-site.xml
> commons-vfs-project-2.0.pom.asc

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

Re: Backwards incompatible changes and package names (was: Re: [VOTE] Release Commons VFS 2.0)

So you think that if there is no API break, then you don't bump major
version numbers?  So what about vfs 2.0?  Would you vote against it?
On Nov 7, 2010 7:18 PM, "Phil Steitz"  wrote:
> On 11/7/10 7:03 PM, sebb wrote:
>> On 7 November 2010 23:56, James Carman wrote:
>>> It's not a new subproject. It's just a new version of the same
>>> subproject. Trust me, I know about how the maven artifactId/package
>>> name/classpath stuff works. I've had this discussion many times
>>> before on this list. VFS is releasing its 2.0 release right now. If
>>> you want to make binary incompatible changes, it has to bump its major
>>> version number to 3 (along with artifactId/package change).
>>
>> Agreed.
>>
>>> This is
>>> why I've argued that VFS 2.0 should actually be 1.1, so that we don't
>>> introduce an inconsistency. The 2.x stuff should be in a vfs2
>>> package, per our naming conventions. In my opinion, it's not enough
>>
>> AFAIK, we have not agreed that package name suffix == major version
number.
>
> I used to be among those resisting this, but James' admirable
> persistence has won me over :) For the components that are likely to
> have any possibility of needing to appear twice on the classpath of
> an application at least, I think the following convention makes sense:
>
> Major version bump <-> compatibility break in API <-> change package
> name <-> change maven artifactId
>
> Bumping required JDK does not by itself force a compat break. I
> guess it is possible that so much can be accomplished without any
> breaks that a major version bump is warranted in some cases; but I
> have never seen that happen. So I am +1 on trying to adhere to this
> convention or at least explaining why not (in [math] for example we
> perhaps lamely argue that classpath multiplicity is not likely).
>
> Phil
>>
>>> different to merit a 2.0 release. Not enough has been done.
>>> Especially when you consider the version numbering madness that this
>>> is going to cause.
>>>
>>> On Sun, Nov 7, 2010 at 5:05 PM, Henning Schmiedehausen
>>>  wrote:
>>>> It will be a new sub-project. commons-vfs-2. and commons-vfs2-1.0
>>>> should be able to co-exist on the same classpath.
>>>>
>>>> For maven reasons, it is not desirable to have shift its
>>>> internal packages (because Maven does not understand that 2.0 and 3.0
>>>> are not compatible) and commons-vfs and commons-vfs2 should not use
>>>> use the same packages.
>>>>
>>>> So commons-vfs will continue to use org.apache.commons.vfs.* and
>>>> commons-vfs2 will use org.apache.commons.vfs2.*
>>>>
>>>> And it must be possible to have both versions on the classpath without
>>>> clashing.
>>>>
>>>> -h
>>>>
>>>>
>>>>
>>>>
>>>> On Sun, Nov 7, 2010 at 13:45, James Carman
wrote:
>>>>> If we release vfs2 and then we make changes that make it binary
>>>>> incompatible, then we have to go to 3 to do a new release. Am I
>>>>> missing something?
>>>>>
>>>>> On Sun, Nov 7, 2010 at 4:20 PM, Henning Schmiedehausen
>>>>>  wrote:
>>>>>> No, that would be a vfs2. With new package names and everything. It
>>>>>> would not be intended to be drop in compatible.
>>>>>>
>>>>>> -h
>>>>>>
>>>>>> On Sun, Nov 7, 2010 at 10:53, James Carman
wrote:
>>>>>>> Make sure you stay compatible or it'll have to go to 3.0
>>>>>>> On Nov 7, 2010 11:44 AM, "Gary Gregory"
>>>>>>> wrote:
>>>>>>>> On Nov 7, 2010, at 8:37, "Henning Schmiedehausen"<
>>>>>>> henn...@schmiedehausen.org> wrote:
>>>>>>>>
>>>>>>>>> I would suggest that we (and in fact I started hacking around with
>>>>>>>>> this) release a vfs2 which is Java6+ only and fully generified.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That's fine with me and my current work projects but I like a more
>>>>>>> iterative process where we can generify the code on java 5 for a
2.1. Then
>>>>>>> we can do a java 6 release.
>>>>>>>>
>>>>>>>> Gary
>>>>>>>>>
&g

Re: Backwards incompatible changes and package names (was: Re: [VOTE] Release Commons VFS 2.0)

2010-11-07 Thread Phil Steitz


On 11/7/10 7:03 PM, sebb wrote:

On 7 November 2010 23:56, James Carman  wrote:

It's not a new subproject.  It's just a new version of the same
subproject.  Trust me, I know about how the maven artifactId/package
name/classpath stuff works.  I've had this discussion many times
before on this list.  VFS is releasing its 2.0 release right now.  If
you want to make binary incompatible changes, it has to bump its major
version number to 3 (along with artifactId/package change).


Agreed.


This is
why I've argued that VFS 2.0 should actually be 1.1, so that we don't
introduce an inconsistency.  The 2.x stuff should be in a vfs2
package, per our naming conventions.  In my opinion, it's not enough


AFAIK, we have not agreed that package name suffix == major version number.


I used to be among those resisting this, but James' admirable 
persistence has won me over :) For the components that are likely to 
have any possibility of needing to appear twice on the classpath of 
an application at least, I think the following convention makes sense:


Major version bump <-> compatibility break in API <-> change package 
name <-> change maven artifactId


Bumping required JDK does not by itself force a compat break. I 
guess it is possible that so much can be accomplished without any 
breaks that a major version bump is warranted in some cases; but I 
have never seen that happen.  So I am +1 on trying to adhere to this 
convention or at least explaining why not (in [math] for example we 
perhaps lamely argue that classpath multiplicity is not likely).


Phil



different to merit a 2.0 release.  Not enough has been done.
Especially when you consider the version numbering madness that this
is going to cause.

On Sun, Nov 7, 2010 at 5:05 PM, Henning Schmiedehausen
  wrote:

It will be a new sub-project. commons-vfs-2.  and commons-vfs2-1.0
should be able to co-exist on the same classpath.

For maven reasons, it is not desirable to have  shift its
internal packages (because Maven does not understand that 2.0 and 3.0
are not compatible) and commons-vfs and commons-vfs2 should not use
use the same packages.

So commons-vfs will continue to use  org.apache.commons.vfs.* and
commons-vfs2 will use org.apache.commons.vfs2.*

And it must be possible to have both versions on the classpath without
clashing.

-h




On Sun, Nov 7, 2010 at 13:45, James Carman  wrote:

If we release vfs2 and then we make changes that make it binary
incompatible, then we have to go to 3 to do a new release.  Am I
missing something?

On Sun, Nov 7, 2010 at 4:20 PM, Henning Schmiedehausen
  wrote:

No, that would be a vfs2. With new package names and everything. It
would not be intended to be drop in compatible.

-h

On Sun, Nov 7, 2010 at 10:53, James Carman  wrote:

Make sure you stay compatible or it'll have to go to 3.0
On Nov 7, 2010 11:44 AM, "Gary Gregory"
wrote:

On Nov 7, 2010, at 8:37, "Henning Schmiedehausen"<

henn...@schmiedehausen.org>  wrote:



I would suggest that we (and in fact I started hacking around with
this) release a vfs2 which is Java6+ only and fully generified.



That's fine with me and my current work projects but I like a more

iterative process where we can generify the code on java 5 for a 2.1. Then
we can do a java 6 release.


Gary


-h

On Sun, Nov 7, 2010 at 08:22, Gary Gregory

wrote:

On Nov 7, 2010, at 7:45, "sebb"  wrote:


On 7 November 2010 02:17, Gary Gregory

wrote:

-Original Message-
From: Henning Schmiedehausen [mailto:henn...@schmiedehausen.org]
Sent: Saturday, November 06, 2010 19:03
To: Commons Developers List
Subject: Re: [VOTE] Release Commons VFS 2.0

+1

- I don't think that "has warnings" is a problem
- If deprecated APIs are still around, we can always remove them

later.


Yes, release early, release often.

I would encourage work to proceed immediately to implement this,

generics, and whatever Java 5 changes we can take advantage of.


I've already done the main annotations (@Override and @Deprecation)

I've started looking at generics.

There's rather a lot of changes to fix all the Java 1.5 warnings, so
it will probably have to be done in stages, but I can start committing
soon


Great news. It would be nice to release early release often a la XP with

a 2.1 themed release 'java 5 optimized'


Gary




Gary



-h

On Fri, Nov 5, 2010 at 13:12, Ralph Goers

wrote:

This is a vote to release Apache Commons VFS 2.0.

Since the last candidate the jdk version has been changed to 1.5 and

the

requirement has been added to the web site main page. The test file

for

LargeTarTestCase has been added to the test-data directory, greatly

improving

the build time. Many of the messages from the test cases have been

removed.


[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because...

Ralph

tag:

https://svn.apache.org

Re: Backwards incompatible changes and package names (was: Re: [VOTE] Release Commons VFS 2.0)

2010-11-07 Thread sebb

On 7 November 2010 23:56, James Carman  wrote:
> It's not a new subproject.  It's just a new version of the same
> subproject.  Trust me, I know about how the maven artifactId/package
> name/classpath stuff works.  I've had this discussion many times
> before on this list.  VFS is releasing its 2.0 release right now.  If
> you want to make binary incompatible changes, it has to bump its major
> version number to 3 (along with artifactId/package change).

Agreed.

> This is
> why I've argued that VFS 2.0 should actually be 1.1, so that we don't
> introduce an inconsistency.  The 2.x stuff should be in a vfs2
> package, per our naming conventions.  In my opinion, it's not enough

AFAIK, we have not agreed that package name suffix == major version number.

> different to merit a 2.0 release.  Not enough has been done.
> Especially when you consider the version numbering madness that this
> is going to cause.
>
> On Sun, Nov 7, 2010 at 5:05 PM, Henning Schmiedehausen
>  wrote:
>> It will be a new sub-project. commons-vfs-2. and commons-vfs2-1.0
>> should be able to co-exist on the same classpath.
>>
>> For maven reasons, it is not desirable to have  shift its
>> internal packages (because Maven does not understand that 2.0 and 3.0
>> are not compatible) and commons-vfs and commons-vfs2 should not use
>> use the same packages.
>>
>> So commons-vfs will continue to use  org.apache.commons.vfs.* and
>> commons-vfs2 will use org.apache.commons.vfs2.*
>>
>> And it must be possible to have both versions on the classpath without
>> clashing.
>>
>> -h
>>
>>
>>
>>
>> On Sun, Nov 7, 2010 at 13:45, James Carman  
>> wrote:
>>> If we release vfs2 and then we make changes that make it binary
>>> incompatible, then we have to go to 3 to do a new release.  Am I
>>> missing something?
>>>
>>> On Sun, Nov 7, 2010 at 4:20 PM, Henning Schmiedehausen
>>>  wrote:
>>>> No, that would be a vfs2. With new package names and everything. It
>>>> would not be intended to be drop in compatible.
>>>>
>>>> -h
>>>>
>>>> On Sun, Nov 7, 2010 at 10:53, James Carman  
>>>> wrote:
>>>>> Make sure you stay compatible or it'll have to go to 3.0
>>>>> On Nov 7, 2010 11:44 AM, "Gary Gregory" 
>>>>> wrote:
>>>>>> On Nov 7, 2010, at 8:37, "Henning Schmiedehausen" <
>>>>> henn...@schmiedehausen.org> wrote:
>>>>>>
>>>>>>> I would suggest that we (and in fact I started hacking around with
>>>>>>> this) release a vfs2 which is Java6+ only and fully generified.
>>>>>>>
>>>>>>
>>>>>> That's fine with me and my current work projects but I like a more
>>>>> iterative process where we can generify the code on java 5 for a 2.1. Then
>>>>> we can do a java 6 release.
>>>>>>
>>>>>> Gary
>>>>>>>
>>>>>>> -h
>>>>>>>
>>>>>>> On Sun, Nov 7, 2010 at 08:22, Gary Gregory 
>>>>>>> 
>>>>> wrote:
>>>>>>>> On Nov 7, 2010, at 7:45, "sebb"  wrote:
>>>>>>>>
>>>>>>>>> On 7 November 2010 02:17, Gary Gregory 
>>>>> wrote:
>>>>>>>>>>> -Original Message-
>>>>>>>>>>> From: Henning Schmiedehausen [mailto:henn...@schmiedehausen.org]
>>>>>>>>>>> Sent: Saturday, November 06, 2010 19:03
>>>>>>>>>>> To: Commons Developers List
>>>>>>>>>>> Subject: Re: [VOTE] Release Commons VFS 2.0
>>>>>>>>>>>
>>>>>>>>>>> +1
>>>>>>>>>>>
>>>>>>>>>>> - I don't think that "has warnings" is a problem
>>>>>>>>>>> - If deprecated APIs are still around, we can always remove them
>>>>> later.
>>>>>>>>>>
>>>>>>>>>> Yes, release early, release often.
>>>>>>>>>>
>>>>>>>>>> I would encourage work to proceed immediately to implement this,
>>>>> generics, and whatever Java 5 changes we can take advantage of.
>>>>>>>>>
>>>>>>>>>

Re: Backwards incompatible changes and package names (was: Re: [VOTE] Release Commons VFS 2.0)

It's not a new subproject.  It's just a new version of the same
subproject.  Trust me, I know about how the maven artifactId/package
name/classpath stuff works.  I've had this discussion many times
before on this list.  VFS is releasing its 2.0 release right now.  If
you want to make binary incompatible changes, it has to bump its major
version number to 3 (along with artifactId/package change).  This is
why I've argued that VFS 2.0 should actually be 1.1, so that we don't
introduce an inconsistency.  The 2.x stuff should be in a vfs2
package, per our naming conventions.  In my opinion, it's not enough
different to merit a 2.0 release.  Not enough has been done.
Especially when you consider the version numbering madness that this
is going to cause.

On Sun, Nov 7, 2010 at 5:05 PM, Henning Schmiedehausen
 wrote:
> It will be a new sub-project. commons-vfs-2. and commons-vfs2-1.0
> should be able to co-exist on the same classpath.
>
> For maven reasons, it is not desirable to have  shift its
> internal packages (because Maven does not understand that 2.0 and 3.0
> are not compatible) and commons-vfs and commons-vfs2 should not use
> use the same packages.
>
> So commons-vfs will continue to use  org.apache.commons.vfs.* and
> commons-vfs2 will use org.apache.commons.vfs2.*
>
> And it must be possible to have both versions on the classpath without
> clashing.
>
> -h
>
>
>
>
> On Sun, Nov 7, 2010 at 13:45, James Carman  wrote:
>> If we release vfs2 and then we make changes that make it binary
>> incompatible, then we have to go to 3 to do a new release.  Am I
>> missing something?
>>
>> On Sun, Nov 7, 2010 at 4:20 PM, Henning Schmiedehausen
>>  wrote:
>>> No, that would be a vfs2. With new package names and everything. It
>>> would not be intended to be drop in compatible.
>>>
>>> -h
>>>
>>> On Sun, Nov 7, 2010 at 10:53, James Carman  
>>> wrote:
>>>> Make sure you stay compatible or it'll have to go to 3.0
>>>> On Nov 7, 2010 11:44 AM, "Gary Gregory" 
>>>> wrote:
>>>>> On Nov 7, 2010, at 8:37, "Henning Schmiedehausen" <
>>>> henn...@schmiedehausen.org> wrote:
>>>>>
>>>>>> I would suggest that we (and in fact I started hacking around with
>>>>>> this) release a vfs2 which is Java6+ only and fully generified.
>>>>>>
>>>>>
>>>>> That's fine with me and my current work projects but I like a more
>>>> iterative process where we can generify the code on java 5 for a 2.1. Then
>>>> we can do a java 6 release.
>>>>>
>>>>> Gary
>>>>>>
>>>>>> -h
>>>>>>
>>>>>> On Sun, Nov 7, 2010 at 08:22, Gary Gregory 
>>>> wrote:
>>>>>>> On Nov 7, 2010, at 7:45, "sebb"  wrote:
>>>>>>>
>>>>>>>> On 7 November 2010 02:17, Gary Gregory 
>>>> wrote:
>>>>>>>>>> -Original Message-
>>>>>>>>>> From: Henning Schmiedehausen [mailto:henn...@schmiedehausen.org]
>>>>>>>>>> Sent: Saturday, November 06, 2010 19:03
>>>>>>>>>> To: Commons Developers List
>>>>>>>>>> Subject: Re: [VOTE] Release Commons VFS 2.0
>>>>>>>>>>
>>>>>>>>>> +1
>>>>>>>>>>
>>>>>>>>>> - I don't think that "has warnings" is a problem
>>>>>>>>>> - If deprecated APIs are still around, we can always remove them
>>>> later.
>>>>>>>>>
>>>>>>>>> Yes, release early, release often.
>>>>>>>>>
>>>>>>>>> I would encourage work to proceed immediately to implement this,
>>>> generics, and whatever Java 5 changes we can take advantage of.
>>>>>>>>
>>>>>>>> I've already done the main annotations (@Override and @Deprecation)
>>>>>>>>
>>>>>>>> I've started looking at generics.
>>>>>>>>
>>>>>>>> There's rather a lot of changes to fix all the Java 1.5 warnings, so
>>>>>>>> it will probably have to be done in stages, but I can start committing
>>>>>>>> soon
>>>>>>>
>>>>>>> Great news. It would be nice to re

Backwards incompatible changes and package names (was: Re: [VOTE] Release Commons VFS 2.0)

It will be a new sub-project. commons-vfs-2. and commons-vfs2-1.0
should be able to co-exist on the same classpath.

For maven reasons, it is not desirable to have  shift its
internal packages (because Maven does not understand that 2.0 and 3.0
are not compatible) and commons-vfs and commons-vfs2 should not use
use the same packages.

So commons-vfs will continue to use  org.apache.commons.vfs.* and
commons-vfs2 will use org.apache.commons.vfs2.*

And it must be possible to have both versions on the classpath without
clashing.

-h




On Sun, Nov 7, 2010 at 13:45, James Carman  wrote:
> If we release vfs2 and then we make changes that make it binary
> incompatible, then we have to go to 3 to do a new release.  Am I
> missing something?
>
> On Sun, Nov 7, 2010 at 4:20 PM, Henning Schmiedehausen
>  wrote:
>> No, that would be a vfs2. With new package names and everything. It
>> would not be intended to be drop in compatible.
>>
>> -h
>>
>> On Sun, Nov 7, 2010 at 10:53, James Carman  
>> wrote:
>>> Make sure you stay compatible or it'll have to go to 3.0
>>> On Nov 7, 2010 11:44 AM, "Gary Gregory" 
>>> wrote:
>>>> On Nov 7, 2010, at 8:37, "Henning Schmiedehausen" <
>>> henn...@schmiedehausen.org> wrote:
>>>>
>>>>> I would suggest that we (and in fact I started hacking around with
>>>>> this) release a vfs2 which is Java6+ only and fully generified.
>>>>>
>>>>
>>>> That's fine with me and my current work projects but I like a more
>>> iterative process where we can generify the code on java 5 for a 2.1. Then
>>> we can do a java 6 release.
>>>>
>>>> Gary
>>>>>
>>>>> -h
>>>>>
>>>>> On Sun, Nov 7, 2010 at 08:22, Gary Gregory 
>>> wrote:
>>>>>> On Nov 7, 2010, at 7:45, "sebb"  wrote:
>>>>>>
>>>>>>> On 7 November 2010 02:17, Gary Gregory 
>>> wrote:
>>>>>>>>> -Original Message-
>>>>>>>>> From: Henning Schmiedehausen [mailto:henn...@schmiedehausen.org]
>>>>>>>>> Sent: Saturday, November 06, 2010 19:03
>>>>>>>>> To: Commons Developers List
>>>>>>>>> Subject: Re: [VOTE] Release Commons VFS 2.0
>>>>>>>>>
>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>> - I don't think that "has warnings" is a problem
>>>>>>>>> - If deprecated APIs are still around, we can always remove them
>>> later.
>>>>>>>>
>>>>>>>> Yes, release early, release often.
>>>>>>>>
>>>>>>>> I would encourage work to proceed immediately to implement this,
>>> generics, and whatever Java 5 changes we can take advantage of.
>>>>>>>
>>>>>>> I've already done the main annotations (@Override and @Deprecation)
>>>>>>>
>>>>>>> I've started looking at generics.
>>>>>>>
>>>>>>> There's rather a lot of changes to fix all the Java 1.5 warnings, so
>>>>>>> it will probably have to be done in stages, but I can start committing
>>>>>>> soon
>>>>>>
>>>>>> Great news. It would be nice to release early release often a la XP with
>>> a 2.1 themed release 'java 5 optimized'
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>>>
>>>>>>>>> -h
>>>>>>>>>
>>>>>>>>> On Fri, Nov 5, 2010 at 13:12, Ralph Goers 
>>> wrote:
>>>>>>>>>> This is a vote to release Apache Commons VFS 2.0.
>>>>>>>>>>
>>>>>>>>>> Since the last candidate the jdk version has been changed to 1.5 and
>>> the
>>>>>>>>> requirement has been added to the web site main page. The test file
>>> for
>>>>>>>>> LargeTarTestCase has been added to the test-data directory, greatly
>>> improving
>>>>>>>>> the build time. Many of the messages from the test cases have been
>>> removed.
>>>>>>>>>>
>>>>>>>

Re: [VOTE] Release Commons VFS 2.0

If we release vfs2 and then we make changes that make it binary
incompatible, then we have to go to 3 to do a new release.  Am I
missing something?

On Sun, Nov 7, 2010 at 4:20 PM, Henning Schmiedehausen
 wrote:
> No, that would be a vfs2. With new package names and everything. It
> would not be intended to be drop in compatible.
>
> -h
>
> On Sun, Nov 7, 2010 at 10:53, James Carman  wrote:
>> Make sure you stay compatible or it'll have to go to 3.0
>> On Nov 7, 2010 11:44 AM, "Gary Gregory" 
>> wrote:
>>> On Nov 7, 2010, at 8:37, "Henning Schmiedehausen" <
>> henn...@schmiedehausen.org> wrote:
>>>
>>>> I would suggest that we (and in fact I started hacking around with
>>>> this) release a vfs2 which is Java6+ only and fully generified.
>>>>
>>>
>>> That's fine with me and my current work projects but I like a more
>> iterative process where we can generify the code on java 5 for a 2.1. Then
>> we can do a java 6 release.
>>>
>>> Gary
>>>>
>>>> -h
>>>>
>>>> On Sun, Nov 7, 2010 at 08:22, Gary Gregory 
>> wrote:
>>>>> On Nov 7, 2010, at 7:45, "sebb"  wrote:
>>>>>
>>>>>> On 7 November 2010 02:17, Gary Gregory 
>> wrote:
>>>>>>>> -Original Message-
>>>>>>>> From: Henning Schmiedehausen [mailto:henn...@schmiedehausen.org]
>>>>>>>> Sent: Saturday, November 06, 2010 19:03
>>>>>>>> To: Commons Developers List
>>>>>>>> Subject: Re: [VOTE] Release Commons VFS 2.0
>>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>> - I don't think that "has warnings" is a problem
>>>>>>>> - If deprecated APIs are still around, we can always remove them
>> later.
>>>>>>>
>>>>>>> Yes, release early, release often.
>>>>>>>
>>>>>>> I would encourage work to proceed immediately to implement this,
>> generics, and whatever Java 5 changes we can take advantage of.
>>>>>>
>>>>>> I've already done the main annotations (@Override and @Deprecation)
>>>>>>
>>>>>> I've started looking at generics.
>>>>>>
>>>>>> There's rather a lot of changes to fix all the Java 1.5 warnings, so
>>>>>> it will probably have to be done in stages, but I can start committing
>>>>>> soon
>>>>>
>>>>> Great news. It would be nice to release early release often a la XP with
>> a 2.1 themed release 'java 5 optimized'
>>>>>
>>>>> Gary
>>>>>
>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>>>
>>>>>>>> -h
>>>>>>>>
>>>>>>>> On Fri, Nov 5, 2010 at 13:12, Ralph Goers 
>> wrote:
>>>>>>>>> This is a vote to release Apache Commons VFS 2.0.
>>>>>>>>>
>>>>>>>>> Since the last candidate the jdk version has been changed to 1.5 and
>> the
>>>>>>>> requirement has been added to the web site main page. The test file
>> for
>>>>>>>> LargeTarTestCase has been added to the test-data directory, greatly
>> improving
>>>>>>>> the build time. Many of the messages from the test cases have been
>> removed.
>>>>>>>>>
>>>>>>>>> [ ] +1 release it
>>>>>>>>> [ ] +0 go ahead I don't care
>>>>>>>>> [ ] -1 no, do not release it because...
>>>>>>>>>
>>>>>>>>> Ralph
>>>>>>>>>
>>>>>>>>> tag:
>> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-
>>>>>>>> project-2.0/ (revision 1031749)
>>>>>>>>>
>>>>>>>>> site: http://people.apache.org/~rgoers/commons-vfs/index.html
>>>>>>>>>
>>>>>>>>> The following artifacts have been staged to the Apache Nexus Staging
>>>>>>>> repository org.apache.commons-038 (u:rgoers, a:38.101.196.246)
>>>>>>>>
>> https://repository.apache.org/conten

Re: [VOTE] Release Commons VFS 2.0

No, that would be a vfs2. With new package names and everything. It
would not be intended to be drop in compatible.

-h

On Sun, Nov 7, 2010 at 10:53, James Carman  wrote:
> Make sure you stay compatible or it'll have to go to 3.0
> On Nov 7, 2010 11:44 AM, "Gary Gregory" 
> wrote:
>> On Nov 7, 2010, at 8:37, "Henning Schmiedehausen" <
> henn...@schmiedehausen.org> wrote:
>>
>>> I would suggest that we (and in fact I started hacking around with
>>> this) release a vfs2 which is Java6+ only and fully generified.
>>>
>>
>> That's fine with me and my current work projects but I like a more
> iterative process where we can generify the code on java 5 for a 2.1. Then
> we can do a java 6 release.
>>
>> Gary
>>>
>>> -h
>>>
>>> On Sun, Nov 7, 2010 at 08:22, Gary Gregory 
> wrote:
>>>> On Nov 7, 2010, at 7:45, "sebb"  wrote:
>>>>
>>>>> On 7 November 2010 02:17, Gary Gregory 
> wrote:
>>>>>>> -----Original Message-
>>>>>>> From: Henning Schmiedehausen [mailto:henn...@schmiedehausen.org]
>>>>>>> Sent: Saturday, November 06, 2010 19:03
>>>>>>> To: Commons Developers List
>>>>>>> Subject: Re: [VOTE] Release Commons VFS 2.0
>>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>> - I don't think that "has warnings" is a problem
>>>>>>> - If deprecated APIs are still around, we can always remove them
> later.
>>>>>>
>>>>>> Yes, release early, release often.
>>>>>>
>>>>>> I would encourage work to proceed immediately to implement this,
> generics, and whatever Java 5 changes we can take advantage of.
>>>>>
>>>>> I've already done the main annotations (@Override and @Deprecation)
>>>>>
>>>>> I've started looking at generics.
>>>>>
>>>>> There's rather a lot of changes to fix all the Java 1.5 warnings, so
>>>>> it will probably have to be done in stages, but I can start committing
>>>>> soon
>>>>
>>>> Great news. It would be nice to release early release often a la XP with
> a 2.1 themed release 'java 5 optimized'
>>>>
>>>> Gary
>>>>
>>>>>
>>>>>> Gary
>>>>>>
>>>>>>>
>>>>>>> -h
>>>>>>>
>>>>>>> On Fri, Nov 5, 2010 at 13:12, Ralph Goers 
> wrote:
>>>>>>>> This is a vote to release Apache Commons VFS 2.0.
>>>>>>>>
>>>>>>>> Since the last candidate the jdk version has been changed to 1.5 and
> the
>>>>>>> requirement has been added to the web site main page. The test file
> for
>>>>>>> LargeTarTestCase has been added to the test-data directory, greatly
> improving
>>>>>>> the build time. Many of the messages from the test cases have been
> removed.
>>>>>>>>
>>>>>>>> [ ] +1 release it
>>>>>>>> [ ] +0 go ahead I don't care
>>>>>>>> [ ] -1 no, do not release it because...
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>> tag:
> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-
>>>>>>> project-2.0/ (revision 1031749)
>>>>>>>>
>>>>>>>> site: http://people.apache.org/~rgoers/commons-vfs/index.html
>>>>>>>>
>>>>>>>> The following artifacts have been staged to the Apache Nexus Staging
>>>>>>> repository org.apache.commons-038 (u:rgoers, a:38.101.196.246)
>>>>>>>
> https://repository.apache.org/content/repositories/orgapachecommons-038/
>>>>>>>>
>>>>>>>> commons-vfs-examples-2.0.jar
>>>>>>>> commons-vfs-examples-2.0.pom
>>>>>>>> commons-vfs-examples-2.0-javadoc.jar
>>>>>>>> commons-vfs-examples-2.0-sources.jar
>>>>>>>> commons-vfs-examples-2.0.jar.asc
>>>>>>>> commons-vfs-examples-2.0-sources.jar.asc
>>>>>>>> commons-vfs-examples-2.0.pom.asc
>>>>>>>> commons-vfs-examples-2.0-javadoc.jar.a

Re: [VOTE] Release Commons VFS 2.0

Make sure you stay compatible or it'll have to go to 3.0
On Nov 7, 2010 11:44 AM, "Gary Gregory" 
wrote:
> On Nov 7, 2010, at 8:37, "Henning Schmiedehausen" <
henn...@schmiedehausen.org> wrote:
>
>> I would suggest that we (and in fact I started hacking around with
>> this) release a vfs2 which is Java6+ only and fully generified.
>>
>
> That's fine with me and my current work projects but I like a more
iterative process where we can generify the code on java 5 for a 2.1. Then
we can do a java 6 release.
>
> Gary
>>
>> -h
>>
>> On Sun, Nov 7, 2010 at 08:22, Gary Gregory 
wrote:
>>> On Nov 7, 2010, at 7:45, "sebb"  wrote:
>>>
>>>> On 7 November 2010 02:17, Gary Gregory 
wrote:
>>>>>> -Original Message-
>>>>>> From: Henning Schmiedehausen [mailto:henn...@schmiedehausen.org]
>>>>>> Sent: Saturday, November 06, 2010 19:03
>>>>>> To: Commons Developers List
>>>>>> Subject: Re: [VOTE] Release Commons VFS 2.0
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> - I don't think that "has warnings" is a problem
>>>>>> - If deprecated APIs are still around, we can always remove them
later.
>>>>>
>>>>> Yes, release early, release often.
>>>>>
>>>>> I would encourage work to proceed immediately to implement this,
generics, and whatever Java 5 changes we can take advantage of.
>>>>
>>>> I've already done the main annotations (@Override and @Deprecation)
>>>>
>>>> I've started looking at generics.
>>>>
>>>> There's rather a lot of changes to fix all the Java 1.5 warnings, so
>>>> it will probably have to be done in stages, but I can start committing
>>>> soon
>>>
>>> Great news. It would be nice to release early release often a la XP with
a 2.1 themed release 'java 5 optimized'
>>>
>>> Gary
>>>
>>>>
>>>>> Gary
>>>>>
>>>>>>
>>>>>> -h
>>>>>>
>>>>>> On Fri, Nov 5, 2010 at 13:12, Ralph Goers 
wrote:
>>>>>>> This is a vote to release Apache Commons VFS 2.0.
>>>>>>>
>>>>>>> Since the last candidate the jdk version has been changed to 1.5 and
the
>>>>>> requirement has been added to the web site main page. The test file
for
>>>>>> LargeTarTestCase has been added to the test-data directory, greatly
improving
>>>>>> the build time. Many of the messages from the test cases have been
removed.
>>>>>>>
>>>>>>> [ ] +1 release it
>>>>>>> [ ] +0 go ahead I don't care
>>>>>>> [ ] -1 no, do not release it because...
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> tag:
https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-
>>>>>> project-2.0/ (revision 1031749)
>>>>>>>
>>>>>>> site: http://people.apache.org/~rgoers/commons-vfs/index.html
>>>>>>>
>>>>>>> The following artifacts have been staged to the Apache Nexus Staging
>>>>>> repository org.apache.commons-038 (u:rgoers, a:38.101.196.246)
>>>>>>
https://repository.apache.org/content/repositories/orgapachecommons-038/
>>>>>>>
>>>>>>> commons-vfs-examples-2.0.jar
>>>>>>> commons-vfs-examples-2.0.pom
>>>>>>> commons-vfs-examples-2.0-javadoc.jar
>>>>>>> commons-vfs-examples-2.0-sources.jar
>>>>>>> commons-vfs-examples-2.0.jar.asc
>>>>>>> commons-vfs-examples-2.0-sources.jar.asc
>>>>>>> commons-vfs-examples-2.0.pom.asc
>>>>>>> commons-vfs-examples-2.0-javadoc.jar.asc
>>>>>>> commons-vfs-2.0-tests.jar
>>>>>>> commons-vfs-2.0-test-sources.jar.asc
>>>>>>> commons-vfs-2.0-sources.jar.asc
>>>>>>> commons-vfs-2.0.jar
>>>>>>> commons-vfs-2.0.pom
>>>>>>> commons-vfs-2.0-test-sources.jar
>>>>>>> commons-vfs-2.0-javadoc.jar
>>>>>>> commons-vfs-2.0-javadoc.jar.asc
>>>>>>> commons-vfs-2.0-tests.jar.asc
&g

Re: [VOTE] Release Commons VFS 2.0

2010-11-07 Thread Gary Gregory

On Nov 7, 2010, at 8:37, "Henning Schmiedehausen"  
wrote:

> I would suggest that we (and in fact I started hacking around with
> this) release a vfs2 which is Java6+ only and fully generified.
> 

That's fine with me and my current work projects but I like a more iterative 
process where we can generify the code on java 5 for a 2.1. Then we can do a 
java 6 release. 

Gary
> 
> -h
> 
> On Sun, Nov 7, 2010 at 08:22, Gary Gregory  
> wrote:
>> On Nov 7, 2010, at 7:45, "sebb"  wrote:
>> 
>>> On 7 November 2010 02:17, Gary Gregory  wrote:
>>>>> -Original Message-
>>>>> From: Henning Schmiedehausen [mailto:henn...@schmiedehausen.org]
>>>>> Sent: Saturday, November 06, 2010 19:03
>>>>> To: Commons Developers List
>>>>> Subject: Re: [VOTE] Release Commons VFS 2.0
>>>>> 
>>>>> +1
>>>>> 
>>>>> - I don't think that "has warnings" is a problem
>>>>> - If deprecated APIs are still around, we can always remove them later.
>>>> 
>>>> Yes, release early, release often.
>>>> 
>>>> I would encourage work to proceed immediately to implement this, generics, 
>>>> and whatever Java 5 changes we can take advantage of.
>>> 
>>> I've already done the main annotations (@Override and @Deprecation)
>>> 
>>> I've started looking at generics.
>>> 
>>> There's rather a lot of changes to fix all the Java 1.5 warnings, so
>>> it will probably have to be done in stages, but I can start committing
>>> soon
>> 
>> Great news. It would be nice to release  early release often a la XP with a 
>> 2.1 themed release 'java 5 optimized'
>> 
>> Gary
>> 
>>> 
>>>> Gary
>>>> 
>>>>> 
>>>>> -h
>>>>> 
>>>>> On Fri, Nov 5, 2010 at 13:12, Ralph Goers  
>>>>> wrote:
>>>>>> This is a vote to release Apache Commons VFS 2.0.
>>>>>> 
>>>>>> Since the last candidate the jdk version has been changed to 1.5 and the
>>>>> requirement has been added to the web site main page. The test file for
>>>>> LargeTarTestCase has been added to the test-data directory, greatly 
>>>>> improving
>>>>> the build time. Many of the messages from the test cases have been 
>>>>> removed.
>>>>>> 
>>>>>> [ ] +1 release it
>>>>>> [ ] +0 go ahead I don't care
>>>>>> [ ] -1 no, do not release it because...
>>>>>> 
>>>>>> Ralph
>>>>>> 
>>>>>> tag: 
>>>>>> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-
>>>>> project-2.0/  (revision 1031749)
>>>>>> 
>>>>>> site: http://people.apache.org/~rgoers/commons-vfs/index.html
>>>>>> 
>>>>>> The following artifacts have been staged to the Apache Nexus Staging
>>>>> repository org.apache.commons-038 (u:rgoers, a:38.101.196.246)
>>>>> https://repository.apache.org/content/repositories/orgapachecommons-038/
>>>>>> 
>>>>>> commons-vfs-examples-2.0.jar
>>>>>> commons-vfs-examples-2.0.pom
>>>>>> commons-vfs-examples-2.0-javadoc.jar
>>>>>> commons-vfs-examples-2.0-sources.jar
>>>>>> commons-vfs-examples-2.0.jar.asc
>>>>>> commons-vfs-examples-2.0-sources.jar.asc
>>>>>> commons-vfs-examples-2.0.pom.asc
>>>>>> commons-vfs-examples-2.0-javadoc.jar.asc
>>>>>> commons-vfs-2.0-tests.jar
>>>>>> commons-vfs-2.0-test-sources.jar.asc
>>>>>> commons-vfs-2.0-sources.jar.asc
>>>>>> commons-vfs-2.0.jar
>>>>>> commons-vfs-2.0.pom
>>>>>> commons-vfs-2.0-test-sources.jar
>>>>>> commons-vfs-2.0-javadoc.jar
>>>>>> commons-vfs-2.0-javadoc.jar.asc
>>>>>> commons-vfs-2.0-tests.jar.asc
>>>>>> commons-vfs-2.0.pom.asc
>>>>>> commons-vfs-2.0-sources.jar
>>>>>> commons-vfs-2.0.jar.asc
>>>>>> commons-vfs-sandbox-2.0-tests.jar.asc
>>>>>> commons-vfs-sandbox-2.0-sources.jar
>>>>>> commons-vfs-sandbox-2.0-tests.jar
>>>>>> commons-vfs-sandbox-2.0-test-sou

Re: [VOTE] Release Commons VFS 2.0