geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject Re: compatibility plugins
Date Wed, 27 Aug 2008 18:27:10 GMT


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

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.


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

View raw message