if phase is specified then goal is unused was my reading of the docs when I read them (a while back and I am lazy and have not gone looking at/for the docs since then)
On 1 January 2013 15:01, Benson Margulies <[email protected]> wrote: > My mystification just deepened. > > If @Execute only contains 'goal', and then the mojo is executed from > command line, all is well. > > If I add a 'phase=', then the command-line execution stops working. > That is, if I have both goal= and phase=, the goal seems to be > ignored. And since nothing in the pom explicitly binds the goal to the > phase, it never runs. > > Does this surprise anyone (else?)? > > > > On Tue, Jan 1, 2013 at 8:58 AM, Benson Margulies <[email protected]> > wrote: > > In the license-maven-plugin, there is a goal called > 'aggregate-add-third-party'. > > > > until this morning, it was annotated with: > > > > @Execute( goal = "add-third-party" ) > > > > This caused a problem. The add-third-party Mojo can read data from > > dependencies. So, if module (a) attached a resource, and module (b) > > went to read that resource in add-third-party, it failed. Why? > > > > Well, 'add-third-party' is not part of a lifecycle. So forking it > > executes nothing else. So, the dependency wasn't there in the reactor. > > > > Even if, by the way, the dependency was attached in an earlier phase > > than the aggregate-add-third-party, it didn't help, since the fork > > happens in the aggregating project before the modules happen. > > > > One solution to this is to add phase = SOMETHING to that @Execute, so > > that the execution that produces the resource has somewhere to live. > > Since the default phase for aggregate-add-third-party of > > generate-resources, does generate-resources lead to a risk of > > something circular? > > > > I suppose that another would be to define an entire lifecycle, and > > thus create a phase just for the purpose of allowing things to happen > > that feed add-third-party. Now the plugin would need to be listed as > > an extension, which is a pain. > > > > Anyone have another suggestion? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
