On 17 May 2010 10:25, Frederic Camblor <fcamb...@gmail.com> wrote: > Hi Stephen, > > I agree with you, I'll surely use the script-like approach. > > Nevertheless, I'd like to point I don't want to "reinvent the wheel" with > my > own lifecycle. > > I undestand your position which is "let's standardize lifecycles : this > way, > we'll can provide out-of-the box features and maintain homogeneity between > plugins". > I understand, then, the fact that you shouldn't encourage creation of new > lifecycles (this is perhaps the reason why there is a big lack in the > documentation about this point ?). > > In my specific case, there is a good reason why I don't why to plug the > "clean copy-dependencies my-home-made-plugin-goal" on the default lifecycle > : I want to execute this specific lifecycle "by hand" (for example, after a > change in the <dependency> section in my pom). >
But your plugin bindings should ensure that your build works for a clean checkout no matter what. If you need to run something else to get your build to work, then you have not populated the standard lifecycle correctly... what it sounds like is that you are doing stuff that should be in the standard lifecycle, but you have not figured out how/where to bind it (or the plugins you are using to not provide the caching/prevent redundant operation support) you require. > Plugging this on the default lifecycle implies some problems, especially > when using the maven-release-plugin (ex: first step which verify if no > local > modifications has been made is blocking sometimes). > > I think maven users will always have specific needs that can't be satisfied > by the default (or standards) lifecycle nor "all-made-plugin". > To my mind, maven users should have the possibility to create their own > lifecycles if they understand the pros & cons of doing so (no problems if > there are lots of disclaimers like "creating your own lifecycle is bad ! > Maven team doesn't guarantee the good execution of this lifecycle in the > next version of maven"). > I find too bad to say "if you want to chain maven plugins, then call maven > via ANT or shell scripts" > > Frédéric > > On Mon, May 17, 2010 at 9:51 AM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > You are completely off standard maven behaviour. > > > > easiest solution is to create two files: myAlias.sh and myAlias.bat > > > > myAlias.sh > > #!/bin/sh > > mvn clean:clean dependency:copy-dependencies ... > > > > myAlias.bat > > @mvn clean:clean dependency:copy-dependencies ... > > > > Either that or use ANT. > > > > Maven has a standardised lifecycle for a reason.... if you don't like the > > standardised lifecycle, either use ANT or change your preferences > > > > ;-) > > > > -Stephen > > > > On 17 May 2010 08:42, Frederic Camblor <fcamb...@gmail.com> wrote: > > > > > Hi all, > > > > > > I'm wondering if something in maven (a plugin for example) could help > me > > to > > > chain different plugin goals, not bounded to the default maven > lifecycle. > > > > > > My particular example is the fact that I'd want sort of maven alias > > > allowing > > > to say "when I launch 'mvn <myAlias>' I'd want to chain clean:clean, > > > dependency:copy-dependencies and other home made plugin not bound to > the > > > default lifecycle (no need to validate, compile, package etc...)". > > > I just browsed the existing maven plugins in apache & codehaus and it > > > doesn't seem such a plugin exists. > > > > > > Am I completely off the standard maven behaviour ? > > > > > > I tried, too, to create a custom lifecycle in my "home made plugin", > > which > > > would call clean:clean and dependency:copy-dependencies before > executing > > my > > > plugin main goal .. but I didn't succeeded due to the lack of > > documentation > > > about new lifecycle creation (not bound to existing "default", "clean" > > and > > > "site" lifecycles) :-( > > > *(In every maven plugins I looked at, only the maven release plugin > seems > > > to > > > create its own new lifecycle ... but I admit this plugin seems really > > > complicated to understand !)* > > > Would you have some pointers/advice about this problematic ? > > > > > > Thanks in advance. > > > Frédéric > > > > > >
