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
