I explained the overall goal, in case there are alternative ways to get
there that might be preferable to a forked execution. However, I can
also explain why we are exploring a forked execution at this point.
We are currently setting the version like this:
<version>${env.MY_BUILD_VARIABLE}</version>.
Prior to building, we call a script that sets up the build environment,
including assigning a value to MY_BUILD_VARIABLE, which gets its value
from the top Perforce changenum. Because this variable is set once, the
version of every POM in the multi-module system is set to this value.
This does not allow us to distinguish whether a given module has had any
changes (and thus needs to be rebuilt), so it results in a complete
rebuild of the system. We are trying to make the build system more
agile, such that we can skip building modules that have not had any
changes since the last build.
So, the sub-problem is how to assign a module-specific version to the
POM via an environment variable? We are considering two approaches. The
first is to create a unique environment variable for each submodule, set
it prior to beginning the build, and set the POM version to pull from
its specific environment variable. The second is to set one variable,
but reassign its value prior to executing each submodule. This requires
forked execution.
We would prefer to use Maven to get the correct version. We have failed
to identify a way to do so. One reason is that only text or variables
are accepted inside a <version/>, not commands. Another reason is that
you can't dynamically set the version because the values of POM
properties are solidified prior to any plugins running, though it is not
clear exactly when and how the solidification happens (Parsing?
Validation phase?). If not for the properties solidifying, we could use
a plugin to gather the version number, such as antrun. We can't use
SCM:perforce or release to set the version, because the perforce
implementation is buggy. Therefore, unless we want to manually hardcode
every POM (which we don't), we concluded that we need to pull it from an
environment variable.
With forking, we would be able to update the value of the variable in a
new process, and the goal would be invoked on the POM in the new
process.
-----Original Message-----
From: Stephen Connolly [mailto:[email protected]]
Sent: Tuesday, June 02, 2009 10:45 PM
To: Maven Users List
Subject: Re: Does reactor spawn a subprocess for each submodule?
We are all still wondering _why_ you feel you need to do this forking?
2009/6/3 Tracy Hartford <[email protected]>
> I have spent some time looking into the invoker plugin, and according
to
> the specs, it is primarily used for integration testing.
>
> My original question was whether it was possible, when invoking a
maven
> goal on a parent POM, to force the reactor to spawn a new process for
> each of the submodule executions of that goal. How can I use the
invoker
> to force the executions to fork?
>
> Assuming the invoker could be used to cause forked execution of the
goal
> on the subprocesses, if I were to use a <preBuildHookScript>, would
the
> execution of the script occur in the same process as the goal
> invocation, or would it be executed in its own process, then return to
> the parent process to proceed with the goal execution?
>
> Thanks ~ Tracy
>
> -----Original Message-----
> From: Brian Fox [mailto:[email protected]]
> Sent: Sunday, May 24, 2009 5:51 AM
> To: Maven Users List
> Subject: Re: Does reactor spawn a subprocess for each submodule?
>
> It runs inside the same process. You can use the invoker to fork a
maven
> process, but this is not usually done as you describe. Why do you want
> to
> fork a new process for each module?
>
> On Fri, May 22, 2009 at 6:43 PM, Tracy Hartford <[email protected]>
> wrote:
>
> > I am working on a large multi-module project, and I need to know how
> the
> > reactor works when I invoke a maven goal on the parent POM. I know
> that
> > Maven adds all the submodule POMs into the Reactor, which analyzes
the
> > dependencies between them, and determines the build order. I
> understand
> > that the Reactor then "effectively executes" the goal for each
> > submodule. What I need to know is, when the Reactor executes the
goal
> > for a given submodule, does it spawn a child process to do so, or
does
> > it execute in the current process? If it execute in the current
> process,
> > is there a way to force it to spawn a new process first?
> >
> >
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> 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]
