I don't think we should take away the ability of a user to override a phase in a plugin. For things like the dependency plugin, I specify a sensible default, but there are many valid cases to run that plugin in other phases, I do it myself. I tend to think the current functionality is working as intended, but I personally wouldn't do it that way. I like to see my executions clearly lined up with the phase and goal and config. I can count on one hand the number of times I've invoked multiple goals from a single plugin at the same time.
Having ITs to guarantee this functionality remains is needed if they don't exist already (i'd bet they don't) On Fri, May 22, 2009 at 3:52 PM, Jason van Zyl <jvan...@sonatype.com> wrote: > > On 22-May-09, at 3:23 PM, Benjamin Bentmann wrote: > > Jason van Zyl wrote: >> >> Or if the assembly plugin is truly a utility player then have no >>> suggested binding. [...] I think the phase as a suggestion is probably just >>> confusing. >>> >> >> I don't think providing defaults like a default phase binding in this case >> is confusing. It's just convention over configuration, isn't it? >> > > Changing a source directory does not change the behavior of a build. The > convention for something designed to be truly pluggable. Changing the phase > the assembly plugin alters the way it works. There is the weirdo magic, as a > case in point, where depending on what phase you are in you might get a > directory or an archive as a resolved artifact. Then you're starting to look > for files or directories in your plugin ... so I don't think this is a case > of convention over configuration here. I think a mojo is either designed to > work doing a single thing in a single phase of the lifecycle, or it's a > utility player. Assigning a "default" phase only to have it be changed by a > user likely means the mojo has not been tested in this case and will more > likely then not cause someone confusion or just plain not work. We could > even do something like @phase package,install if you truly think something > belongs and has been tested to run in those phases. > > The default value saves one from typing and also provides a hint (not a >> restriction) about the major (but not the one and only) usage of a goal. >> >> Hoping that we will leave some decisions to the user, not the tool... >> >> > The decisions that can be made by the user have to be options that were > tested by the developers. If the developer was truly responsible for writing > a mojo and was somehow made to incur the cost of support then I'm willing to > bet that they would limit how that mojo was used. I think it would be fine > to allow a developer to specify all the phases the plugin is known to run in > and then the user works within the known set of viable conditions. I think > we need to be very realistic about what can be supported and I think this > ultimately benefits everyone. If a system lets you do something then one > should reasonably expect it to work. There are already complete > free-for-alls for people to use and I think we have to consider allowing > less but works exactly as advertised. > > >> Benjamin >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/SonatypeNexus > http://twitter.com/SonatypeM2E > ---------------------------------------------------------- > > Our achievements speak for themselves. What we have to keep track > of are our failures, discouragements and doubts. We tend to forget > the past difficulties, the many false starts, and the painful > groping. We see our past achievements as the end result of a > clean forward thrust, and our present difficulties as > signs of decline and decay. > > -- Eric Hoffer, Reflections on the Human Condition > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
