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
