Just looking at that enforcer again, that's crazy that you need all
those components in there to do again what Maven just already did
internally. You have to, and I'm not faulting you. You probably
learned more about the internals then you wanted to. We can't do
anything in 2.0.x but this certainly has to be fixed in 2.1. This is
another major subsystem that has no real abstraction and makes things
like finding out simple things about the model someone is about to
use to build very hard.
On 15 Aug 07, at 8:10 AM 15 Aug 07, Jason van Zyl wrote:
Hi Brian,
Thanks for adding that rule, I have incorporated into the best
practices guide for the client I'm working with and it stands
generally I believe as something any good build should do.
There are a couple things to note just so I convey the goal, and I
think the work that John is doing with the build plan also plays a
part here.
In this particular case the enforcer with this rule should walk and
find all of the plugins without versions, including the ones in the
lifecycle that may be running implicitly for a given packaging:
1) We should be able to notify the user of all the plugin
declarations in violation
2) This information should be captured in a way by the enforcer so
that it can be used in an IDE
3) We should be able to do something with this information and not
make it onerous to the user to correct. So we might eventually
offer a way to find the latest versions, create a chunk of a
pluginManagement section, or anything else that makes it easy to
correct.
John is working on what's called the build plan, which will
eventually be the sum total of everything that _will_ execute and
its configuration. I think the enforcer being able to act on the
build plan would be very powerful. And when we fix the problem
where the raw models are getting are getting tainted then you will
have accurate information. I'm just suggesting that you talk with
John as the build plan will ultimately be one stop shopping for
what is about to happen and then we can proactively make assertions.
Just to note that one very ingenious work around for this problem
(and it is a problem unless you know about every Maven plugin you
use and define versions) is to create a profile, and within that
profile specify a plugin repository and then disable it for
releases and snapshots and this prevents the plugin version manager
from being able to resolve versions and the build dies. It doesn't
provide all the information in a nice way but does the job of
letting a build person no you have some potential instability.
Someone could do something stupid with a clean plugin release, and
if it got automatically updated would throw off your whole system.
So this locking down of plugin versions is absolutely critical in
corporate environments and should be a best practice to follow.
This new rule in the enforcer will actually make this feasible.
Thanks for whipping that up!
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
