geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lin Sun" <>
Subject Re: compatibility plugins
Date Wed, 27 Aug 2008 13:55:55 GMT
I think what you proposed solves the prob of having a particular
sample release working with a prior server release.   However, it can
be rather expensive to release samples for every single G releases
(including minor releases).   I think there is also a need to release
samples with a particular G version and expect it to run on multiple
follow-on maintenance G releases.  An example is that we release
v2.1.2 samples that is tested with G 2.1.2 server and we want the
v2.1.2 samples to run on G 2.1.3, 2.1.4 and 2.1.5 when we release G
2.1.3, 2.1.4, 2.1.5, if there is no other change needed in the
samples.   This would save us from releasing samples with every single
maintenance release and the need of compatibility plugins.

To enable this per dependency, in a v2.1.2 sample plugin, a user can
specify something like:

<artifact-alias server="client"

At the plugin installation, we can replace [2.1.2,) with the actual
server version if the condition is met (server is 2.1.3, 2.1.4,

To enable this for all the dependencies of the geronimo plugin, in a
v2.1.2 sample plugin, a user can specify something like:

If this is specified, we can interprete it as creating the following
artifact-alias for ALL the dependencies that we expect to be avail on
a full javaee5 G server.   This would save the user from creating the
artifact-alias entries for the plugin's dependencies.

<artifact-alias server="client"



On Wed, Aug 27, 2008 at 2:59 AM, David Jencks <> wrote:
> On Aug 26, 2008, at 7:55 PM, Lin Sun wrote:
>> In a geronimo plugin's metadata, could we allow the users to choose
>> whether or not the server should eliminate the dependency version
>> checking if the server is v2.1.2+?   If the module name (for example,
>> jasper or jasper-deployer) is there and the version is slightly
>> different, we will just use the existing module in the server.
>> I guess this is sorta like the artifact alias, but the difference is
>> that a user can configure this on a geronimo plugin basis and
>> hopefully using just one property, for example
>> <skipDependencyChecking>[2.1.2,)</skipDependencyChecking>
> So far I don't like the uncertainty I think this would introduce.  If I saw
> a more worked out example of what you have in mind I might like it better.
> Rather than have separate compatibility plugins, I've thought in the past
> that each plugin could include aliases for the previous versions it's
> compatible with.
> So, each 2.1.3 plugin could explain how it can replace its own 2.1.2 version
> with e.g.
>                            <artifact-alias server="client"
> key="org.apache.geronimo.configs/client-security/2.1.2/car">org.apache.geronimo.configs/client-security/2.1.3/car</artifact-alias>
> For the 2.1.4 version of this plugin we'd have
>                            <artifact-alias server="client"
> key="org.apache.geronimo.configs/client-security/2.1.2/car">org.apache.geronimo.configs/client-security/2.1.4/car</artifact-alias>
>                            <artifact-alias server="client"
> key="org.apache.geronimo.configs/client-security/2.1.3/car">org.apache.geronimo.configs/client-security/2.1.4/car</artifact-alias>
> This kind of spreads out the compatibility plugin contents into all the
> individual plugins.
> We might be able to either write some c-m-p code to generate these or put it
> in the c-m-p common instance with a lot of ${} variables, maybe
>                            <artifact-alias server="client"
> key="${groupId}/${artifactId}/2.1.2/car">${groupId}/${artifactId}/${version}/car</artifact-alias>
> thanks
> david jencks
>> Lin
>> On Tue, Aug 26, 2008 at 10:34 PM, Joe Bohn <> wrote:
>>> 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 <>
>>>> 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. 
>>>>> 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

View raw message