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:14:16 GMT

On Aug 27, 2008, at 1:03 PM, Joe Bohn wrote:

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

I guess that fixes the version so that after this plugin is installed,  
c-m-p wont try to pull in later versions even if you are assembling a  
server from a repo with later versions in it.

If this guess is right :-) then we probably do want this in every  
plugin so putting it in the common instance would be a good idea.

david jencks

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

View raw message