> Date: Tue, 1 Jan 2013 20:04:22 -0500
> Subject: Re: A subtlety with forked executions, looking for advice
> From: [email protected]
> To: [email protected]
>
> 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.MG>In other words ..what I would call an " in process
> task."..if i understand correctly
MG>I like the 'queueing' nature of tasks within a single JVM
>
> 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.'MG>i'm considering this
> behavior to create a new plugin.xml then on exit (of the initial JVM proc)
MG>allow consequent tasks to act upon the newly created plugin.xml
MG>in the old days we had mutexes and semaphores to allow one process the
ability to be placed on 'hold' until
MG>an all clear signal came from another process..so when a file is created
...processes will hold until file exists...NG>then allow any consequent
processes the ability to read the file
MG>thanks Benson
>
>
>
>
>
> >
> > 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]
>
