How do I migrate this to VFS 3.0

See how this was done in other projects -- CL and Deployers.

We used this constantly there.

For the Bundle protocol part in OSGi facade, perhaps you can just drop that,

and I'll re-write it from scratch based on the new VFS3 api.

For the deployers testing, John created a bridge class

https://svn.jboss.org/repos/jbossas/projects/jboss-deployers/trunk/deployers-vfs/src/test/java/org/jboss/test/deployers/support/AssembledDirectory.java

or you could just change the tests to use the new VirtualFileAssembly class directly?

A better long-term approach would be to move to using ShrinkWrap archives to declaratively create ear/war/jar archives.  ShrinkWrap already has fluent API to add classes/resources to an archive.

JavaArchive archive = Archives.create("archive.jar", JavaArchive.class) 
    .addClasses(MyClass.class,MyOtherClass.class) 
    .addResource("mystuff.properties");

I have also written a VFS3 based filesystem that uses ShrinkWrap archives for a backing.  This allows you to take an archive an mount it into the VFS wherever you like.  Once mounted you can simply deploy the VirtualFile pointing to the mounted FileSystem.

JavaArchive archive = ...

VirtualFile archiveFile = VFS.getChild("/vfs/path").getChild(archive.getName());
VFS.mount(archiveFile, new ArchiveFileSystem(archive, tempDir));

deploy(archiveFile);

I need to work with Andrew to figure out where the ArchiveFileSystem should live long term, but I do think this is the best long term testing strategy for creation of test archives.  Since we are suggesting ShrinkWrap be used for customers to test through embedded, it would be a good idea to do the same where possible.  This will also reduce the number of competing implementations of the same functionality.

johnbailey wrote:

 

A better long-term approach would be to move to using ShrinkWrap archives to declaratively create ear/war/jar archives.  ShrinkWrap already has fluent API to add classes/resources to an archive.

 

Not for these tests. We don't want to create an archive, although Thomas has already found a tool for doing that for OSGi called "bnd".

For these tests, we want to pass the metadata objects in explicitly (via the predetermined attachments on the deployment)

rather than having them parsed from xml.

e.g. for testing all the different permutations of OSGi metadata

we use an "AssembledDirectory" that filters the specified packages in the classpath and then

we create many different OSGiMetaData objects with slight tweaks to different parameters.

Any other way would require hundreds of manifest files and slow down the tests as you have to construct the jars.

Ahh.  I should have looked deeper into the tests.  I can help out moving the tests to use the VirtualFileAssembly.