On Tue, Jan 1, 2013 at 7:43 PM, Martin Gainty <[email protected]> wrote: > > 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, 'fork' is a term of art from Unix, that has been applied in different ways in different places in Maven. A Forked Maven Execution means that a particular Maven goal is declared to 'fork' some other execution. For example, many reporting plugins will fork an execution because they require, say, 'compile' to have run for them to do their work. There is no new JVM, just an extra execution sequence. For surefire, javadoc, and other plugins, 'fork' just means 'don't run this in the Maven JVM; make a new JVM to run it in.' > > 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] >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
