You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Victor Nazarov (JIRA)" <ji...@apache.org> on 2015/05/08 17:25:01 UTC
[jira] [Comment Edited] (MNG-5408) Explicit profile activation in
pom.xml
[ https://issues.apache.org/jira/browse/MNG-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14534709#comment-14534709 ]
Victor Nazarov edited comment on MNG-5408 at 5/8/15 3:24 PM:
-------------------------------------------------------------
I think it would help a lot to have activateProfileselement in parent section, like this:
{code:title=pom.xml|borderStyle=solid}
<project>
<parent>
<artifactId>my-maven-parent</artifactId>
<activateProfiles>runJetty,!runTomcat</activateProfiles>
</parent>
</project>
{code}
Profile activation is performed from current pom up to root pom. So activateProfiles element should bubble up, by the same rules as command line profile activation is performed.
The difference from current implementation is that set of activeProfileIds will differ from child to parent during profile activation process.
In such a way shared parent pom can declare reusable profiles activated by child poms when needed. Additional dependency management between profiles can be usefull so, see [https://issues.apache.org/jira/browse/MNG-3309]
was (Author: sviperll):
I think it would help a lot to have activateProfileselement in parent section, like this:
{code:title=pom.xml|borderStyle=solid}
<project>
<parent>
<artifactId>my-maven-parent</artifactId>
<activateProfiles>runJetty,!runTomcat</activateProfiles>
</parent>
</project>
{code}
Profile activation is performed from current pom up to root pom. So activateProfiles element should bubble up, by the same rules as command line profile activation is performed.
It will difference from current implementation is that set of activeProfileIds will differ from child to parent during profile activation process.
In such a way shared parent pom can declare reusable profiles activated by child poms when needed. Additional dependency management between profiles can be usefull so, see [https://issues.apache.org/jira/browse/MNG-3309]
> Explicit profile activation in pom.xml
> --------------------------------------
>
> Key: MNG-5408
> URL: https://issues.apache.org/jira/browse/MNG-5408
> Project: Maven
> Issue Type: Improvement
> Components: Profiles
> Affects Versions: 3.0.4
> Reporter: Paul Lowry
>
> +Background:+
> Organisations should be able to define complex maven tasks, each involving multiple plugin executions, in a way that is standardised for use in all projects.
> The obvious solution would seem to be profiles:
> * They allow us to define maven project configuration and multiple plugin executions
> * They can be enabled/disabled, and they are not mutually exclusive, so we can use them to run execution A or execution B of the same plugin, or A and then B, or any other sequence (note: this sort of control is not available in pluginManagement)
> For example, consider an organisation where some project teams do integration testing of war artifacts by running them in Jetty, whereas others use Tomcat. Both scenarios require several plugins to run, and though the process is similar it is not the same (for our example, let's assume that Jetty requires a test context file, and Tomcat projects have a different naming scheme for their test classes).
> Using profiles in a root pom, which is the parent for all projects in the organisation, we can make the process for running a war in Jetty/Tomcat quite simple, and more importantly quite consistent:
> {code:xml|title=root.pom.xml}
> <project>
> <profiles>
> <!--
> profile for running integration tests using jetty
> -->
> <profile>
> <id>runJetty</id>
> <build>
> <plugins>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-resources-plugin</artifactId>
> <executions>
> <execution>
> <id>runJetty.prep</id>
> <phase>pre-integration-test</phase>
> <goals>
> <goal>copy-resources</goal>
> </goals>
> <configuration>
> <resources>
> <resource>
> <directory>\${project.build.testOutputDirectory}/jetty</directory>
> <filtering>true</filtering>
> </resource>
> </resources>
> <outputDirectory>\${project.build.directory}/\${project.build.finalName}</outputDirectory>
> </configuration>
> </execution>
> </executions>
> </plugin>
> <plugin>
> <groupId>org.mortbay.jetty</groupId>
> <artifactId>jetty-maven-plugin</artifactId>
> <executions>
> <execution>
> <id>runJetty.start</id>
> <phase>pre-integration-test</phase>
> <!-- start server in jetty, using property ${runJetty.port} -->
> </execution>
> <execution>
> <id>runJetty.stop</id>
> <phase>post-integration-test</phase>
> <!-- stop jetty -->
> </execution>
> </executions>
> </plugin>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-failsafe-plugin</artifactId>
> <executions>
> <execution>
> <id>runJetty.test</id>
> <phase>integration-test</phase>
> <goals>
> <goal>integration-test</goal>
> <goal>verify</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
> </plugins>
> </build>
> </profile>
> <!--
> profile for running integration tests using tomcat
> -->
> <profile>
> <id>runTomcat</id>
> <build>
> <plugins>
> <plugin>
> <groupId>org.apache.tomcat.maven</groupId>
> <artifactId>tomcat6-maven-plugin</artifactId>
> <executions>
> <execution>
> <id>runTomcat.start</id>
> <phase>pre-integration-test</phase>
> <!-- start server in tomcat, using property ${runTomcat.port} -->
> </execution>
> </executions>
> </plugin>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-failsafe-plugin</artifactId>
> <executions>
> <execution>
> <id>runTomcat.test</id>
> <phase>integration-test</phase>
> <goals>
> <goal>integration-test</goal>
> <goal>verify</goal>
> </goals>
> <configuration>
> <includes>
> <include>\${runTomcat.testPattern}</include>
> </includes>
> </configuration>
> </execution>
> </executions>
> </plugin>
> </plugins>
> </build>
> </profile>
> </profiles>
> </project>
> {code}
> A war project, with the above as its parent, can be configured to start its build artifact and run all integration tests, using Jetty or Tomcat as follows:
> {noformat:title=project tested using Jetty}
> <project>
> <properties>
> <runJetty.port>7070</runJetty.port>
> </properties>
> </project>
> {noformat}
> {noformat:title=the same project tested using Tomcat}
> <project>
> <properties>
> <runTomcat.port>7070</runTomcat.port>
> <runTomcat.testPattern>**/*AcceptanceTest.java</runTomcat.testPattern>
> </properties>
> </project>
> {noformat}
> Having defined these re-usable profiles, we then reach the question of how to activate them automatically in the organisation's various war projects (since the organisation's best practices demand that every build of a war project should run integration tests).
> Profiles can be activated by JDK version or OS, but these are not specific enough conditions. They can also be activated by command line properties, but these are too explicit - in this case we want our profile to run automatically. The only other activation condition is for a file to exist; but we cannot look in the target directory because profile activation is evaluated before the build starts; nor can we reliably depend on 'src/main/webapp', since different projects may arrange their sources differently, and some projects might want to disable the profile.
> +Problem:+
> So we hit a problem, namely: A project should be able to activate a profile explicitly; but the activation mechanisms provided out of the box are not refined enough.
> Several alternative ways have been suggested to activate profiles, such as packaging type (http://jira.codehaus.org/browse/MNG-4154), artifactId/groupId (http://jira.codehaus.org/browse/MNG-944), and pom properties. This last is probably the most widely mentioned, and was even used as the example for a custom profile activator feature, that was spiked in Maven 2.1 but never made it into the product. See these links for details...
> * http://maven.40175.n5.nabble.com/Activating-a-profile-in-settings-xml-based-on-a-property-set-in-pom-xml-tp512562p512598.html
> * http://maven.40175.n5.nabble.com/profile-activation-based-on-property-properties-in-POM-tp88010p88011.html
> * http://docs.codehaus.org/display/MAVEN/Custom+Profile+Activators
> If pom properties could activate profiles, it would certainly work nicely for the example above, in that developers could enable Jetty or Tomcat as follows:
> {code:xml|title=root.pom.xml}
> <project>
> <profiles>
> <profile>
> <id>runJetty</id>
> <activation>
> <property>
> <name>runJetty</name>
> <value>true</value>
> </property>
> </activation>
> ...
> </profile>
> <profile>
> <id>runTomcat</id>
> <activation>
> <property>
> <name>runTomcat</name>
> <value>true</value>
> </property>
> </activation>
> ...
> </profile>
> </profiles>
> </project>
> {code}
> {noformat:title=project tested using Jetty}
> <project>
> <properties>
> <runJetty>true</runJetty>
> <runJetty.port>7070</runJetty.port>
> </properties>
> </project>
> {noformat}
> {noformat:title=the same project tested using Tomcat}
> <project>
> <properties>
> <runTomcat>true</runTomcat>
> <runTomcat.port>7070</runTomcat.port>
> <runTomcat.testPattern>**/*AcceptanceTest.java</runTomcat.testPattern>
> </properties>
> </project>
> {noformat}
> However, none of these improvements (or similar) have ever been released.
> It seems to me like I'm missing something. Maybe the Maven developers/committers consider profiles an inappropriate way to configure builds like the example above; or maybe it's just too costly to activate profiles using info from the pom model.
> +Summary:+
> I'd like very much to understand why profiles cannot (or should not) be used in scenarios like the one described above.
> I'd also like to know if John Casey's custom profile activator might ever see the light of day, or if there is some alternative solution on the roadmap for Maven.
> Thanks & Regards
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)