maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Victor Nazarov (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MNG-5408) Explicit profile activation in pom.xml
Date Fri, 08 May 2015 15:25:01 GMT

    [ https://issues.apache.org/jira/browse/MNG-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14534709#comment-14534709
] 

Victor Nazarov commented on MNG-5408:
-------------------------------------

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)

Mime
View raw message