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 <joe.bohn@earthlink.net> 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
>>
>
|