geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: compatibility plugins
Date Wed, 27 Aug 2008 22:07:14 GMT

On Aug 27, 2008, at 11:27 AM, 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?

correct.  I just picked an example that happened to be for a client.

> 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.
Hopefully that will work.
> 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?

I don't remember too well but I think that the "latest" commonInstance  
replaces any "farther" commonInstance.  If so that would be the  
behavior we want.

If not, I guess we could look into having 2 parent poms, one for  
client and one for server.  This will take some experimentation I think.
> 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.

Lets try it and see how it works and if there are problems.

david jencks

> 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

View raw message