Anyone experimenting with a FileTree implementation based on apache commons-vfs2?


(Doug Lethin) #1

I’m in the early stages of experimenting with a gradle build that will need to access a set of files. I would imagine that it might be possible that this set is somewhere on the filesystem, potentially in a zip file, or maybe on a webserver that supports webdav.

In researching this possibility I came across my first exposure to commons-vfs2.

This was very intriguing to me as it would appear that commons-vfs2 supports all 3 of my conditions and models it very eloquently through a URI where the protocol specifies the “type” of filesystem. For example:

zip - zip:http://somehost/downloads/somefile.zip tgz:file://anyhost/dir/mytar.tgz!/somepath/somefile file:///home/someuser/somedir webdav://somehost:8080/dist

The nice thing about this approach is that my build could have some default behavior to determine the URI, and then through an init script or a command line switch this behavior could be changed to specify a different URI.

But however the URI was specified, as long as the it was passed to an implementation of FileTree based on commons-vfs’ FileSystemManager class, it seems like the build would be perfectly agnostic to the source and would work in either case.

Here is the example from apache on how FileSystemManager works.

It seems plausible to somehow wrap this in a FileTree implementation.

// Locate the Jar file
FileSystemManager fsManager = VFS.getManager();
FileObject jarFile = fsManager.resolveFile( "jar:lib/aJarFile.jar" );
  // List the children of the Jar file
FileObject[] children = jarFile.getChildren();
System.out.println( "Children of " + jarFile.getName().getURI() );
for ( int i = 0; i < children.length; i++ )
{
    System.out.println( children[ i ].getName().getBaseName() );
}

Of course the bummer is that after searching, I couldn’t find anyone doing something like this, so I would need to write it.

The short summary use case I’m trying to support is that I need to provide a mechanism to supply the source of some configuration resource files needed to run some integration tests. A good percentage of the time these can be just hosted on a webserver running webdav. But in some cases, a user might want to run with a local copy of the configuration resources.

Any gotcha’s that stand out in anyone’s mind in trying to go down this approach?

Thanks.