geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: Some features for 1.1.1 -- module/deployment extensions
Date Sun, 11 Jun 2006 18:18:04 GMT
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).
>
> 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.

This seems like a lot for a patch release.  To be sure, this is an 
important issue.  If it's that critical for the community and needs to 
get out ASAP, then let's make this the sole feature to release in v1.2 
and we can get it out immediately.


Regards,
Alan



Mime
View raw message