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