On 18 juil. 2013, at 13:09, sebb <[email protected]> wrote: > 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?
Yeah, indeed. > 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. Yeah, that would also work and handle the test skipping quite well. Regards, Pierre-Arnaud > 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
