On 8-Feb-08, at 4:52 PM, Carlos Sanchez wrote:
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.
Sure, but that's a minor inconvenience for us developing plugins in
the default lifecycle, but for the user if it helps then it's a low-
tech solution that will help folks. I agree with Brian.
People are miseducated and that's our fault. The new version of the
enforcer plugin helps, but if this helps stabilize things for those
who haven't yet figured out that putting versions on your plugins is a
good idea then so be it.
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]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
A party which is not afraid of letting culture,
business, and welfare go to ruin completely can
be omnipotent for a while.
-- Jakob Burckhardt
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
