Custom mojo/lifecycle questions
List, I'm investigating the use of Maven as a project lifecycle management tool for solution deployment projects that we do at my company. I have so far defined 2 goals in my mojo, validate and install, which correspond to the 2 initial phases of our specific lifecycle (validate install patch overlay load test report). As far as my current understanding goes, it is not (yet?) possible to define an entirely custom lifecycle in Maven, only to map mojo goals to phases in one of the existing lifecycles, the default lifecycle being, as it were, the default. My components.xml and lifecycle.xml files are as follows: component-set components component roleorg.apache.maven.lifecycle.mapping.LifecycleMapping/role role-hintfast-gs-project/role-hint implementationorg.apache.maven.lifecycle.mapping.DefaultLifecycleMapping/ implementation configuration phases validatecom.fastsearch.gs.mojo:maven-esp-plugin:validate/validate compilecom.fastsearch.gs.mojo:maven-esp-plugin:install/compile /phases /configuration /component /components /component-set lifecycles lifecycle idfast-gs-project/id phases phase idvalidate/id executions execution goals goalvalidate/goal /goals /execution /executions /phase phase idcompile/id executions execution goals goalinstall/goal /goals /execution /executions /phase /phases /lifecycle /lifecycles (Note that I have mapped the 'install' goal to the 'compile' phase in the default lifecycle.) However, when I run Maven on a sample project, its behaviour i somewhat strange: C:\cygwin\home\blehra\eclipsework\default\sampleprojmvn esp:install [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'esp'. [INFO] [INFO] Building Sample Project [INFO]task-segment: [esp:install] [INFO] [INFO] Preparing esp:install [WARNING] Removing: install from forked lifecycle, to prevent recursive invocation. [INFO] Preparing esp:validate [WARNING] Removing: install from forked lifecycle, to prevent recursive invocation. [WARNING] Removing: validate from forked lifecycle, to prevent recursive invocation. [INFO] No goals needed for project - skipping [INFO] [esp:validate] [INFO] Project is valid [INFO] Preparing esp:validate [WARNING] Removing: install from forked lifecycle, to prevent recursive invocation. [WARNING] Removing: validate from forked lifecycle, to prevent recursive invocation. [INFO] No goals needed for project - skipping [INFO] [esp:validate] [INFO] Project is valid [INFO] [esp:install] [INFO] [INFO] FAST Maven Installer starting up... [INFO] Customer:customer [INFO] Project: project [INFO] Target env: test [INFO] Local host: ablehr.laptop.net [INFO] Local base dir: C:\cygwin\home\blehra\eclipsework\default\sampleproj [INFO] Install profile: basedir\custom\resources\test\InstallProfile.xml [INFO] [INFO] Reading install profile and connecting to hosts... [INFO] ESP version: 5.1.3 [INFO] Platform:Linux [INFO] Remote command: SSH2 [INFO] Target hosts: [INFO] - test48.oslo.fast.no [INFO] - test66.oslo.fast.no [INFO] - test117.oslo.fast.no (admin) [INFO] - test123.oslo.fast.no [INFO] [INFO] Checking if ESP 5.1.3 is installed on hosts in configuration... [INFO] - test48.oslo.fast.no: Running OK [INFO] - test66.oslo.fast.no: Running OK [INFO] - test117.oslo.fast.no: Running OK [INFO] - test123.oslo.fast.no: Running OK [INFO] ESP 5.1.3 is installed on all hosts in configuration, nothing to do. [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 16 seconds [INFO] Finished at: Wed Sep 12 13:05:53 CEST 2007 [INFO] Final Memory: 2M/5M [INFO] C:\cygwin\home\blehra\eclipsework\default\sampleproj My questions: 1. The 'validate' goal is invoked twice in a row; why and how to avoid? 2. I'm getting the message 'No goals needed for project - skipping', which according to a posting here from Brett Porter on 17 Nov 2005 means that 'the module has a packaging of POM or something else that doesn't define any goals for the lifecycle step you are running'. Should I be worried? 3. I'm getting warnings that goal has been
Re: Custom mojo/lifecycle questions
Hello, In your mvn command, you are invoing esp:install which means: - execute the mojo install in the plugin esp In your mojo's configuration you may have forked a lifecycle which would explain maven's behavior: - validate is executed twice, one for the mojo and once for the lifecycle the pom is packaged two - install is executed once to prevent recursive invocation HTH -- OQube software engineering \ génie logiciel Arnaud Bailly, Dr. \web http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Custom mojo/lifecycle questions
Thanks, this makes sense, if I invoke 'mvn install' instead, it works a lot better. In fact, if I invoke the default lifecycle phase 'compile' (which maps to esp:install), it works just fine (apart from the unwanted warning message), identical to how it behaves if I invoke 'install'. My understanding then of what happens is that a default lifecycle phase is invoked and that mvn (as intended) invokes all default lifecycle phases up to and including the invoked phase, but if and only of they are mapped to goals in components.xml. Is my understanding correct? The problem with this is that our lifecycle is *not* the default lifecycle. 'install' is the second to last phase in the default lifecycle, whereas it is only the second phase in our solution deployment lifecycle (which is: validate install patch overlay load test report). If I try to invoke a phase that is *not* in the default lifecycle (e.g. 'overlay'), I get the following error: [ERROR] BUILD FAILURE [INFO] [INFO] Invalid task 'overlay': you must specify a valid lifecycle phase, or a goal in the format plugin:goal or pluginGroupId:pluginArtifactId:pluginVersion:goal This also makes good sense. However, if I invoke the goal 'esp:overlay' instead, I'm back to executing single goals twice or even more often. Unless it is possible to invoke plugin:goal and still have mvn invoke goals only once and in order, it would seem that the only way out of this dead end would be to create a truly customised lifecycle, am I right? If so, can this be done by creating a custom LifecycleMapping implementation? I have looked at the DefaultLifecycleMapping class in an attempt to flesh out what needs to be done, but I didn't even manage to figure out how the private member variable 'lifecycles' ever gets assigned a value... :-| I remember seeing a posting from Jason van Zyl from about a month ago that all that's required to build a truly customised lifecycle is present in the current code base and that he was going to provide some examples shortly. I have yet to see the examples, though, so I am a bit uncertain as to whether this is really possible, particularly based on other postings stating that custom lifecycles are not and will not be supported in M2 due to their messing up inter-mojo dependencies and what not. Insights and recommendations highly appreciated! Thanks, - Anders. -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Insitu Sent: 12. september 2007 14:53 To: users@maven.apache.org Subject: Re: Custom mojo/lifecycle questions Hello, In your mvn command, you are invoing esp:install which means: - execute the mojo install in the plugin esp In your mojo's configuration you may have forked a lifecycle which would explain maven's behavior: - validate is executed twice, one for the mojo and once for the lifecycle the pom is packaged two - install is executed once to prevent recursive invocation HTH -- OQube software engineering \ génie logiciel Arnaud Bailly, Dr. \web http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Custom mojo/lifecycle questions
Thanks, this makes sense, if I invoke 'mvn install' instead, it works a lot better. In fact, if I invoke the default lifecycle phase 'compile' (which maps to esp:install), it works just fine (apart from the unwanted warning message), identical to how it behaves if I invoke 'install'. My understanding then of what happens is that a default lifecycle phase is invoked and that mvn (as intended) invokes all default lifecycle phases up to and including the invoked phase, but if and only of they are mapped to goals in components.xml. Is my understanding correct? The problem with this is that our lifecycle is *not* the default lifecycle. 'install' is the second to last phase in the default lifecycle, whereas it is only the second phase in our solution deployment lifecycle (which is: validate install patch overlay load test report). If I try to invoke a phase that is *not* in the default lifecycle (e.g. 'overlay'), I get the following error: [ERROR] BUILD FAILURE [INFO] [INFO] Invalid task 'overlay': you must specify a valid lifecycle phase, or a goal in the format plugin:goal or pluginGroupId:pluginArtifactId:pluginVersion:goal This also makes good sense. However, if I invoke the goal 'esp:overlay' instead, I'm back to executing single goals twice or even more often. Unless it is possible to invoke plugin:goal and still have mvn invoke goals only once and in order, it would seem that the only way out of this dead end would be to create a truly customised lifecycle, am I right? If so, can this be done by creating a custom LifecycleMapping implementation? I have looked at the DefaultLifecycleMapping class in an attempt to flesh out what needs to be done, but I didn't even manage to figure out how the private member variable 'lifecycles' ever gets assigned a value... :-| I remember seeing a posting from someone about a month ago that all that's required to build a truly customised lifecycle is present in the current code base and that some examples would be provided shortly. I have yet to see the examples, though, so I am a bit uncertain as to whether this is really possible, particularly based on other postings stating that custom lifecycles are not and will not be supported in M2 due to their messing up inter-mojo dependencies and what not. Insights and recommendations highly appreciated! Thanks, - Anders. -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Insitu Sent: 12. september 2007 14:53 To: users@maven.apache.org Subject: Re: Custom mojo/lifecycle questions Hello, In your mvn command, you are invoing esp:install which means: - execute the mojo install in the plugin esp In your mojo's configuration you may have forked a lifecycle which would explain maven's behavior: - validate is executed twice, one for the mojo and once for the lifecycle the pom is packaged two - install is executed once to prevent recursive invocation HTH -- OQube software engineering \ génie logiciel Arnaud Bailly, Dr. \web http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Custom mojo/lifecycle questions
Hello Anders, I was the one who triggered the mail from Jason as I and lot of other people had the same kind of questions than yours :) The net conclusion I came up to is that if you want to do something with custom lifecyles, you jsut have to live with the three lifecycles that exists right now: default, clean and site. Apart from the name problem, this is not really an issue: just pretend that compile = install, install = overlay, ... and everything will be ok. Also, there may some confusion between phases naming and mojo naming: It would have been better to name the phases 'phase1' 'phase2' ... You can think in terms of programs and functions: a mojo is a function, a phase and a lifecycle are programs. You have more than enough phases to create complex lifecycles. Actually, from a a theoretical point of view, as a plugin can trigger a lifecycle, I think you just need 2 phases to create a complex build tree ! As usual, I am not aware of your particular problem but what I would do would be to just stick to the default lifecycle, bind your mojos to it and don't care to fork lifecycles within the mojo themselves (it is always possible to do the binding in the pom) and use your custom packaging as the example you gave us. HTH -- OQube software engineering \ génie logiciel Arnaud Bailly, Dr. \web http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
