On 30/11/2008, at 11:04 AM, Benjamin Bentmann wrote:
Hi,
In the light of MNG-3866 [0], Shane and I had a short discussion
what should be the right behavior during model inheritance for
handling plugin definitions with different versions. Apparently,
that is something to discuss in the context of the community ;-), so
please comment.
Maybe I'm missing something but that issue seems to indicate a bug
regardless since the configuration is completely lost instead of
duplicated (assuming your latter example is complete).
On 30/11/2008, at 11:24 AM, Shane Isbell wrote:
My primary concern is as follows. Say there is a version 1.1 of a
plugin
specified in the pluginManagement section and that was joined with a
plugin
of version 1.0. The plugin configuration information may be completely
incompatible. Also if you do the key off of version, you can define
the same
plugin with different versions and different configs in the same
pluginManagement section.
Is there a use case for multiple versions of a plugin running on the
same project? I'm concerned this adds some confusion in two ways:
* pluginManagement to dependencyManagement starts to behave
differently - you won't actually be able to use it to apply a single
version across a project
* it could become unclear when a plugin will be merged vs when it will
be a second instance
I would see the first thing coming out being an enforcer rule to make
sure you use a version consistently.
Some notes on the behaviour:
Is this something for a modelVersion increment? It seems this would
break existing projects that are expecting them to merge, relying on
the version mediation.
In the current version I think multiple definitions of a single plugin
(whether the version matches or not), are ignored, so they will need
to be changed to be honoured if they haven't already to be consistent
with the new inheritance model.
Also the specific example that was given had no version at all - we
discussed this at length before and it would seem in this case to make
even more sense to require that the version be specified.
On 30/11/2008, at 11:47 AM, Jason van Zyl wrote:
The case where the version is taken into consideration is the proper
way. As Shane already mentioned there is the case where
configuration may be different, but for whatever reason you may need
a plugin version that requires a different version of the plugin
API. Something that will change in 3.x is the ability to isolate an
execution environment given any set of artifacts. So in concrete
terms it means that each version of the plugin API will have its own
execution environment. In this way the old plugin API can be
supported forever and a new API, with plugins based on that, can co-
exist peacefully together indefinitely.
When you say "will change", does it already work, or is this likely to
cause problems in the interim?
- Brett
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
