geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: compatibility plugins
Date Wed, 27 Aug 2008 06:59:46 GMT

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 <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