geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul McMahan <>
Subject Re: geronimo plugin schema (longish)
Date Fri, 20 Jul 2007 18:19:51 GMT
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 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,


View raw message