[
https://jira.codehaus.org/browse/MNG-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=339919#comment-339919
]
Jason van Zyl commented on MNG-5408:
------------------------------------
I think a better idea here would be mixins:
https://jira.codehaus.org/browse/MNG-5437
> Explicit profile activation in pom.xml
> --------------------------------------
>
> Key: MNG-5408
> URL: https://jira.codehaus.org/browse/MNG-5408
> Project: Maven 2 & 3
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
