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