You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Mario Ivankovits <ma...@ops.co.at> on 2005/12/05 21:28:15 UTC
[vfs][REVOTE] release version 1.0
Hi!
Even if the last vode passed I decided to restart the voting based on RC7.
RC7 is now using commons-net 1.4.1 and built using the jdk1.3 compiler
also some rearrangements have taken place to accommodate to our
guidlines (e.g. include xdocs into src distribution)
As previously posted please find the RC7 at
http://people.apache.org/~imario/vfs
Please vote:
[ ] +1 I support this release and am willing to help
[ ] +0 I support this release but am unable to help
[ ] -0 I do not support this release
[ ] -1 I do not support this release, and here are my reasons
Sorry if this revote bothers you, but after all what happens in the last
days on our mailinglist I thought if would be better to do so.
Thanks!
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs] Interfaces Re: [vfs][REVOTE] release version 1.0
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Stephen!
> Another query, are you happy that you will never want to add a method
> to FileObject, or any other interface in VFS?
No.
> Alternatively define FileObject (and possibly other interfaces) as an
> abstract class now, then you don't have the same problems.
There is already a AbstractFileObject (the same for other interfaces
too). Every developer is hold to extend from AbstractFileObject instead
of FileObject as it provides some environmental work for you.
But when it comes to decoration I'll be happy with the FileObject
interfaces alone. E.g. I plan to get the caching stuff out of
AbstractFileObject and put it into an CachingFileObjectDecorator - then
I cant use the AbstractfileObject but would like to use the FileObject
interface - maybe - this decision hasnt been made now.
> At the very least, if you think that you might change the interface,
> you should add in the javadoc that it might change in v2.0.
Isnt this always the case with commons? Every major release is allowed
to introduce non backward compatible changes as long as there existed a
migration path?
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[vfs] Interfaces Re: [vfs][REVOTE] release version 1.0
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Another query, are you happy that you will never want to add a method to
FileObject, or any other interface in VFS?
Commons tends to be strict about not allowing changes like this.
Possible solutions to adding a method in the future are
- to create a FileObject2 subinterface
- to go to version 2.0
Alternatively define FileObject (and possibly other interfaces) as an
abstract class now, then you don't have the same problems.
At the very least, if you think that you might change the interface, you
should add in the javadoc that it might change in v2.0.
Stephen
Mario Ivankovits wrote:
> Hi!
>
> Even if the last vode passed I decided to restart the voting based on RC7.
> RC7 is now using commons-net 1.4.1 and built using the jdk1.3 compiler
> also some rearrangements have taken place to accommodate to our
> guidlines (e.g. include xdocs into src distribution)
>
> As previously posted please find the RC7 at
> http://people.apache.org/~imario/vfs
>
> Please vote:
>
> [ ] +1 I support this release and am willing to help
> [ ] +0 I support this release but am unable to help
> [ ] -0 I do not support this release
> [ ] -1 I do not support this release, and here are my reasons
>
>
> Sorry if this revote bothers you, but after all what happens in the last
> days on our mailinglist I thought if would be better to do so.
>
> Thanks!
> Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs][REVOTE] release version 1.0
Posted by Niall Pemberton <ni...@gmail.com>.
On 12/6/05, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi Niall!
> > The question is, was it your intention to start running the tests in
> > gump? Presumably, they were excluded from the maven-generated ant
> > build file because of the difficulties in running them in gump. Maybe
> > you should revert back to excluding them again?
> >
> My intention was to have consistency between maven and ant build. And
> thus reenabled the tests and regenerated build.xml.
>
> If its possible to drop in my vmware test server it would be great,
> though if its not possible to disable the tests through the gump
> descriptor I can revert back for sure.
OK, you may want to get better "gump advice" than from me, I've just
picked up a little bit of gump knowledge from fixing issues on other
projects. Having said that....
When maven is generating the ant build file its picking up the
"maven.ant.excludeTests" from your project.properties and putting an
excludes element in the ant file - so with the way it is currently,
there isn't a property you can specify in gump to "override" that.
If your intention is to have working ant and maven builds available
for users of vfs (i.e. nothing to do with gump) then what you could do
is leave your build.xml as it is and add a new ant build file just for
gump (e.g. build-gump.xml) that doesn't run the tests.
If you do want gump to run the tests - but just exclude the one(s)
which use a server then you need to either do something smarter in
maven or do your gump version ant build file by hand.
Niall
> ---
> Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs][REVOTE] release version 1.0
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Niall!
> The question is, was it your intention to start running the tests in
> gump? Presumably, they were excluded from the maven-generated ant
> build file because of the difficulties in running them in gump. Maybe
> you should revert back to excluding them again?
>
My intention was to have consistency between maven and ant build. And
thus reenabled the tests and regenerated build.xml.
If its possible to drop in my vmware test server it would be great,
though if its not possible to disable the tests through the gump
descriptor I can revert back for sure.
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs][REVOTE] release version 1.0
Posted by Niall Pemberton <ni...@gmail.com>.
On 12/6/05, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi Niall!
> > From what I can see the <exclude name="**/*.java"> would have
> > prevented any tests being included and removing that is when the tests
> > started failing. So in summary my guess is the tests never worked in
> > gump.
> >
> For sure, and they wont work anyway as there is no test server available
> for gump.
>
> > Looking at the gump config for vfs, I think the test classes dir is
> > missing from the classpath, so I have added it.
>
> Thank you very much!
No problem, although looks like fixing that one issue was just the tip
of the iceberg!
> > Hopefully that should
> > sort out the ClassNotFound exception.
> >
> As I said, tests should still fail - is there now a vmware available
> where I can put my test-server?
> I already use vmware and thus have a vmware image?
OK, the gump change has been picked up and the ClassNotFoundException
has gone, but its now failing because gump needs to be configured for
all the test properties you have defined in your project.properties
file - for example "test.basedir".
However its not worth fixing these issues if at the end of the day you
can't get whatever server you need up and working - you'll have to ask
the "gump experts" about vmware and running your test-server to work
this out.
Also, since all tests were specifically excluded from the maven
generated ant file...
http://svn.apache.org/viewcvs.cgi?rev=147806&view=rev
...IMO it would be better to not modify the file (i.e. build.xml)
directly, but change the "maven.ant.excludeTests" in
project.properties and re-generate it.
The question is, was it your intention to start running the tests in
gump? Presumably, they were excluded from the maven-generated ant
build file because of the difficulties in running them in gump. Maybe
you should revert back to excluding them again?
Niall
> ---
> Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs][REVOTE] release version 1.0
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Niall!
> From what I can see the <exclude name="**/*.java"> would have
> prevented any tests being included and removing that is when the tests
> started failing. So in summary my guess is the tests never worked in
> gump.
>
For sure, and they wont work anyway as there is no test server available
for gump.
> Looking at the gump config for vfs, I think the test classes dir is
> missing from the classpath, so I have added it.
Thank you very much!
> Hopefully that should
> sort out the ClassNotFound exception.
>
As I said, tests should still fail - is there now a vmware available
where I can put my test-server?
I already use vmware and thus have a vmware image?
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs][REVOTE] release version 1.0
Posted by Niall Pemberton <ni...@gmail.com>.
On 12/5/05, Dion Gillard <di...@gmail.com> wrote:
> Does this mean we need to re-gen the ant build file?
>
> On 12/6/05, Mario Ivankovits <ma...@ops.co.at> wrote:
> > Stephen Colebourne wrote:
> > > What is the cause of the current GUMP test failure??
> > >
It looks to me like the vfs tests were not being run until this change
in the build,xml:
http://tinyurl.com/da6tr
>From what I can see the <exclude name="**/*.java"> would have
prevented any tests being included and removing that is when the tests
started failing. So in summary my guess is the tests never worked in
gump.
Looking at the gump config for vfs, I think the test classes dir is
missing from the classpath, so I have added it. Hopefully that should
sort out the ClassNotFound exception. I'll check it tommorrow, but if
it doesn't, apologies in advance for interfering.
Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs][REVOTE] release version 1.0
Posted by Dion Gillard <di...@gmail.com>.
Does this mean we need to re-gen the ant build file?
On 12/6/05, Mario Ivankovits <ma...@ops.co.at> wrote:
> Stephen Colebourne wrote:
> > What is the cause of the current GUMP test failure??
> >
> ClassNotFoundException of one of our test classes.
> internal-test:
> [mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons/vfs/target/test-reports
> [junit] Running org.apache.commons.vfs.provider.ftp.test.FtpProviderTestCase
> [junit] Testsuite: org.apache.commons.vfs.provider.ftp.test.FtpProviderTestCase
> [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
> [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
>
> [junit] Caused an ERROR
> [junit] org.apache.commons.vfs.provider.ftp.test.FtpProviderTestCase
> [junit] java.lang.ClassNotFoundException: org.apache.commons.vfs.provider.ftp.test.FtpProviderTestCase
> [junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
> [junit] at java.security.AccessController.doPrivileged(Native Method)
> [junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
>
>
> Using maven locally works like a charme.
>
>
> ---
> Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
http://www.multitask.com.au/people/dion/
"You are going to let the fear of poverty govern your life and your
reward will be that you will eat, but you will not live." - George
Bernard Shaw
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs][REVOTE] release version 1.0
Posted by Mario Ivankovits <ma...@ops.co.at>.
Stephen Colebourne wrote:
> What is the cause of the current GUMP test failure??
>
ClassNotFoundException of one of our test classes.
internal-test:
[mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons/vfs/target/test-reports
[junit] Running org.apache.commons.vfs.provider.ftp.test.FtpProviderTestCase
[junit] Testsuite: org.apache.commons.vfs.provider.ftp.test.FtpProviderTestCase
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
[junit] Caused an ERROR
[junit] org.apache.commons.vfs.provider.ftp.test.FtpProviderTestCase
[junit] java.lang.ClassNotFoundException: org.apache.commons.vfs.provider.ftp.test.FtpProviderTestCase
[junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
[junit] at java.security.AccessController.doPrivileged(Native Method)
[junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
Using maven locally works like a charme.
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs][REVOTE] release version 1.0
Posted by Stephen Colebourne <sc...@btopenworld.com>.
What is the cause of the current GUMP test failure??
Stephen
Mario Ivankovits wrote:
> Hi!
>
> Even if the last vode passed I decided to restart the voting based on RC7.
> RC7 is now using commons-net 1.4.1 and built using the jdk1.3 compiler
> also some rearrangements have taken place to accommodate to our
> guidlines (e.g. include xdocs into src distribution)
>
> As previously posted please find the RC7 at
> http://people.apache.org/~imario/vfs
>
> Please vote:
>
> [ ] +1 I support this release and am willing to help
> [ ] +0 I support this release but am unable to help
> [ ] -0 I do not support this release
> [ ] -1 I do not support this release, and here are my reasons
>
>
> Sorry if this revote bothers you, but after all what happens in the last
> days on our mailinglist I thought if would be better to do so.
>
> Thanks!
> Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[RESULT][vfs][REVOTE] release version 1.0
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
After a couple of RCs, a already passed 1.0 vote I have to annonounce
that the revote has failed.
You can find the voting thread here:
http://marc.theaimsgroup.com/?t=113381466200006&r=1&w=2
The main reason is that commons-vfs depends on commons-compress which is
a sandbox component. It turns out that it is undesired to release
packages if they itself depends on non released code.
This is the same for webdavlib (slide) where we have to use a specific
snapshot to make the webdav stuff work.
I'll fix the compress stuff by import the required sources into the VFS
codebase (or should we cut a compress release?).
The webdavlib might be another problem as there was no release in 2005,
hopefully we will see a new one soon.
So how can I proceed now?
I cant rewind the RC's, so if I continue development which version
should I use?
I tend to use 1.1-dev even if we never had a 1.0 release.
Too much time to get the release out has been taken.
Now I'll fix the new bugs and move on as described on
http://wiki.apache.org/jakarta-commons/VfsNext.
Once we sorted out the dependency stuff we can cut a new release.
What do you think?
Ciao,
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs][REVOTE] release version 1.0
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
hi mario
On Mon, 2005-12-19 at 11:21 +0100, Mario Ivankovits wrote:
> > Checked again, and it works now! So I am +1 for the release.
> >
> No one else?
>
>
> Should I delay the release until all the discussion around "how to
> release" and the "maybe to come" maven plugin has been settled?
> If so, I'll proceed with developing - else I'll release this week.
it looks like it'll be a while before the dust settles on how to do
better releases so i'd recommend another vote and not waiting.
it's been very confused over the last few weeks plus folks have been
busy at javapolis and apachecon. i think that this vote has probably got
a bit lost (i certainly lost track). it's probably best just to use a
subject something like '[VOTE] release vfs version 1' since my filters
didn't recognise this as a vote thread and perhaps others haven't
either.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs][REVOTE] release version 1.0
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Rahul!
>> If so, I'll proceed with developing - else I'll release this week.
>>
>
> Some theorize that releases must not be disruptive to development.
> While this has always been debatable (releasing is atleast disruptive
> to the RM, if for no-one else, moresoever in Commons) -- I wouldn't
> put it as an "if else" the way you do above. I'd recommend continuing
> development in a branch of choice (which might as well be the trunk,
> since you must've tagged the RC) while we wait for developments on
> this vote.
>
Maybe my statement sounded too "harsh", it wasnt meant so.
Its just I have to think about so many things all the time that (as long
as I am the only active developer) I prefer the "serialized" development.
I wont have to deal with brachnes, merges, etc - too much hassles
already, wont start new one ;-)
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[vfs][REVOTE] release version 1.0
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
>>> Three source files in [vfs] depend on [compress], which is a sandbox
>>> component.
>>>
>>> I am not sure what Commons policy is about releasing components with
>>> dependencies on unreleased components. Is this OK?
>>>
>>
>> I dont know. Anyone else out there with any objection about it?
>
> I believe that its against our policy to do so.
>
> Your best approach may be to copy the code into VFS as package scoped
> classes until a release of [compress] is made.
Ok, I'll have a look at it.
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs][REVOTE] release version 1.0
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Mario Ivankovits wrote:
>> Three source files in [vfs] depend on [compress], which is a sandbox
>> component.
>>
>> I am not sure what Commons policy is about releasing components with
>> dependencies on unreleased components. Is this OK?
>>
>
> I dont know. Anyone else out there with any objection about it?
I believe that its against our policy to do so.
Your best approach may be to copy the code into VFS as package scoped
classes until a release of [compress is made.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs][REVOTE] release version 1.0
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> Three source files in [vfs] depend on [compress], which is a sandbox component.
>
> I am not sure what Commons policy is about releasing components with
> dependencies on unreleased components. Is this OK?
>
I dont know. Anyone else out there with any objection about it?
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs][REVOTE] release version 1.0
Posted by Rahul Akolkar <ra...@gmail.com>.
On 12/19/05, Mario Ivankovits <ma...@ops.co.at> wrote:
>
> No one else?
>
<snip/>
Hi Mario -
Three source files in [vfs] depend on [compress], which is a sandbox component.
I am not sure what Commons policy is about releasing components with
dependencies on unreleased components. Is this OK?
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs][REVOTE] release version 1.0
Posted by Rahul Akolkar <ra...@gmail.com>.
On 12/19/05, Mario Ivankovits <ma...@ops.co.at> wrote:
>
> > Checked again, and it works now! So I am +1 for the release.
> >
> No one else?
>
<snip/>
FWIW, I will express my non-binding opinion by the end of the week, if
this vote is still open.
>
> Should I delay the release until all the discussion around "how to
> release" and the "maybe to come" maven plugin has been settled?
<snap/>
Definitely not. No one knows how much work its going to be and how
long its going to take (some may have more of a clue than others, but
thats what it amounts to). Obviously, you and maybe others thought VFS
was ready for a 1.0 which is why we see this vote, and this vote and
release (if the vote passes), should continue according to the
"current procedures in effect".
> If so, I'll proceed with developing - else I'll release this week.
>
<snip/>
Some theorize that releases must not be disruptive to development.
While this has always been debatable (releasing is atleast disruptive
to the RM, if for no-one else, moresoever in Commons) -- I wouldn't
put it as an "if else" the way you do above. I'd recommend continuing
development in a branch of choice (which might as well be the trunk,
since you must've tagged the RC) while we wait for developments on
this vote.
-Rahul
> ---
> Mario
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs][REVOTE] release version 1.0
Posted by Mario Ivankovits <ma...@ops.co.at>.
> Checked again, and it works now! So I am +1 for the release.
>
No one else?
Should I delay the release until all the discussion around "how to
release" and the "maybe to come" maven plugin has been settled?
If so, I'll proceed with developing - else I'll release this week.
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs][REVOTE] release version 1.0
Posted by Oliver Heger <ol...@t-online.de>.
Mario Ivankovits wrote:
> Hi Oliver!
>
>> I have a problem with the ant build file. The build fails with the
>> following error:
>>
>
> Yes, thats the same problem as with gump.
> Finally I disabled the tests for the ant build again.
> They wont work without an special test server and need some maven
> pre-goal stuff to have the local environment correctly setup.
>
> Sorry for the inconvenience.
>
> Could you please give
> http://svn.apache.org/viewcvs.cgi/*checkout*/jakarta/commons/proper/vfs/trunk/build.xml
> another try, thanks!
>
> ---
> Mario
>
Checked again, and it works now! So I am +1 for the release.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs][REVOTE] release version 1.0
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Oliver!
> I have a problem with the ant build file. The build fails with the
> following error:
>
Yes, thats the same problem as with gump.
Finally I disabled the tests for the ant build again.
They wont work without an special test server and need some maven
pre-goal stuff to have the local environment correctly setup.
Sorry for the inconvenience.
Could you please give
http://svn.apache.org/viewcvs.cgi/*checkout*/jakarta/commons/proper/vfs/trunk/build.xml
another try, thanks!
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs][REVOTE] release version 1.0
Posted by Oliver Heger <ol...@t-online.de>.
Mario,
I have a problem with the ant build file. The build fails with the
following error:
[junit] Running
org.apache.commons.vfs.provider.ftp.test.FtpProviderTestCase
[junit] Tests run: 0, Failures: 0, Errors: 1, Time elapsed: 0,02 sec
[junit] Testsuite:
org.apache.commons.vfs.provider.ftp.test.FtpProviderTestC
ase
[junit] Tests run: 0, Failures: 0, Errors: 1, Time elapsed: 0,02 sec
[junit] Testcase: unknown took 0 sec
[junit] Caused an ERROR
[junit] null
[junit] java.lang.NullPointerException
[junit] at java.io.File.<init>(File.java:180)
[junit] at
org.apache.commons.AbstractVfsTestCase.getTestDirectoryFile(A
bstractVfsTestCase.java:103)
[junit] at
org.apache.commons.AbstractVfsTestCase.getTestDirectory(Abstr
actVfsTestCase.java:128)
[junit] at
org.apache.commons.vfs.test.AbstractTestSuite.setUp(AbstractT
estSuite.java:134)
[junit] at junit.extensions.TestSetup$1.protect(TestSetup.java:18)
[junit] at junit.extensions.TestSetup.run(TestSetup.java:23)
BUILD FAILED
D:\data\projects\OpenSource\vfs\commons-vfs-1.0-RC7-src\build.xml:98:
Test org.a
pache.commons.vfs.provider.ftp.test.FtpProviderTestCase failed
The maven build works.
Sorry
Oliver
Mario Ivankovits wrote:
> Hi!
>
> Even if the last vode passed I decided to restart the voting based on
> RC7.
> RC7 is now using commons-net 1.4.1 and built using the jdk1.3 compiler
> also some rearrangements have taken place to accommodate to our
> guidlines (e.g. include xdocs into src distribution)
>
> As previously posted please find the RC7 at
> http://people.apache.org/~imario/vfs
>
> Please vote:
>
> [ ] +1 I support this release and am willing to help
> [ ] +0 I support this release but am unable to help
> [ ] -0 I do not support this release
> [ ] -1 I do not support this release, and here are my reasons
>
>
> Sorry if this revote bothers you, but after all what happens in the
> last days on our mailinglist I thought if would be better to do so.
>
> Thanks!
> Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org