FYI, I plan to address http://issues.apache.org/jira/browse/GERONIMO-1873 as soon as possible in 1.1.1. I'd like plugins to be able to define new deployment unit formats (e.g. JBI service assemblies, a Spring deployment unit, a Quartz job as a deployment unit, or a Jasper report as a deployment unit).
Any of those will probably need a geronimo-XYZ.xml deployment plan, to supply a module ID and dependencies if nothing else. And currently, the deploy tool doesn't know how to crack open an arbitrary deployment unit and figure out its module ID, which is necessary to support redeployment when the plan is embedded in the archive (it has to know what existing module(s) to replace). There are two possible solutions: one is to stop using JSR-88 for deployment and just pass the archive to the server and let it do its thing; the other is to let each deployer indicate the name of its deployment plan (when the plan is packed in the module). I'd lean toward the second approach for 1.1.1, as it's a fairly trivial change. A related question is whether we should let you pack non-J2EE deployment units in an EAR. That is, if we define a JasperReports report deployment unit, should your EAR be able to contain a WAR, an EJB JAR, and 2 reports? I would think so, though we may choose to implement a wrapper that would hold the EAR and the 2 reports instead. I'm not sure how extensive a change this might require -- we seem to have some special handling for classpaths for modules within an EAR, and I don't know where that happens and what's likely to break. If we do nothing, the alternative is that you'd only be able to redeploy new types of modules if you pass either the module ID or the plan on the command line along with the archive (no packing plan in archive), and if you had a J2EE app and a handful of other modules that all work together, you would still have to deploy/redeploy them all individually. Thanks, Aaron
