On Thu, Apr 15, 2010 at 9:06 AM, Raphael Ackermann
<[email protected]> wrote:
> Thanks for the answer.
>
> How could I have found out from the existing documentation on [1]
>
Right, you couldn't, that's why I had to go look at the ReleaseManager
source code to verify. In general, the Release plugin is very
useful, but the documentation doesn't do it justice. I sense that
the frustration quotient* for the Release Plugin is very high.
*Frustration Quotient is defined by ("promise of plugin" * "necessity
of plugin") / ("amount of sane documentation")
> It says Attributes:
>
> Requires a Maven 2.0 project to be executed.
> Executes as an aggregator plugin.
>
> Does the "Executes as an aggregator plugin" means that it will only
> take the root project into account? If so, that should be made clearer
> as this doesn't mean much to me".
>
> googling I found many plugins with this "Executes as an aggregator
> plugin." attribute, but I couldn't find information on what it means.
> There is also no reference to an "aggregator plugin" in the
> maven-by-example or maven-complete-reference pdf books.
>
I'll file a JIRA for those two books... there "WTF is an aggregator
plugin?" -> https://issues.sonatype.org/browse/MVNREF-144
> [1] http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html
>
> Raphael
>
> On Thu, Apr 15, 2010 at 15:16, Tim O'Brien <[email protected]> wrote:
>> The DefaultReleaseManager is a part of the maven-release-manager, if
>> you look at the code in prepare(), you'll notice that it does not take
>> preparationGoals from anything other than the root project into
>> account. If you are looking at DefaultReleaseManager.java from the
>> 2.0 branch the relevant line numbers are 203 and 199.
>>
>> So the answer is no, you can't customize in a submodule. I'm sure,
>> with some effort you might be able to hack something into the
>> ReleasePhase logic, but there's no point. Just configure the root
>> project with "clean install".
>>
>> Tim
>>
>> On Thu, Apr 15, 2010 at 4:28 AM, Raphael Ackermann
>> <[email protected]> wrote:
>>> if I have a project structure like below:
>>>
>>> project-root
>>> + --- project-a
>>> + --- project-b
>>> + --- project-c
>>>
>>> and in project-root I have
>>>
>>> <plugin>
>>> <artifactId>maven-release-plugin</artifactId>
>>> </plugin>
>>>
>>> and in project-b I have
>>>
>>> <plugin>
>>> <artifactId>maven-release-plugin</artifactId>
>>> <configuration>
>>> <preparationGoals>clean install</preparationGoals>
>>> </configuration>
>>> </plugin>
>>>
>>> when I run mvn release:prepare (mvn 2.2.1) in the project-root directory
>>> I see
>>> [INFO] [INFO] Building project-b
>>> [INFO] [INFO] task-segment: [clean, verify]
>>>
>>> and the build fails because project-c needs an artifact that gets
>>> generated in project-b's install phase.
>>>
>>> If I change the setup and add the configuration of the clean install
>>> preparation goals into the parent pom project-root
>>>
>>> <plugin>
>>> <artifactId>maven-release-plugin</artifactId>
>>> <configuration>
>>> <preparationGoals>clean install</preparationGoals>
>>> </configuration>
>>> </plugin>
>>>
>>> I can see the following output:
>>>
>>> [INFO] [INFO] Building project-b
>>> [INFO] [INFO] task-segment: [clean, install]
>>>
>>> and the project builds successfully.
>>>
>>> I would like to only build one child module with clean install to save time.
>>>
>>> Does the release plugin ignore all configuration in child modules and
>>> only uses the configuration from the module where it is run from? Or
>>> do I need to add some other configuration?
>>>
>>> Raphael
>>>
>>> ---------------------------------------------------------------------
>>> 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]
