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
