You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jason Warner <ja...@gmail.com> on 2007/07/20 14:46:51 UTC
Re: geronimo plugin schema (longish)
On 7/19/07, Donald Woods <dw...@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
> >
> >
>
>
Re: geronimo plugin schema (longish)
Posted by Paul McMahan <pa...@gmail.com>.
On Jul 20, 2007, at 11:22 AM, Jason Warner wrote:
> 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?
Since we're quickly approaching the end of the runway for Geronimo
2.0 it looks like the changes made in GERONIMO-2757 are going to part
of that release. From a backwards compatibility perspective I think
we should try very hard to support the schema changes it introduced.
I'm not sure yet what that means w.r.t. how the plugin installer code
might get swizzled around.
Best wishes,
Paul
Re: geronimo plugin schema (longish)
Posted by Jason Warner <ja...@gmail.com>.
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 <dw...@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
> > <ma...@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
> > >
> > >
> >
> >
>
>
Re: geronimo plugin schema (longish)
Posted by Donald Woods <dw...@apache.org>.
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
> <ma...@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
> >
> >
>
>