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:55:55 GMT
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>

Lin



On Tue, Aug 26, 2008 at 10:34 PM, Joe Bohn <joe.bohn@earthlink.net> 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 <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