Great! Thanks, Aaron
On 6/10/06, Donald Woods <[EMAIL PROTECTED]> wrote:
Glad to hear its possible. I'll start working on the table and was thinking about putting it on the Wiki under Architecture --> Assemblies. -Donald 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 <[EMAIL PROTECTED]> 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 >> > 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 >> > >> > >> >> >> > >
