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/plugins for > 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 > >
smime.p7s
Description: S/MIME Cryptographic Signature
