Following up to myself... I also have a handle DSL that's usable within the actual test-case to build a deployment and apply some structure. | it "should use the unit's root as RAILS_ROOT" do | deployment = deploy do | root do | dir 'config', :metadata=>true do | file 'rails-env.yml', :read=>'rails-env/simple-rails-env.yml' | end | end | end | unit = deployment_unit_for( deployment ) | meta_data = unit.getAttachment( RailsApplicationMetaData.java_class ) | | meta_data.should_not be_nil | meta_data.getRailsRoot().should eql( unit.getRoot() ) | meta_data.getRailsEnv().should eql( 'simply-an-env' ) | end | This creates a vfsmemory:// deployment which contains a directory config/ which is both a metadata directory and contains a file named rails-env.yml which is actually read from one of the test resources of a different name. Basically, just a handy way to construct a tree VFS from a variety of sources, and jacking some StructureMetaData around it at the same time. Thoughts? fwiw, if you prefer, the alternate Ruby syntax using curlies would be | deployment = deploy { | root { | dir( 'config', :metadata=>true ) { | file 'rails-env.yml', :read=>'rails-env/simple-rails-env.yml' | } | } | } | -Bob View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4226050#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...