I feel like this is pretty low on the list of problems to be solved, but if the allowed phases can be a wildcard, then I guess I'm neutral on the idea. I think things like pom versioning are far more pressing.
On Fri, May 22, 2009 at 8:10 PM, Jason van Zyl <jvan...@sonatype.com> wrote: > > On 22-May-09, at 4:36 PM, John Casey wrote: > > >> >> Jason van Zyl 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. >>> >> >> I don't think it's more intuitive to have this proliferation of new mojos, >> simply to handle explicitly all the potential places where it might be >> appropriate to use a particular piece of build logic. As it is in the >> assembly plugin, we have five or more mojos (owing to legacy issues) that do >> 99% the same thing, but they're named differently to handle the 1% >> difference in logic. Actually, the 1% difference is now accounted for almost >> completely in the shared code, so the 1% difference is a legacy notion as >> well. Now, in your approach, I'll have to create at least several more mojos >> to handle cases where people want to use the assembly plugin in different >> phases. I simply cannot remove the '@phase' annotation, because in 80% of >> cases the user wants to use a dependencySet which requires dependency >> resolution, so providing '@phase package' eliminates configuration (by >> providing a convention) for 80% of use cases. >> > > You don't need a proliferation of mojos, you would specify what phases you > know to work. If you can account for a single mojo to work in multiple > phases and cover all the different logic then you have a single mojo. My > point is state what you do well, if the rest is unsure then Maven should > stop. I'm not talking about what Maven does now, I'm talking about how to > ideally stop users from stepping into a mistake. I like the idea of a > default phase and allowed phases. > > >> I think it's a mistake to enforce your assumptions about the quality of >> tests and/or code in plugins. It would truly be a case of coding for the >> lowest common denominator, and imposing a serious penalty on plugins that >> have legitimate reasons for leaving the default + configuration in place. >> > > Coding for the lowest common denominator? How do you see a developer of a > mojo who clearly states where the mojo runs because they've tested it and > know this to be the lowest common denominator? > > >> 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. >>> >> >> I'm all for this sort of documentation, telling users where a particular >> plugin is safe to run. But let's not throw the baby out with the bathwater >> here. There are cases where plugins could be used almost anywhere in the >> build process (especially if they're not producing something involved in the >> "main line" of compiling/testing/etc. the actual source code). >> > > That's if that's the case then they would have no default phase and be > allowed everywhere. If that's the case for the plugin the contract in the > mojo says that. Plugins that are found to have worthless contracts will soon > not be used by people. > > And frankly, there are also cases where some builds get pretty crowded in >> certain lifecycle phases, and it's helpful to get a little creative with >> phase bindings in cases where something has to happen "at some point" before >> something else, but it doesn't necessarily matter when. >> > > I think this is indicative of other problems. If there is no clear place to > put something, or moreover no clear way to order within a phase. Again I'm > not talking about what we're saddled with now in 2.x but what the system > could and should be like. > > >> Of course this is a little vague, but that's the point; we cannot possibly >> account for every single concrete build use case in the entire world. >> > > We don't have to, but mojos can certainly have tighter contracts and if > something is not meant for a particular lifecycle that will also be more > clear. > > We don't have the infrastructure to document them, nor do we want to >> engage in the endless rounds of releases required to support that extra, >> marginal use case that walks in. We need to provide a tool that operates in >> a declarative way at build time, but still offers users just enough wiggle >> room to fit Maven responsibly around their own needs. Is this a balancing >> act? Of course it is, and not all of the resulting builds will look like >> elegant masterpieces of design. But the alternative is to tell those users, >> "Sorry, come back later when we release a new version that accommodates your >> use case." We have to try to do the right thing, but users absolutely must >> have enough rope to hang themselves, too. >> >> Tightening the usage of @phase will eliminate a lot of critical >> flexibility here. >> > > We'll agree to disagree then. > > > >> -john >> >> >>>> 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 >>> >> >> --------------------------------------------------------------------- >> 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 > ---------------------------------------------------------- > > A man enjoys his work when he understands the whole and when he > is responsible for the quality of the whole > > -- Christopher Alexander, A Pattern Language > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
