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

Reply via email to