In relation to the upgrade to VFS 3, why don't we deprecate VFSDeployer?
Right now we stand a chance that we'll get multiple deployer versions because version 1 needs to integrate with VFS 2 and version 2 on top of VFS 3. But most (if not all) of those deployers actually don't have any need for real file access.
For example:EjbAnnotationMetaDataDeployer [1] actually needs to use the results of the annotation scanner to work. DummiesSerializedMetaDataDeployer [2] only needs an InputStream on the underlying file. (Also note that parsing deployer is a counter-intuitive name, because it's actually an file or I/O deployer.)
In essence we could create an IODeployer in which we plug a DeploymentUnitIOManager and then have two implementations: VFS2DeploymentUnitIOManager and VFS3DeploymentUnitIOManager. Where it not that most deployers operate on a higher level abstraction anyway (classes or annotations etc.).
In short we need a blueprint which makes all deployers VFS independent. Thus instead of deprecating a lot of deployer components, we just refactor them properly and do not create an O(x) maintenance burden, but an O(2). :-)
[1] http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/ejb3/trunk/deployers/src/main/java/org/jboss/ejb3/deployers/EjbAnnotationMetaDataDeployer.java?revision=83990&view=markup
[2] http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/reloaded/trunk/naming-deployers/src/test/java/org/jboss/reloaded/naming/deployers/test/common/DummiesSerializedMetaDataDeployer.java?revision=99665&view=markup
