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