Lin Sun wrote:
I wonder if there is a way to eliminate the need of compatibility
plugin for samples to install on multiple maintenance releases of
geronimo (such as 2.1.2, 2.1.3, etc.).
I remember in the plugin catalog, there is a property called
geronimoVersion. I wonder if we could allow users to specify a
geronimo plugin to run on multiple maintenance releases of geronimo in
this property, for example below means that the geronimo plugin can
run on G server v2.1.2+.
<geronimoVersion>[2.1.2,)</geronimoVersion>
Since we know there are only minor changes in maintenance releases,
when this property is set to allow the geronimo plugin to run on
multiple G releases, maybe we could loose our plugin validation a bit
to allow the installation to go through? I can see this function
being useful for most of our samples which we don't change between
maintenance releases (or even major releases).
That is another aspect of the problem. There are really 2 aspects:
1) dependencies that the plugin needs. This is what we are trying to
solve the with the artifact-aliases defined in the compat* plugins
referenced in this note.
2) The geronimo-version in the geronimo-plugin(s).xml. This indicates
if the plugin should even be shown as eligible for installation on the
current server. In order to even get to the point of leveraging what I
have with the compatibility plugins we need to either omit the server
version (as we are currently doing in samples) or loosen the version
checking. I think it makes sense to allow plugins within the same
major.minor version to be eligible for installation.
Joe
Lin
On Tue, Aug 26, 2008 at 9:29 PM, Joe Bohn <[EMAIL PROTECTED]> wrote:
We've had numerous discussions on how to facilitate plugins created for an
earlier release running on a later release. It seems that the only viable
alternative we keep coming back to is to create artifact alias entries to
map the older versions to the latest version. I'd like to have some
solution (even if imperfect) for Geronimo 2.1.3 so plugins we've released
for previous versions might have some hope of running on 2.1.3. My primary
concern is that samples that we hope to release for 2.1.2 will also install
on 2.1.3 using this mechanism. Perhaps even older plugins (like directory)
could be installed in 2.1.3.
To that end, I've created 3 compatibility plugins (not yet checked in) under
the server /plugins.
compat21 - includes alias mappings from 2.1 cars to 2.1.3 cars
comapt211 - includes alias mappings from 2.1.1 cars to 2.1.3 cars
compat212 - includes alias mappings from 2.1.2 cars to 2.1.3 cars
I've already verified that I can install the 2.1.2 samples in a 2.1.3 server
image using the compat212 plugin.
The structure is such that once we release a 2.1.3 version I anticipate that
we would create a compat213 for inclusion with the other compat* plugins in
2.1.4.
These aren't very sophisticated. They simply include all artifact alias
entries for all cars shipped in the specified lower level release and map
them to the equivalent 2.1.3 release car. There are no tomcat/jetty
specific versions of the plugins ... just one compat plugin per prior
release with entries for all of the cars shipped with that release. I don't
think the extraneous entries will cause any harm in the opposite server.
Also, I'm sure there are client cars included int he list that can be
removed (or perhaps moved to a client-artifact-aliases list). I hope you
will help me clean it up once I check it in.
So now the questions:
1) I'd like to check these into branches/2.1 ... should I? Just thought I'd
check in case there are strong objections to this approach.
2) I'd like to include all 3 compat* plugins in all 2.1.3 assemblies that we
ship by including them in the boilerplate. This will provide "out of the
box" downward compatibility for plugins that have dependencies on the lower
level cars. Any concerns?
3) Are there other entries that we should include beyond the cars included
in the javaee5 assemblies?
4) Do we need to do something equivalent for client-artifact-aliases? What
should be included there?
Thanks,
Joe
