You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Benson Margulies <bi...@gmail.com> on 2013/01/01 14:58:55 UTC
A subtlety with forked executions, looking for advice
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: A subtlety with forked executions, looking for advice
Posted by Martin Gainty <mg...@hotmail.com>.
> Date: Tue, 1 Jan 2013 20:04:22 -0500
> Subject: Re: A subtlety with forked executions, looking for advice
> From: bimargulies@gmail.com
> To: dev@maven.apache.org
>
> On Tue, Jan 1, 2013 at 7:43 PM, Martin Gainty <mg...@hotmail.com> 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: bimargulies@gmail.com
> >> To: dev@maven.apache.org
> >>
> >> On Tue, Jan 1, 2013 at 12:15 PM, Martin Gainty <mg...@hotmail.com> 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: bimargulies@gmail.com
> >> >> To: dev@maven.apache.org
> >> >>
> >> >> On Tue, Jan 1, 2013 at 10:15 AM, Stephen Connolly
> >> >> <st...@gmail.com> 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 <bi...@gmail.com> 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 <bi...@gmail.com>
> >> >> >> 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: dev-unsubscribe@maven.apache.org
> >> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >> >>
> >> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Re: A subtlety with forked executions, looking for advice
Posted by Benson Margulies <bi...@gmail.com>.
On Tue, Jan 1, 2013 at 7:43 PM, Martin Gainty <mg...@hotmail.com> 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: bimargulies@gmail.com
>> To: dev@maven.apache.org
>>
>> On Tue, Jan 1, 2013 at 12:15 PM, Martin Gainty <mg...@hotmail.com> 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: bimargulies@gmail.com
>> >> To: dev@maven.apache.org
>> >>
>> >> On Tue, Jan 1, 2013 at 10:15 AM, Stephen Connolly
>> >> <st...@gmail.com> 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 <bi...@gmail.com> 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 <bi...@gmail.com>
>> >> >> 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: dev-unsubscribe@maven.apache.org
>> >> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >> >>
>> >> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: A subtlety with forked executions, looking for advice
Posted by Martin Gainty <mg...@hotmail.com>.
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: bimargulies@gmail.com
> To: dev@maven.apache.org
>
> On Tue, Jan 1, 2013 at 12:15 PM, Martin Gainty <mg...@hotmail.com> 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: bimargulies@gmail.com
> >> To: dev@maven.apache.org
> >>
> >> On Tue, Jan 1, 2013 at 10:15 AM, Stephen Connolly
> >> <st...@gmail.com> 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 <bi...@gmail.com> 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 <bi...@gmail.com>
> >> >> 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: dev-unsubscribe@maven.apache.org
> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Re: A subtlety with forked executions, looking for advice
Posted by Benson Margulies <bi...@gmail.com>.
On Tue, Jan 1, 2013 at 12:15 PM, Martin Gainty <mg...@hotmail.com> 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: bimargulies@gmail.com
>> To: dev@maven.apache.org
>>
>> On Tue, Jan 1, 2013 at 10:15 AM, Stephen Connolly
>> <st...@gmail.com> 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 <bi...@gmail.com> 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 <bi...@gmail.com>
>> >> 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: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: A subtlety with forked executions, looking for advice
Posted by Martin Gainty <mg...@hotmail.com>.
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
______________________________________________
..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: bimargulies@gmail.com
> To: dev@maven.apache.org
>
> On Tue, Jan 1, 2013 at 10:15 AM, Stephen Connolly
> <st...@gmail.com> 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 <bi...@gmail.com> 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 <bi...@gmail.com>
> >> 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: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Re: A subtlety with forked executions, looking for advice
Posted by Benson Margulies <bi...@gmail.com>.
On Tue, Jan 1, 2013 at 10:15 AM, Stephen Connolly
<st...@gmail.com> 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 <bi...@gmail.com> 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 <bi...@gmail.com>
>> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: A subtlety with forked executions, looking for advice
Posted by Stephen Connolly <st...@gmail.com>.
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 <bi...@gmail.com> 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 <bi...@gmail.com>
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
RE: A subtlety with forked executions, looking for advice
Posted by Martin Gainty <mg...@hotmail.com>.
ive had nothing but headaches with forked executions..specifically maven-surefire-plugin
If I shut off fork in the <configuration> <forkMode>false<forkMode>everything works
i'm not sure if this aberrant behaviour can be reproduced with other goal bindings in other plugins but reading past blog entries
from Tran ..forked executions seem to always cause problems http://maven.40175.n5.nabble.com/jira-Created-MSUREFIRE-121-ability-to-add-dependency-to-jvm-s-classpath-rather-in-surefirebooter-clar-td191678.html WDYT?
Martin
______________________________________________
Place long-winded disclaimer here
> Date: Tue, 1 Jan 2013 10:01:39 -0500
> Subject: Re: A subtlety with forked executions, looking for advice
> From: bimargulies@gmail.com
> To: dev@maven.apache.org
>
> 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 <bi...@gmail.com> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Re: A subtlety with forked executions, looking for advice
Posted by Benson Margulies <bi...@gmail.com>.
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 <bi...@gmail.com> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org