commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: [Configuration] Dependency on VFS
Date Thu, 26 Mar 2009 03:43:08 GMT
Thanks,

I've tried uploading to the "old" snapshot repo but kept getting a  
401. Brian Fox set up the "new" repo so that commons could use it.  
I've uploaded a snapshot to https://repository.apache.org/content/repositories/snapshots/

. I have updated the pom on my local machine to deploy there but I  
haven't checked it in as I also changed the release repo to the new  
Nexus repository, but I don't know that the Commons PMC has OK'd that  
yet.

I try to avoid doing anything on Windows - even on my Windows Laptop I  
run Ubuntu in a VM - so the WindowsFileNameParser is a java class I  
haven't looked at yet. But I will take a look at that and see what I  
can do.

Ralph


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


Mime
View raw message