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: [email protected] > 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]
