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