geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <>
Subject Some features for 1.1.1 -- module/deployment extensions
Date Fri, 09 Jun 2006 20:51:23 GMT
FYI, I plan to address 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

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.


View raw message