definition of fork must've been lost in translation or maybe a context switch somewhere ... to avoid any confusion fork in plugin-metadata means ______________________________fork in maven-surefire-plugin means______________________________
Martin ______________________________________________ depends on the meaning of the word 'is' is...author has been forgotten > Date: Tue, 1 Jan 2013 12:40:39 -0500 > Subject: Re: A subtlety with forked executions, looking for advice > From: [email protected] > To: [email protected] > > 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] >
