Paul,
From what you described and looking at the schema you provided, it looks
like the changes made by Geronimo-2757 are going to get blown away and replaced by this new plugin-module. Am I right in thinking that?
Also, I think it would be a great idea to replace the SAX parsing currently used by the Plugin Installer. In fact, I think you might almost have to given that you're going to have a lot of duplicate elements within a plugin. The current SAX parser seems inadequate for what you plan on doing. Just my $0.02. -Jason Warner On 7/20/07, Donald Woods <[EMAIL PROTECTED]> wrote:
You're not confused. That was my point/question of does it really make sense to have one massive geronimo-plugins.xml for several releases.... I +1 the idea of updating the schema, I'm just wondering how we can use it from a build perspective.... -Donald Jason Warner wrote: > > > On 7/19/07, *Donald Woods* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Sounds like a good idea, but does this help or hurt us as far as > trying to > automatically generate the geronimo-plugins.xml after a > build? Seems like > keeping multiple releases in one XML file is going to become a PITA > after a > couple of releases.... > > Why not create a separate geronimo-plugins.xml for each major > release stream > (like 2.0/2.0.x and then 2.1/2.1.x)? Wouldn't that be easier to > maintain, > especially if we reorg the modules/configs in 2.1 for the new > pluggable admin > Portlets and move unnecessary code out into optional plugins.... > > > Isn't that what we do already? IIUC, we currently do have a different > geronimo-plugin.xml > for each release. I think the whole point of what Paul wants to do is > to move away from that. > I might be confused, though. It's early :) > > -Donald > > Paul McMahan wrote: > > I've been thinking about some changes to the geronimo-plugin > schema to > > make plugin catalogs less verbose and easier to maintain across > versions > > of Geronimo. The problem with the current schema is that some of > the > > plugin metadata that is sensitive to the geronimo version is > grouped in > > <geronimo-versions> elements, but some is not. > > > > Plugins are often sensitive to the geronimo version they were > developed > > under since they typically rely on lots of container services. > Besides > > that, in general plugins only work in the version of geronimo > they were > > exported from (or car plugin version). So this schema limitation > makes > > it difficult to create one catalog that supports several versions of > > geronimo without having a lot of redundant plugin entries. Right > now we > > maintain separate catalogs at http://geronimo.apache.org/pluginsfor > > each version of geronimo because of this limitation. > > > > I attached a proposed schema here : > > https://issues.apache.org/jira/browse/GERONIMO-3330 > > > > Using that new schema a plugin entry would look something like: > > <plugin> > > <name/> > > <category/> > > <description/> > > <url/> > > <author/> > > <license/> > > <plugin-module> > > <module-id/> > > <hash/> > > <geronimo-version/> > > <jvm-version-version/> > > <prerequisite> > > <id/> > > <resource-type/> > > <description/> > > </prerequisite> > > <dependency/> > > <obsoletes/> > > <source-repository/> > > </plugin-module> > > <plugin-module> > > ... > > </plugin-module> > > </plugin> > > > > Note that the metadata that is sensitive to the geronimo version is > > encapsulated in a <plugin-module> element. And a single <plugin> can > > several <plugin-module> elements ( e.g. one for each version of > geronimo > > it supports). > > > > While making this schema change two other things I was considering is > > factoring the plugin code out of geronimo-system into a separate > config > > and using JAXB to handle the XML processing instead of the sax > code it > > currently uses. Feedback is welcome. > > > > Best wishes, > > Paul > > > > > >
