On 18 July 2013 08:49, Pierre-Arnaud Marcelot <[email protected]> wrote:
>
> On 18 juil. 2013, at 01:12, sebb <[email protected]> wrote:
>
>> On 18 July 2013 00:10, Emmanuel Lécharny <[email protected]> wrote:
>>> Le 7/18/13 12:42 AM, sebb a écrit :
>>>> On 17 July 2013 23:21, Jeff MAURY <[email protected]> wrote:
>>>>> Build also except if the benchmarks profile is activated: build fails
>>>>> because it seems the benchmarks pom is still on 3.0.0-M1-SNAPSHOT
>>>> Both of these files still refer to the SNAPSHOT release:
>>>>
>>>> benchmarks/pom.xml
>>>> benchmarks2/pom.xml
>>>>
>>>> Looks like the release plugin did not work properly, or the poms are
>>>> not configured correctly.
>>>
>>> No, as I said, this is my mistake : those poms are belonging to modules
>>> taht are activated by a profile, and I forgot to use it.
>>
>> Is it possible to auto-activate it when using the release plugin?
>
> Apache's root 'apache' pom.xml enforces that the "apache-release" profile is 
> appended to the command line used when performing the release tasks of the 
> "release" plugin, see [1].
>> <!--  START SNIPPET: release-plugin-configuration  -->
>> <plugin>
>>     <groupId>org.apache.maven.plugins</groupId>
>>     <artifactId>maven-release-plugin</artifactId>
>>     <version>2.3.2</version>
>>     <configuration>
>>         <useReleaseProfile>false</useReleaseProfile>
>>         <goals>deploy</goals>
>>         <arguments>-Papache-release ${arguments}</arguments>
>>     </configuration>
>> </plugin>
>> <!--  END SNIPPET: release-plugin-configuration  -->
>
>
> So using the same profile id and making sure to add the required modules 
> would help to auto-activate them "automatically" when doing a release:
>> <profile>
>>     <id>apache-release </id>
>>     <modules>
>>         <module>benchmarks</module>
>>         <module>benchmarks2</module>
>>     </modules>
>> </profile>
>
> My 2 cents,

However, won't that run the benchmark tests?

It occurs to me that what's needed is to always include the modules in
the top-level pom so they don't get ignored when creating source or
amending versions.

So I would drop the profiles from the parent pom, and add them to the
relevant module poms.

Testing can then be disabled unless the appropriate profile is enabled.
e.g. define a local property, default true, which is used to skip tests.
If the profile is defined, set the property to false.
There may be other ways to achieve this within each module.

> Pierre-Arnaud
>
> [1] - 
> http://search.maven.org/remotecontent?filepath=org/apache/apache/13/apache-13.pom

Reply via email to