You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Paul McMahan <pa...@gmail.com> on 2007/07/20 00:52:53 UTC
geronimo plugin schema (longish)
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 24, 2007, at 12:55 PM, Joe Bohn wrote:
> I don't supposed there is anyway to split the module-id out to a
> single place and then specify all of the applicable geronimo-
> versions to be associated with the plugin? It looks like it would
> be very easy to make a mistake here. What would happen if a
> different module if was specified for geronimo-version 2.0 vs.
> geronimo-version 2.1?
I think we actually want to support that scenario since in many cases
a module won't be compatible with multiple versions of Geronimo, so a
different <module-id> will be needed. Also, if there is no <geronimo-
version> specified then the plugin installer currently assumes that
the plugin is compatible with all versions of Geronimo. So a repo
maintainer could specify that part of the plugin metadata sorta like
a switch statement with a default <module-id>.
Best wishes,
Paul
Re: geronimo plugin schema (longish)
Posted by Joe Bohn <jo...@earthlink.net>.
Paul McMahan wrote:
> On Jul 19, 2007, at 10:42 PM, Lin Sun wrote:
>
>> After a plugin is published, a user finds it also works with a
>> different version of geronimo (without any other code change), so a
>> user would modify the plugin's xml file to add the newer version
>> geronimo there. Should the user also change the version of the plugin
>> itself in this case?
>
> Yeah that situation could be a little confusing when using this schema.
> The versions of geronimo that the plugin supports are in
> <geronimo-version> elements. But the version of the plugin itself is
> implicit in its <module-id> which uses standard maven naming conventions
> (group / id / version / type). So if a single version of the plugin
> works in multiple versions of geronimo then a sample catalog entry might
> look like:
>
> <plugin>
> ...
> <plugin-module>
> <module-id>awesome.group/awesomeApp/1.0/car</module-id>
> <geronimo-version>2.0</geronimo-version>
> </plugin-module>
> <plugin-module>
> <module-id>awesome.group/awesomeApp/1.0/car</module-id>
> <geronimo-version>2.1</geronimo-version>
> </plugin-module>
> </plugin>
I don't supposed there is anyway to split the module-id out to a single
place and then specify all of the applicable geronimo-versions to be
associated with the plugin? It looks like it would be very easy to make
a mistake here. What would happen if a different module if was
specified for geronimo-version 2.0 vs. geronimo-version 2.1?
Joe
>
> Maybe for the sake of clarity the plugin version should be explicitly
> declared by introducing a new <version> element as a child of
> <plugin>. But I waffle on that because it creates an opportunity to
> have a different version embedded in the module-id. That might prove
> useful in some contrived scenario but it seems dangerous.
>
>> Also, any consideration of how plugins can work with geronimo and
>> other products who uese geronimo?
>
> Actually the main goal here is to make it easier for application
> developers to set up and maintain their own plugin repositories. Right
> now I think its a little burdensome and we can make some simple
> improvements like these schema changes that will help a lot.
>
>
> Best wishes,
> Paul
>
Re: geronimo plugin schema (longish)
Posted by Paul McMahan <pa...@gmail.com>.
On Jul 19, 2007, at 10:42 PM, Lin Sun wrote:
> After a plugin is published, a user finds it also works with a
> different version of geronimo (without any other code change), so a
> user would modify the plugin's xml file to add the newer version
> geronimo there. Should the user also change the version of the
> plugin itself in this case?
Yeah that situation could be a little confusing when using this
schema. The versions of geronimo that the plugin supports are in
<geronimo-version> elements. But the version of the plugin itself
is implicit in its <module-id> which uses standard maven naming
conventions (group / id / version / type). So if a single version
of the plugin works in multiple versions of geronimo then a sample
catalog entry might look like:
<plugin>
...
<plugin-module>
<module-id>awesome.group/awesomeApp/1.0/car</module-id>
<geronimo-version>2.0</geronimo-version>
</plugin-module>
<plugin-module>
<module-id>awesome.group/awesomeApp/1.0/car</module-id>
<geronimo-version>2.1</geronimo-version>
</plugin-module>
</plugin>
Maybe for the sake of clarity the plugin version should be explicitly
declared by introducing a new <version> element as a child of
<plugin>. But I waffle on that because it creates an opportunity to
have a different version embedded in the module-id. That might prove
useful in some contrived scenario but it seems dangerous.
> Also, any consideration of how plugins can work with geronimo and
> other products who uese geronimo?
Actually the main goal here is to make it easier for application
developers to set up and maintain their own plugin repositories.
Right now I think its a little burdensome and we can make some simple
improvements like these schema changes that will help a lot.
Best wishes,
Paul
Re: geronimo plugin schema (longish)
Posted by Lin Sun <li...@gmail.com>.
I like the idea in general. I am wondering how this scenario would work:
After a plugin is published, a user finds it also works with a different
version of geronimo (without any other code change), so a user would
modify the plugin's xml file to add the newer version geronimo there.
Should the user also change the version of the plugin itself in this case?
Also, any consideration of how plugins can work with geronimo and other
products who uese geronimo?
Lin
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 19, 2007, at 11:38 PM, Donald Woods 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....
Excellent points. The new schema would still support the
configuration you describe where there is one catalog per version of
Geronimo. Its main advantage is that it does not constrain
repositories to that approach. For example, I suspect that non-ASF
repos like at http://geronimo.liferay.com/plugins would take
advantage of the new schema since I doubt they want to maintain a
catalog for every version of Geronimo. David Jencks has also started
some very interesting work with using a local maven repo for a plugin
repo which may end up benefitting from the new schema as well.
If Geronimo's plugin feature is a success then I think there will be
lots of catalogs scattered around the net besides the catalog we
maintain for whichever parts of the Geronimo server itself we decide
to implement as plugins.
So then the real question in my mind is less centered on whether or
the schema needs more work. The question becomes whether or not the
Geronimo project itself should continue maintaining version-specific
catalogs for its plugins or consolidate them using the new schema.
You pointed out some advantages of version specific catalogs that I
hadn't thought about:
- catalogs for specific branches of the server could be
automagically generated at build time
- smaller, more focused XML files are easier to maintain (?)
Some disadvantages of that approach:
- redundancy across catalogs, updating the metadata for a plugin
could require updating many catalogs
- it's more difficult to "advertise" your repository URL since it is
version specific
- creating a new catalog each time we release a new version of
Geronimo is tedious[1]
- plugins factored out of server trunk would have to stay in version-
synch with Geronimo server
That last item is hard to explain, and is sort of the converse of
that last point you made. Which means that we probably have
different ideas about how the plugins will be factored out. That is
bound to be a very interesting discussion :-)
Best wishes,
Paul
[1] http://tinyurl.com/yvqlpz
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
> >
> >
>
>
Re: geronimo plugin schema (longish)
Posted by Jason Warner <ja...@gmail.com>.
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 Donald Woods <dw...@apache.org>.
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....
-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
>
>