You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <ja...@maven.org> on 2007/08/15 08:10:50 UTC
Enforcer PluginVersionsDefined
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Enforcer PluginVersionsDefined
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Hi John,
At this point I'm not even thinking about modifying the build plan. I
just need to get at the lifecycle and the plugins bound (I don't even
care about the execution info...I just need to find out which plugins so
I can make sure they are resolved (go-offline) or have locked down
versions (enforcer). The info about the current lifecycle is there, I
can see it in the debugger or via reflection but it's not accessible in
a public way.
--Brian
-----Original Message-----
From: John Casey [mailto:jdcasey@commonjava.org]
Sent: Wednesday, August 15, 2007 10:37 AM
To: Maven Developers List
Subject: Re: Enforcer PluginVersionsDefined
One thing to note is that the build plan will be constructed _prior_
to any mojos executing, so modding that build plan implies you're
also getting in there ahead of the first mojo's
execution...otherwise, you don't have complete access to modify the
plan. This takes us out of the realm of standard mojo
implementations, and into that of custom components for Maven.
Currently, Maven provides very poor support for customizations like
this...even in 2.1/trunk.
We need to think about improving this somehow, IMO. For now, I can
probably provide a hook to the BuildPlanner functionality (or maybe,
the LifecycleExecutor right after the build planner is called) that
will post-process the build plan before its first use. Then, build
extensions _should_ be able to provide implementations for this hook.
Of course, all of this is only for 2.1-land...2.0.x is very, very
different in this part of the code.
-john
On Aug 15, 2007, at 2:10 AM, 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Enforcer PluginVersionsDefined
Posted by John Casey <jd...@commonjava.org>.
One thing to note is that the build plan will be constructed _prior_
to any mojos executing, so modding that build plan implies you're
also getting in there ahead of the first mojo's
execution...otherwise, you don't have complete access to modify the
plan. This takes us out of the realm of standard mojo
implementations, and into that of custom components for Maven.
Currently, Maven provides very poor support for customizations like
this...even in 2.1/trunk.
We need to think about improving this somehow, IMO. For now, I can
probably provide a hook to the BuildPlanner functionality (or maybe,
the LifecycleExecutor right after the build planner is called) that
will post-process the build plan before its first use. Then, build
extensions _should_ be able to provide implementations for this hook.
Of course, all of this is only for 2.1-land...2.0.x is very, very
different in this part of the code.
-john
On Aug 15, 2007, at 2:10 AM, 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
RE: Enforcer PluginVersionsDefined
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
This was definitely a learning experience in some areas I hadn't
explored before. As I was going through all the lifecycle muck, I kept
thinking "now I know why John redid this in 2.1." When I load the
DefaultLifecycleExecuter and view it in the debugger, lots of the info I
need is there, I just can't get at it. I think we could make it quite a
bit more usable in 2.0.x without major changes. We could create a few
private variables that hold the information discovered during execution,
like the lifecycle used and the plugin mappings. If we hold on to these
and then provide some getters that return _copies_, I think it would be
safe and slightly more usable. WDYT?
Also, the code to create the unmolested model tree should be abstracted
and made shareable.
The dependency:go-offline goal needs this lifecycle plugin list also so
I can make sure all plugins and their dependencies are resolved.
Currently it is just finding the ones in the pom.
Either way, I'm glad it seems to be working for you.
--Brian
-----Original Message-----
From: Jason van Zyl [mailto:jason@maven.org]
Sent: Wednesday, August 15, 2007 2:48 AM
To: Maven Developers List
Subject: Re: Enforcer PluginVersionsDefined
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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Enforcer PluginVersionsDefined
Posted by Jason van Zyl <ja...@maven.org>.
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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org