"ALRubinger" wrote : | From what I can tell, we'd just be moving the problem, as we have to integrate somewhere. Seems what you're proposing is moving jboss-bootstrap-api-embedded and impl-embedded under the org.jboss.embedded umbrella again (where I had it originally, actually ;)). | Yes, i think it's better under it's own umbrella :) "ALRubinger" wrote : | As currently set up, this won't affect AS as AS doesn't depend upon it. And AS can't really affect it either; that's why there's the TMPDPL "Container" API. Now api-embedded doesn't have a dependency on even VDF. Container becomes the locked SPI. | | Does that solve the backwards-compat issue sufficiently for you? Hmm, we could briefly talk about the deployable as well - as i can tell for sure that ProfileService won't expose a VDF deployment. Maybe we want to just rename the VfsVdfDeployableFactory to a DeployableFactory? In the end it should not really matter what deployable is created and i don't think there should be 2 different types - like VdfDeployable and PSDeployable - at the same time. Is there an additional use for the deployable in general? I guess it would be used when having a DSL attaching the actual deployment descriptor instead of a reference to a xml? [OT] out of curiosity - it seems that when creating a deployable you are creating a zip out of the shrinkwrap in-memory archive. When i first looked at the archive stuff - i thought you are directly deploying this in-memory VirtualFile. Is there a specific reason why you don't do that? Well, as it gets zipped it could be interesting to use that also in standalone testing. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261116#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...