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/, 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]

Reply via email to