On Jun 9, 2006, at 1:51 PM, Aaron Mulder wrote:
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).
Depending on what this requires in terms of changes in Geronimo it sounds like a new feature. I know we haven't discussed it at all, but I assume that dot releases don't get new features. (I'm not saying it is a "feature" just sounds like one to me).
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).
That sucks. Is there something else we could do to avoid needing the module id? I'm guessing not.
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.
I like the first one. JSR-88 seems to have to have a myopic view of the world and I really starting to feel constrained by the spec. Do you think it will be able to support everything we want to do in the future?
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.
I think we should allow arbitrary nesting, and I think it will require a major change to deployment.
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.
I would lean towards a multiphase rollout of this feature. A small work around for 1.1.1, and depending on timing maybe split the rest across 1.2 and 1.3.
That is just my $0.02. -dain
