Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of ralph.goers@dslextreme.com
 designates 209.85.220.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CACZkXPz-rAsukAxsO99giD0WQ5jNj3tK=3_nYCxk9aFKYmspeg@mail.gmail.com>
References: <20111115044908.A698F14E4DC@vmgump.apache.org>
	<87pqgtq2cz.fsf@v35516.1blu.de>
	<CACZkXPz-rAsukAxsO99giD0WQ5jNj3tK=3_nYCxk9aFKYmspeg@mail.gmail.com>
Date: Tue, 15 Nov 2011 09:18:25 -0800
Message-ID: 
 <CAEk_X4bY-=XWGWgEK8gQ4QDW6H8BWMQMN_5MuJKhGtosSnj5gQ@mail.gmail.com>
Subject: Re: [GUMP@vmgump]: Project commons-vfs2-test (in module
 apache-commons) failed
From: "ralph.goers @dslextreme.com" <ralph.goers@dslextreme.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=485b397dd343d92f4a04b1c92c6d

--485b397dd343d92f4a04b1c92c6d
Content-Type: text/plain; charset=ISO-8859-1

Under core/src/test/resources you will find all the data that needs to be
pre-populated for the test runs. Only write-tests is there with a dummy.txt
file. The dir1 subdirectory is created by the tests. It seems odd to me
that the SftpProviderTestCase is pointing to the
target/test-classes/test-data directory.  That directory is used by the
"normal" file-based tests and I would think it could have stuff left in it
from those runs. That said, I ran mvn clean install -Dmaven.test.skip and
then mvn test -Dtest=SftpProviderTestCase and verified that it worked. It
did leave the dir1 and dir2 subdirectories after the run was finished.

Ralph

On Tue, Nov 15, 2011 at 8:15 AM, Gary Gregory <garydgregory@gmail.com>wrote:

> On Tue, Nov 15, 2011 at 2:19 AM, Stefan Bodewig <bodewig@apache.org>
> wrote:
>
> > The Mina issue is resolved, tests now fail for a different reason.
> >
> > See for example
> >
> >
> >
> http://vmgump.apache.org/gump/public/apache-commons/commons-vfs2-test/gump_file/org.apache.commons.vfs2.provider.sftp.test.SftpProviderTestCase.txt.html
> >
> >
> Well, that's better, one step closer, to look at this positively.
>
> The tests pass locally (for me, does your mileage vary?)
> The tests pass on Continuum
> The tests fail on Gump.
>
> The key error seems to be:
>
> No such file:
> /srv/gump/public/workspace/apache-commons/vfs/core/target/test-classes/test-data/write-tests/dir1/
>
> Either the dir was not created on test set up, or it is not found by the
> file system viewer I installed in the embedded test server.
>
> But it seems to be looking in the right place. I suppose debugging Gump
> remotely is as impossible as debugging Continuum remotely.
>
> back to System.out.println? Can a Gump build be run on demand?
>
> Ideas and help welcome!
>
> Thank you,
> Gary
>
> Stefan
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>

--485b397dd343d92f4a04b1c92c6d--