geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject Re: Some features for 1.1.1 -- module/deployment extensions
Date Sat, 10 Jun 2006 18:52:25 GMT

Actually, I already have this list created (though not in a table).   I 
was updating the image I had created earlier to show the dependencies 
between modules (formerly configurations) about a month ago.  Things may 
have changed slightly since then, but this is at least a start.

My apologies for the current format (powerpoint doc). But I think this 
will get you started.

BTW, I was going to post this the as a new thread after I verified that 
the parent dependencies in the image were still correct.  I think there 
is some clean-up necessary on some of these relationships.


Aaron Mulder wrote:
> That's already possible.  I had it working earlier, but we need to
> recreate the metadata file for it that lists the modules to add and
> the modules to remove.
> If you get a chance, could you look at project.xml for the J2EE
> assemblies vs. the minimal assemblies and make a list of all the
> Geronimo modules in the two?  Such as:
> module  J2EE  minimal
> system  yes  yes
> unavailable-webservices-deployer  no  yes
> ...
> We can use a list like that to create the plugin metadata to upgrade
> minimal to full J2EE.
> Thanks,
>    Aaron
> On 6/9/06, Donald Woods <> wrote:
>> Would this also enable the scenario of someone wanting to upgrade a
>> minimal-tomcat-server with the unavailable-webservices-deployer to
>> include the Axis and Axis-builder modules?
>> -Donald
>> Aaron Mulder wrote:
>> > 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
>> > 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
>> >
>> >

Joe Bohn
joe.bohn at

"He is no fool who gives what he cannot keep, to gain what he cannot 
lose."   -- Jim Elliot

View raw message