geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <joe.b...@earthlink.net>
Subject Re: compatibility plugins
Date Wed, 27 Aug 2008 20:03:07 GMT
One more question below

Joe Bohn wrote:
> 
> David,
> 
> I tried your recommendation for using the commonInstance with lots of 
> ${} variables.   It seems to be working well - thanks! At the moment 
> I've added entries to map 2.1, 2.1.1, and 2.1.2 to the current release.
> 
> I still have some questions though that I think you can help me with:
> 1) I didn't include "server=client".  My understanding is that this adds 
> the entry to the client-artifact-aliases file which would not be 
> desirable - right?
> 2) What should I do about the client aliases?  Would it make sense to 
> add specific artifact-aliases entries to the relatively few client cars 
> with server=client specified?  My understanding is that c-m-p will skip 
> adding the commonInstance entries if specific artifact-alias entries are 
> included.
> 3) It would be nice if I could add some more commonInstance entries in 
> /plugins/client/pom.xml but I've seen comments that multiple nested 
> entries have issues. Do you know if that is the case?
4) There is already an artifact-alias entry for j2ee-server mapping from 
  a null version to the current version.  Do you know why this is 
needed?  Can we either remove it or perhaps include it in commonInstance 
so that all modules have a mapping of // to the current version?
> 
> Updating c-m-p to process a new attribute might still be a good idea 
> because it could provide a finer degree of control.  However, so far 
> this seems like a good enough solution for now.
> 
> Thanks,
> Joe
> 
> 
> 
> Joe Bohn wrote:
>> David Jencks wrote:
>>
>>> 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>

>>>
>>
>> Yes, I recall your proposal and I liked it.  I was originally thinking 
>> you were proposing an entry for the immediate prior version and so 
>> when I considered another level out (aka 2.1.4) it seemed to 
>> breakdown. However, I guess there is no reason that we could not 
>> include multiple entries as you noted above. I'll look into this some 
>> more.
>>
>> A variation on this idea would be to add into the pom an attribute 
>> where we can specify compatible versions.  The car-maven-plugin could 
>> then use these attributes to generate the alias entries in the 
>> geronimo-plugin.xml.  This might allow us to specify compatible 
>> versions in the top level pom (just one primary place to maintain) for 
>> all plugins given that we typically will want the same behavior for 
>> all plugins shipped with the server.
>>
>> I pushed the comprehensive plugin idea because it appeared that we 
>> were short on time for a 2.1.3 release (there is a proposed code 
>> freeze date of this Friday) and whatever we do I think we need to get 
>> something into 2.1.3.
>>
>> Joe
>>
> 
> 


Mime
View raw message