You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ralph Goers <ra...@dslextreme.com> on 2010/11/04 00:22:30 UTC
[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
Re: [VOTE] Release Commons VFS 2.0
Posted by Jörg Schaible <jo...@gmx.de>.
Jörg Schaible wrote:
> Hi Ralph,
>
> Ralph Goers wrote:
>
>> 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...
>
> Minor nitpicks:
>
> 1/ commons-vfs-parent.pom declares own snapshot repositories. Is it still
> necessary? Such declarations are not recommended by Maven folks anyway.
> 2/ commons-vfs.pom contains a comment that the TestSuites are not
> executed. This is no longer true for the version of the used surefire
> plugin.
> 3/ http://people.apache.org/~rgoers/commons-vfs/download.html:
> Something went wrong with the table.
> 4/ This page recommends also Maven 2.1.0 to build although this version is
> considered as broken. Either recommend 2.0.11 (building with JDK 1.4) or
> >= 2.2.1.
> 5/ The table on this page lists httpclient 2.0, but we use 3.0. Bascially
> we could also provide links to the generated dependency pages of the
> submodules.
The page also contains a link to "nightly builds" with 3 year old artifacts.
> 6/ The dependency report of the core module declares httpclient as
> required. The dependency report of the sandbox declares the core vfs as
> required, but httpclient as optional. Either it's optional in core or
> required in the sandbox.
> 7/ New FTPS support is not even mentioned on
> http://people.apache.org/~rgoers/commons-vfs/filesystems.html as
> enhancement of FTP provider (see VFS-264).
> 8/ The same page lists mime FS twice (as supported FS and available from
> sandbox, while CIFS support is listed only once). Both should be handled
> the same.
> 9/ http://people.apache.org/~rgoers/commons-vfs/3rdparty.html lists loopy
> as external plugin. While it is not clear that it still works with VFS
> 2.0, there are more providers listed in the Wiki (icnl. Loopy):
> http://wiki.apache.org/commons/VFS. Maybe it is better to drop the page
> completely, create an own section in the Wiki for 3rd party plugins and
> have a link to this Wiki page from
> http://people.apache.org/~rgoers/commons- vfs/filesystems.html.
The news paragraph in commons-vfs home is outdated.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
Posted by Jörg Schaible <jo...@gmx.de>.
Jörg Schaible wrote:
[snip]
> A test building vfs from the source tarballs with my compiler zoo will
> follow.
Cannot do this anymore, files no longer available.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Ralph,
Ralph Goers wrote:
> 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...
Minor nitpicks:
1/ commons-vfs-parent.pom declares own snapshot repositories. Is it still
necessary? Such declarations are not recommended by Maven folks anyway.
2/ commons-vfs.pom contains a comment that the TestSuites are not executed.
This is no longer true for the version of the used surefire plugin.
3/ http://people.apache.org/~rgoers/commons-vfs/download.html: Something
went wrong with the table.
4/ This page recommends also Maven 2.1.0 to build although this version is
considered as broken. Either recommend 2.0.11 (building with JDK 1.4) or >=
2.2.1.
5/ The table on this page lists httpclient 2.0, but we use 3.0. Bascially we
could also provide links to the generated dependency pages of the
submodules.
6/ The dependency report of the core module declares httpclient as required.
The dependency report of the sandbox declares the core vfs as required, but
httpclient as optional. Either it's optional in core or required in the
sandbox.
7/ New FTPS support is not even mentioned on
http://people.apache.org/~rgoers/commons-vfs/filesystems.html as enhancement
of FTP provider (see VFS-264).
8/ The same page lists mime FS twice (as supported FS and available from
sandbox, while CIFS support is listed only once). Both should be handled the
same.
9/ http://people.apache.org/~rgoers/commons-vfs/3rdparty.html lists loopy as
external plugin. While it is not clear that it still works with VFS 2.0,
there are more providers listed in the Wiki (icnl. Loopy):
http://wiki.apache.org/commons/VFS. Maybe it is better to drop the page
completely, create an own section in the Wiki for 3rd party plugins and have
a link to this Wiki page from http://people.apache.org/~rgoers/commons-
vfs/filesystems.html.
A test building vfs from the source tarballs with my compiler zoo will
follow.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [VOTE] Release Commons VFS 2.0
Posted by Ronan KERDUDOU - VirageGroup <rk...@viragegroup.com>.
"+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
rk@viragegroup.com
www.viragegroup.com
-----Message d'origine-----
De�: Ralph Goers [mailto:ralph.goers@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
Posted by Brian Fox <br...@infinity.nu>.
I think I'll add another standard descriptor to the default bundle,
and then projects can opt for the tar.gz simply by setting a property.
I'm hesitant to start causing all projects to generate two copies of
the source archives by default, since many of them seem happy with
just a zip.
On Thu, Nov 4, 2010 at 2:28 PM, Henning Schmiedehausen
<he...@schmiedehausen.org> wrote:
> That makes lots of sense to standardize.
>
> So, if we standardize, IMHO we should standardize on provide both. It
> really is only a single line in the default assembly. No big deal.
>
> -h
>
>
>
> On Thu, Nov 4, 2010 at 12:59, Brian Fox <br...@infinity.nu> wrote:
>>>>
>>>> We need both zips and tars of the sources for the actual release (what we push to dist/).
>>
>>> Brian wants to know why. It certainly isn't mandated by the board.
>>
>> That gets me into trouble a lot of times. "Because we always have done
>> it that way" is my favorite opportunity to ask why. You guys are
>> certainly free to make tar.gz's if you want and I have nothing to say
>> about it. However here's why I ask:
>>
>> We've tried to setup a standard profile in the apache pom that will
>> meet the basic requirements for any Apache project using Maven to meet
>> the things like LICENSE/NOTICE and signed source archives. So far, the
>> zip has been sufficient for all the projects using it. I can't see any
>> value in duplicating the source archive as a tar.gz because as I
>> mentioned, it shouldn't normally have binaries and therefore the
>> permissions are irrelevant. Since it's unlikely we would want to
>> enable this for all projects, it means you would have to extend the
>> profile in a way that causes you to diverge from the norm and it will
>> make it harder to consume standard changes down the road. (in fact
>> most of the troubles we've seen getting vfs released were related to
>> undoing the legacy profile and using the standard one).
>>
>> So I wonder why a tar.gz sourceball is needed and is it worth it to
>> diverge just for that.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
Posted by Henning Schmiedehausen <he...@schmiedehausen.org>.
That makes lots of sense to standardize.
So, if we standardize, IMHO we should standardize on provide both. It
really is only a single line in the default assembly. No big deal.
-h
On Thu, Nov 4, 2010 at 12:59, Brian Fox <br...@infinity.nu> wrote:
>>>
>>> We need both zips and tars of the sources for the actual release (what we push to dist/).
>
>> Brian wants to know why. It certainly isn't mandated by the board.
>
> That gets me into trouble a lot of times. "Because we always have done
> it that way" is my favorite opportunity to ask why. You guys are
> certainly free to make tar.gz's if you want and I have nothing to say
> about it. However here's why I ask:
>
> We've tried to setup a standard profile in the apache pom that will
> meet the basic requirements for any Apache project using Maven to meet
> the things like LICENSE/NOTICE and signed source archives. So far, the
> zip has been sufficient for all the projects using it. I can't see any
> value in duplicating the source archive as a tar.gz because as I
> mentioned, it shouldn't normally have binaries and therefore the
> permissions are irrelevant. Since it's unlikely we would want to
> enable this for all projects, it means you would have to extend the
> profile in a way that causes you to diverge from the norm and it will
> make it harder to consume standard changes down the road. (in fact
> most of the troubles we've seen getting vfs released were related to
> undoing the legacy profile and using the standard one).
>
> So I wonder why a tar.gz sourceball is needed and is it worth it to
> diverge just for that.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
Posted by Phil Steitz <ph...@gmail.com>.
On Nov 4, 2010, at 7:33 PM, Mark Thomas <ma...@apache.org> wrote:
> On 04/11/2010 14:21, Brian Fox wrote:
>>> How about users that want to work with sources on platforms where CRLF
>>> endings are a PITA?
>>
>> Simply tar.gz'ing the files changes the line endings?
>
> No. Tomcat's build processes are more sophisticated than that. Files in
> the -src.zip have CRLF endings, files in the -src.tar.gz have LF endings.
Last I checked, Maven did the same thing. Could be that has since been broken. Will check this...
Phil
> Mark
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
Posted by Mark Thomas <ma...@apache.org>.
On 04/11/2010 14:21, Brian Fox wrote:
>> How about users that want to work with sources on platforms where CRLF
>> endings are a PITA?
>
> Simply tar.gz'ing the files changes the line endings?
No. Tomcat's build processes are more sophisticated than that. Files in
the -src.zip have CRLF endings, files in the -src.tar.gz have LF endings.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
Posted by Brian Fox <br...@infinity.nu>.
> How about users that want to work with sources on platforms where CRLF
> endings are a PITA?
Simply tar.gz'ing the files changes the line endings?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
Posted by sebb <se...@gmail.com>.
On 4 November 2010 17:05, Mark Thomas <ma...@apache.org> wrote:
> On 04/11/2010 12:59, Brian Fox wrote:
>> So I wonder why a tar.gz sourceball is needed and is it worth it to
>> diverge just for that.
>
> How about users that want to work with sources on platforms where CRLF
> endings are a PITA?
>
> Tomcat distributes sources in .zip and .tar.gz versions for exactly this
> reason.
Also, if there were no tgz source, then a Unix user would need to
download tgz binary and zip source.
Potentially confusing.
Tar.gz also tends to provide better compression.
> Mark
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
Posted by Mark Thomas <ma...@apache.org>.
On 04/11/2010 12:59, Brian Fox wrote:
> So I wonder why a tar.gz sourceball is needed and is it worth it to
> diverge just for that.
How about users that want to work with sources on platforms where CRLF
endings are a PITA?
Tomcat distributes sources in .zip and .tar.gz versions for exactly this
reason.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
Posted by Brian Fox <br...@infinity.nu>.
>>
>> We need both zips and tars of the sources for the actual release (what we push to dist/).
> Brian wants to know why. It certainly isn't mandated by the board.
That gets me into trouble a lot of times. "Because we always have done
it that way" is my favorite opportunity to ask why. You guys are
certainly free to make tar.gz's if you want and I have nothing to say
about it. However here's why I ask:
We've tried to setup a standard profile in the apache pom that will
meet the basic requirements for any Apache project using Maven to meet
the things like LICENSE/NOTICE and signed source archives. So far, the
zip has been sufficient for all the projects using it. I can't see any
value in duplicating the source archive as a tar.gz because as I
mentioned, it shouldn't normally have binaries and therefore the
permissions are irrelevant. Since it's unlikely we would want to
enable this for all projects, it means you would have to extend the
profile in a way that causes you to diverge from the norm and it will
make it harder to consume standard changes down the road. (in fact
most of the troubles we've seen getting vfs released were related to
undoing the legacy profile and using the standard one).
So I wonder why a tar.gz sourceball is needed and is it worth it to
diverge just for that.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
Posted by Ralph Goers <ra...@dslextreme.com>.
On Nov 4, 2010, at 8:19 AM, Phil Steitz wrote:
> On 11/4/10 9:42 AM, Brian Fox wrote:
>> On Wed, Nov 3, 2010 at 8:25 PM, sebb<se...@gmail.com> wrote:
>>> On 3 November 2010 23:22, Ralph Goers<ra...@dslextreme.com> wrote:
>>>> This is a vote to release Apache Commons VFS 2.0.
>>> -1 There does not appear to be a tar.gz version of
>>> commons-vfs-project-2.0-source-release.zip
>>
>> The source archives should be taken care of by the standard
>> apache-release profile defined in the Apache pom. This is what we put
>> together to make it possible for all maven projects at apache to
>> easily meet the source archive standards. We currently do not produce
>> tar.gz archives of the sources, just zips. I don't think both are
>> required since it's a waste of storage and tar.gz is usually needed
>> when you have to preserve binary permissions. We're talking about
>> sources here so a zip should be sufficient.
>
> We need both zips and tars of the sources for the actual release (what we push to dist/).
>
> Phil
Brian wants to know why. It certainly isn't mandated by the board.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
Posted by Phil Steitz <ph...@gmail.com>.
On 11/4/10 9:42 AM, Brian Fox wrote:
> On Wed, Nov 3, 2010 at 8:25 PM, sebb<se...@gmail.com> wrote:
>> On 3 November 2010 23:22, Ralph Goers<ra...@dslextreme.com> wrote:
>>> This is a vote to release Apache Commons VFS 2.0.
>> -1 There does not appear to be a tar.gz version of
>> commons-vfs-project-2.0-source-release.zip
>
> The source archives should be taken care of by the standard
> apache-release profile defined in the Apache pom. This is what we put
> together to make it possible for all maven projects at apache to
> easily meet the source archive standards. We currently do not produce
> tar.gz archives of the sources, just zips. I don't think both are
> required since it's a waste of storage and tar.gz is usually needed
> when you have to preserve binary permissions. We're talking about
> sources here so a zip should be sufficient.
We need both zips and tars of the sources for the actual release
(what we push to dist/).
Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
Posted by Brian Fox <br...@infinity.nu>.
On Wed, Nov 3, 2010 at 8:25 PM, sebb <se...@gmail.com> wrote:
> On 3 November 2010 23:22, Ralph Goers <ra...@dslextreme.com> wrote:
>> This is a vote to release Apache Commons VFS 2.0.
> -1 There does not appear to be a tar.gz version of
> commons-vfs-project-2.0-source-release.zip
The source archives should be taken care of by the standard
apache-release profile defined in the Apache pom. This is what we put
together to make it possible for all maven projects at apache to
easily meet the source archive standards. We currently do not produce
tar.gz archives of the sources, just zips. I don't think both are
required since it's a waste of storage and tar.gz is usually needed
when you have to preserve binary permissions. We're talking about
sources here so a zip should be sufficient.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
Posted by sebb <se...@gmail.com>.
On 3 November 2010 23:22, Ralph Goers <ra...@dslextreme.com> wrote:
> 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/
core/src/test/java/org/apache/commons/vfs/provider/tar/test/LargeTarTestCase.java
does not have an AL header (nor does it have svn:eol-style native)
>
> 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
>
-1 The non-Maven binary archives are empty apart from N&L files
-1 There does not appear to be a tar.gz version of
commons-vfs-project-2.0-source-release.zip
Not a blocker, but should be fixed:
* The DOAP file should not be in the source archive(s).
* The javadoc jars don't have NOTICE and LICENSE files.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org