compile from source 2009/6/5 Tracy Hartford <[email protected]>
> This sounds promising, but I can't seem to locate it. I found the > snapshots repository for the versions plugin at > http://snapshots.repository.codehaus.org/org/codehaus/mojo/versions-mave > n-plugin/<http://snapshots.repository.codehaus.org/org/codehaus/mojo/versions-mave%0An-plugin/>, > but there are no beta snapshots listed. The codehaus mojo > page for the versions plugin does not mention set. > > Where can I take a look at versions:set? > > Thanks ~ Tracy > > -----Original Message----- > From: Stephen Connolly [mailto:[email protected]] > Sent: Wednesday, June 03, 2009 12:47 PM > To: Maven Users List > Cc: Maven Users List > Subject: Re: Does reactor spawn a subprocess for each submodule? > > have a look at versions:set in the latest 1.0-beta-1-SNAPSHOT > > Sent from my [rhymes with myPod] ;-) > > On 3 Jun 2009, at 18:51, "Tracy Hartford" <[email protected]> wrote: > > > 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] > > > > --------------------------------------------------------------------- > 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] > >
