On Tue, Jan 1, 2013 at 12:15 PM, Martin Gainty <[email protected]> wrote: > > so in other words execution with no goal bound.. will rollback to the > declared defaultGoal?http://maven.apache.org/pom.html > (i wonder if perhaps the defaultGoal is incorrect for what i'm seeing in > surefire) > thanks Steve ..and Happy New Year, > Martin
Martin, 'fork' in the sense of a forked execution declared in plugin metadata is completely different from what happens when surefire forks. > ______________________________________________ > ..place long-winded disclaimer here.. > Date: Tue, 1 Jan 2013 11:22:34 -0500 >> Subject: Re: A subtlety with forked executions, looking for advice >> From: [email protected] >> To: [email protected] >> >> On Tue, Jan 1, 2013 at 10:15 AM, Stephen Connolly >> <[email protected]> wrote: >> > 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) >> >> thanks. This implies that a forked execution of a mojo had better not >> depend on something produced in the reactor. I'm not sure that's >> unreasonable, even if it painted me into a pretty small corner in the >> license-maven-plugin due to my unwillingness to turn it into a >> multi-module project. >> >> >> > >> > >> > 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] >> >> >> >> >> >> --------------------------------------------------------------------- >> 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]
