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
