I'm pretty much +1
Another behavior that would change is if I build and install a plugin
in my local repo, it won't be used. I'd have to explicitly set it in
the pom.
On Feb 8, 2008 4:41 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> I know it's been discussed before in the context of various other issues
> and solutions, but I want to discuss locking down core plugins in the
> super pom _for_ 2.0 _only_.
>
>
>
> Normally we get into some large protracted discussions about better
> solutions and drawbacks/benefits of them, meanwhile the users suffer the
> wrath of auto plugin updates. Considering the amount of time I spent
> writing the enforcer requirePluginVersions rule, you can safely assume
> you don't need to convince me that the _right_ way is to lock them down
> in your poms. I already believe that. I also think that there is
> probably a better solution, whether it's plugin packs (which I don't
> agree with at this point) or something else. We can agree that whatever
> else it is that may be done will come in 2.1 and for a large portion of
> users 2.1 in production is a long way off and we continue to suffer "bad
> press" about the instability of Maven in the mean time. So I'd like to
> put those discussions aside for now and simply discuss the ramifications
> of defaulting the core plugin versions in the super pom in 2.0 only.
>
>
>
> I see two main benefits:
>
> 1. Those who have followed best practice and locked their versions
> down will not be affected by this at all. The normal inheritance rules
> will apply, and we'll put these versions into the pluginManagement
> section of the super pom.
>
> 2. Those who have not locked their versions down will only be
> affected by gaining stability in between maven releases. If they want a
> new plugin before the next Maven release, they will have to follow the
> best practices and lock their version down to the new version. (this
> actually informs people and encourages them to learn how to do
> that...but when _they_ are ready to do it because they are motivated to
> grab a new release, not when they least expect it because we pushed out
> a plugin that broke their build)
>
> 3. The change is very simple, can be done quickly and has little
> harm of creating more problems.
>
>
>
> The only drawback I can see is that it lulls people into a false sense
> of security because _less_ plugins auto update.... Not all of them.
> Certainly we won't lock down every plugin in existence and those
> plugins will still be subjected to the auto update. Again, I'm not
> suggesting we solve the world here, but this is a simple step forward to
> reduce the impact of one of the most frequent complaints of the users.
>
>
>
> If you can think of some serious drawbacks to this approach, speak now
> for forever hold your peace ;-)
>
>
>
> --Brian
>
>
>
>
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
