The idea was to initiate the deployment with some specific metadata that describes deployment (file, directory, SWArchive, etc..). There would then be a series of deployers which look for these specific metadata types and would invoke the proper VFS mount/unmount operations for the deployment.
What you're describing is all already there.
* StructureMetaData -- perhaps all it's missing is some more exact deployment type info (file, dir, ...)
* jboss-structure.xml -- again, perhaps some more info on the type
But why exactly do you need this?
But who would provide this? If it's not pre-determined, then we need to figure this out.
And that's exactly why we have structure deployers.
Imo, the structure deployer are the only one's who know where and how to (un)mount things.
As they are the only one's that (should) understand the deployment structure.
With this, I already see some inconsistency; e.g. we do mounting in VFSClassLoaderClassPathDeployer [1].
This mean we're doing some things twice; e.g. 1st mounting war's libs, then doing this again for [1]
But I guess this is a workaround for dynamically added classpath entries?
Meaning we should be able to force people to do this themselves, hence it wouldn't be needed in [1], right?
The key change is to align the structure deployers with the Deployer API and actually have deploy and undeploy operations.
Agreed, but this is big spi change, hence it will have to wait till v3.0.
And like you said, it will help us remove Automounter.
Then you can introduce deployers in front of structure determination to handle proper mounting. With this change, all that would be needed to integrate the ShrinkWrap Archive deployment would be to create the deployment (in embedded, TorqueBox, etc.) with an attachment that would cause a special mounting deployer to pick up and mount the ArchiveFileSystem as apposed to the normal filesystem based mounting deployers.
You can already do this -- perhaps we cound only extend StructureContext to keep the ref to (VFS)Deployment.
e.g.
* add new structure deployer SWRP, before any other -> relative order < 0
* the root or our mounting point has unique suffix; e.g. root.swrp
* we then recognize this root in our SWRP, and properly mount it