commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <oliver.he...@oliver-heger.de>
Subject Re: [Configuration] Dependency on VFS
Date Sat, 28 Mar 2009 20:34:53 GMT
Oliver Heger schrieb:
> Ralph Goers wrote:
>> I fixed this. Please rebuild your VFS and give it another try.
>>
>> Ralph
> 
> Yes, the test is now successful. Thanks for the fix!
> 
> Oliver

When doing some further tests I noticed a strange behavior of 
TestWebdavConfigurationBuilder: A mvn test works, but when I execute the 
test class alone, all tests fail with the message "No base url provided" 
in the getBasePath() method. Obviously the system property cannot be 
resolved.

Can it be that this test only works if some other test was run before? 
If this is the case, we might get into trouble in some environments 
where tests are executed in a different order.

Oliver

> 
>> On Mar 25, 2009, at 2:19 PM, Oliver Heger wrote:
>>
>>> Ralph Goers schrieb:
>>>
>>>> On Mar 23, 2009, at 2:34 PM, Oliver Heger wrote:
>>>>
>>>>> Hey, this really looks interesting! Unfortunately, I am pretty  busy
>>>>> ATM and will need some time to grasp the concepts.
>>>>>
>>>>> However, I have now a build problem: Maven complains that it  cannot
>>>>> find the vfs snapshot jar (see below). Do we need to add  the
>>>>> snapshot repository to the pom?
>>>>>
>>>> Yeah. I'm not crazy about adding the snapshot repo to the pom. It 
>>>> would only need to be there until the next release. At the moment 
>>>> VFS hasn't been published to the SNAPSHOT repo. I've been doing a 
>>>> mvn install of VFS on my local box before working on configuration. 
>>>> But until VFS has a release I guess the only decent option is to  put
>>>> the snapshot repo in the pom and publish the VFS snapshot.  BTW  - I
>>>> haven't tried publishing anything to the snapshot repo before. 
>>>> Should I expect to have the necessary karma to do that?
>>>> Also, I still have to add doc to the user guide. Hopefully, once I 
>>>> do that it will be a little easier to understand.
>>> Well, as a temporary solution we probably have to include the 
>>> snapshot repository. Otherwise everybody who tries to build 
>>> [configuration] from the sources will get a build error. I haven't 
>>> published a jar to the snapshot repository either, so don't know 
>>> about karma.
>>>
>>> I have now installed the vfs snapshot in my local repository. 
>>> Compiling works fine, but I get a test failure:
>>> testNewFileReloading
>>> (org.apache.commons.configuration.reloading.TestVFSFileMon
>>> itorReloadingStrategy)
>>>
>>> The following exception is thrown:
>>> org.apache.commons.vfs.FileSystemException: URI "D:\data\projects
>>> \OpenSource\commons-configuration\target" is not an absolute file  name.
>>>     at  org .apache .commons .vfs .provider .local
>>> .WindowsFileNameParser
>>> .extractWindowsRootPrefix(WindowsFileNameParser.java:81)
>>>     at  org .apache .commons .vfs .provider .local
>>> .WindowsFileNameParser.extractRootPrefix(WindowsFileNameParser.java: 39)
>>>     at  org .apache .commons .vfs .provider
>>> .local.LocalFileNameParser.parseUri(LocalFileNameParser.java:78)
>>>     at  org .apache .commons .vfs
>>> .provider.AbstractFileProvider.parseUri(AbstractFileProvider.java:170)
>>>     at  org .apache .commons .vfs .impl
>>> .DefaultFileSystemManager.resolveURI(DefaultFileSystemManager.java: 802)
>>>     at  org .apache
>>> .commons.configuration.VFSFileSystem.getPath(VFSFileSystem.java:197)
>>>     at  org .apache .commons .configuration .reloading
>>> .VFSFileMonitorReloadingStrategy
>>> .init(VFSFileMonitorReloadingStrategy.java:135)
>>>     at  org .apache .commons .configuration .AbstractFileConfiguration
>>> .setReloadingStrategy(AbstractFileConfiguration.java:765)
>>>     at  org .apache .commons .configuration .reloading
>>> .TestVFSFileMonitorReloadingStrategy
>>> .testNewFileReloading(TestVFSFileMonitorReloadingStrategy.java:111)
>>>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>     at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>>     at java.lang.reflect.Method.invoke(Unknown Source)
>>>     at junit.framework.TestCase.runTest(TestCase.java:154)
>>>     at junit.framework.TestCase.runBare(TestCase.java:127)
>>>     at junit.framework.TestResult$1.protect(TestResult.java:106)
>>>     at junit.framework.TestResult.runProtected(TestResult.java:124)
>>>     at junit.framework.TestResult.run(TestResult.java:109)
>>>     at junit.framework.TestCase.run(TestCase.java:118)
>>>     at junit.framework.TestSuite.runTest(TestSuite.java:208)
>>>     at junit.framework.TestSuite.run(TestSuite.java:203)
>>>     at  org .eclipse .jdt .internal .junit
>>> .runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>>>     at  org .eclipse
>>> .jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>>     at  org .eclipse .jdt .internal
>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>>>     at  org .eclipse .jdt .internal
>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>>>     at  org .eclipse .jdt
>>> .internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>>>     at  org .eclipse .jdt
>>> .internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java: 196)
>>>
>>> I suspect this is a Windows-specific issue.
>>>
>>> Oliver
>>>
>>> ---------------------------------------------------------------------
>>> 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
> 


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


Mime
View raw message