We have somewhat of a fairly complete geronimo-plugins.xml generated now
as a result of a Geronimo build or building other plugins. It just
requires some minor edits afterward before we can publish it. The
geronimo-plugins.xml is created (or updated) as a peer to the maven
repository (under .m2). It's difficult to tie this directly to just one
build since the catalog of plugins is typically created from building
several projects (Geronimo server, samples, components, or whatever).
Joe
Jason Dillon wrote:
If that is the case, then why don't we add support to auto-generate
this for each build and stuff the required bits into the maven
repository?
--jason
On Thu, May 8, 2008 at 12:44 AM, Joe Bohn <[EMAIL PROTECTED]> wrote:
Donald Woods wrote:
Seems that we need a unique plugin repo for each release, given how we now
build plugins based on the content in pom.xml instead of supplying a
separate plugin file.... Maybe there are some additional car-maven-plugin
enhancements needed, so you can define a range or that any sever release is
supported by the plugin/car being built. Or maybe as David Jencks has
suggested elsewhere, we need to setup the artifact_aliases.properties in
each server release to alias prior releases (like 2.1 and 2.1.1) to the
current release (which would be 2.1.2 for the next release.)
Heh ... funny you should mention this now. I came the same conclusion
yesterday as well (ie. we need a catalog per release given our current
process for creating the plugins). I've decided that we need a catalog per
release for those already out the door and we can think of getting more
creative for future releases.
Joe
-Donald
Joe Bohn wrote:
I've got some questions (and possibly some issues) with the plugin
repository for Geronimo 2.1.1. I went out there attempting to update the
plugin catalog after the release of 2.1.1 (as I had done after 2.1 was
released). However, I hit some issues and have some questions:
1) I learned too late that the download plugin repository list should
have been changed before we cut the release if we wanted the unique catalog
for 2.1.1 plugins to be the default (specified in
framework/configs/plugin/pom.xml). As it stands now, the default plugin
catalog for Geronimo 2.1.1 is pointing to the catalog for Geronimo 2.1.
2) Perhaps sharing the plugin catalog is the correct thing. I'm really
not sure if that is best (or even possible). Can we have one catalog
support multiple Geronimo releases? ... I would presume we could. Is that
what people were assuming or is the assumption a catalog per release?
3) Assuming we should have our own catalog for G 2.1.1 .... I created one
and put it under out there under
geronimo/site/trunk/docs/plugins/geronimo-2.1.1/. Naturally, you must
manually add the catalog for 2.1.1 since the default wasn't updated prior to
the release.
4) The catalog from #3 seems to work but I think I need to update some of
the plugins (esp. samples) so that they are supported on Geronimo 2.1.1. So
it appears that regardless of if we have shared or unique catalogs among
releases we will need to update the plugins to support the newer releases if
they are shared. Is that correct? (I specifically attempted to install the
2.1-SNAPSHOT jsp sample which failed in 2.1.1 due to missing 2.1
dependencies).
I was a bit thrown off by all of this since we didn't have to make the
same change for the download list when Geronimo 2.1 was released even though
we did update the catalog. This was because the version of the catalog was
already specified as 2.1 even while the server itself was still
2.1-SNAPSHOT. I wonder if it is wise to have the catalog listed as if
released even when the dependent server (and plugins) are not. BTW, this is
also the current case for Geronimo 2.2 and it's catalog. Thoughts?
Joe
