geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Warner" <jaw...@gmail.com>
Subject Re: geronimo plugin schema (longish)
Date Fri, 20 Jul 2007 12:46:51 GMT
On 7/19/07, Donald Woods <dwoods@apache.org> 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
> >
> >
>
>

Mime
View raw message