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 <dwoods@apache.org> 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* <dwoods@apache.org
> > <mailto: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/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
> > >
> > >
> >
> >
>
>
|