On Aug 26, 2008, at 7:55 PM, Lin Sun wrote:
In a geronimo plugin's metadata, could we allow the users to choose
whether or not the server should eliminate the dependency version
checking if the server is v2.1.2+? If the module name (for example,
jasper or jasper-deployer) is there and the version is slightly
different, we will just use the existing module in the server.
I guess this is sorta like the artifact alias, but the difference is
that a user can configure this on a geronimo plugin basis and
hopefully using just one property, for example
<skipDependencyChecking>[2.1.2,)</skipDependencyChecking>
So far I don't like the uncertainty I think this would introduce. If
I saw a more worked out example of what you have in mind I might like
it better.
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>
thanks
david jencks
Lin
On Tue, Aug 26, 2008 at 10:34 PM, Joe Bohn <[EMAIL PROTECTED]>
wrote:
That is another aspect of the problem. There are really 2 aspects:
1) dependencies that the plugin needs. This is what we are trying
to solve
the with the artifact-aliases defined in the compat* plugins
referenced in
this note.
2) The geronimo-version in the geronimo-plugin(s).xml. This
indicates if
the plugin should even be shown as eligible for installation on the
current
server. In order to even get to the point of leveraging what I
have with
the compatibility plugins we need to either omit the server version
(as we
are currently doing in samples) or loosen the version checking. I
think it
makes sense to allow plugins within the same major.minor version to
be
eligible for installation.
Joe
Lin
On Tue, Aug 26, 2008 at 9:29 PM, Joe Bohn <[EMAIL PROTECTED]>
wrote:
We've had numerous discussions on how to facilitate plugins
created for
an
earlier release running on a later release. It seems that the
only
viable
alternative we keep coming back to is to create artifact alias
entries to
map the older versions to the latest version. I'd like to have
some
solution (even if imperfect) for Geronimo 2.1.3 so plugins we've
released
for previous versions might have some hope of running on 2.1.3. My
primary
concern is that samples that we hope to release for 2.1.2 will also
install
on 2.1.3 using this mechanism. Perhaps even older plugins (like
directory)
could be installed in 2.1.3.
To that end, I've created 3 compatibility plugins (not yet
checked in)
under
the server /plugins.
compat21 - includes alias mappings from 2.1 cars to 2.1.3 cars
comapt211 - includes alias mappings from 2.1.1 cars to 2.1.3 cars
compat212 - includes alias mappings from 2.1.2 cars to 2.1.3 cars
I've already verified that I can install the 2.1.2 samples in a
2.1.3
server
image using the compat212 plugin.
The structure is such that once we release a 2.1.3 version I
anticipate
that
we would create a compat213 for inclusion with the other compat*
plugins
in
2.1.4.
These aren't very sophisticated. They simply include all artifact
alias
entries for all cars shipped in the specified lower level release
and map
them to the equivalent 2.1.3 release car. There are no tomcat/
jetty
specific versions of the plugins ... just one compat plugin per
prior
release with entries for all of the cars shipped with that
release. I
don't
think the extraneous entries will cause any harm in the opposite
server.
Also, I'm sure there are client cars included int he list that
can be
removed (or perhaps moved to a client-artifact-aliases list). I
hope you
will help me clean it up once I check it in.
So now the questions:
1) I'd like to check these into branches/2.1 ... should I? Just
thought
I'd
check in case there are strong objections to this approach.
2) I'd like to include all 3 compat* plugins in all 2.1.3
assemblies that
we
ship by including them in the boilerplate. This will provide
"out of the
box" downward compatibility for plugins that have dependencies on
the
lower
level cars. Any concerns?
3) Are there other entries that we should include beyond the cars
included
in the javaee5 assemblies?
4) Do we need to do something equivalent for client-artifact-
aliases?
What
should be included there?
Thanks,
Joe
