geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <>
Subject Re: Adding plugin utilities to Geronimo
Date Thu, 21 Sep 2006 01:30:16 GMT
A plugin can include files to copy to specific locations in Geronimo
and also settings to write into config.xml.  If there's more you're
looking for, can you provide a more specific list?  For example,
people have asked in the past for more explicit support for database
pools (like dependencies saying is must be version 9.x of product
Oracle, not just there must be a pool named MyAppPool).


On 9/20/06, Joe Bohn <> wrote:
> I think this would be really helpful and we should check it in.
> I may have some more features that we will need to add to influence the
> geronimo configuration when a plugin is installed.  For example, we may
> need to install some additional jars in specific locations (such as
> schemas) or alter some configuration settings based upon a plugin that
> is being deployed.  Should we maybe consider integrating these types of
> functions into the plugin deployement functionality and extending the
> geronimoplugin schema to control when/how they are driven?
> Joe
> Aaron Mulder wrote:
> > All,
> >
> > I've got a couple plugin utility classes that include things like
> > adding a screen to a console when a plugin is first run, resolving
> > references to DB pools or GBeans from a plugin, and mangling a J2EE
> > module as its deployed to incorporate plugin features (e.g. so you can
> > include scheduled jobs in a WAR using the Quartz plugin).
> >
> > Is there interest in adding this stuff to the Geronimo project?  It
> > seems like it would be best packaged as a JAR that other plugins can
> > depend upon.
> >
> > I don't think it needs to be distributed with Geronimo, as it can be
> > installed with the first plugin that depends on it.  So I'd be
> > inclined to create a dir like geronimo/plugins/trunk/common to hold
> > this (or perhaps geronimo/plugins/common/trunk -- I don't remember if
> > we want all the plugin content in the same trunk or separate trunks).
> > Anyway, I'd put in a compatible-with-1.1 release right away, and spin
> > off a compatible-with-1.2 release as soon as the naming builder
> > improvements are fully incorporated (I'm not sure if that's happened
> > yet or not).
> >
> > Thanks,
> >    Aaron
> >
> >

View raw message