geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lin Sun" <linsun....@gmail.com>
Subject Re: compatibility plugins
Date Wed, 27 Aug 2008 02:12:54 GMT
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).

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
>

Mime
View raw message