I have two Maven profiles profile-A and profile-B. "B" should only be activated if "A" is not activated.
So if I would call
mvn install
profile-B is executed (but not profile-A).
But if I would call
mvn install -Pprofile-A
then only profile-A is executed (but not profile-B).
Any hints how I need to write my pom.xml to achieve this?
I already tried this, but it doesn't work:
<profiles>
<profile>
<id>profile-A</id>
<activation>
<activeByDefault>false</activeByDefault>
</activation>
...
</profile>
<profile>
<id>profile-B</id>
<activation>
<activeByDefault>true</activeByDefault>
<property>
<name>!profile-A</name>
</property>
...
</activation>
...
</profile>
</profiles>
I think for your example command line to work as expected, all you need is the <activeByDefault>true</activeByDefault> for profile B.
http://maven.apache.org/guides/introduction/introduction-to-profiles.html states:
All profiles that are active by default are automatically deactivated when a profile in the POM is activated on the command line or through its activation config.
Related
I have the following parent pom.xml file:
<profile>
<id>build_full</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<modules>
<module>mymodule_interface</module>
<module>mymodule_switch</module>
<module>mymodule_switch_simulator</module>
<module>mymodule_switch_controller</module>
<module>mymodule_server</module>
</modules>
</profile>
and in my child pom for mymodule_server, I have the following:
<profile>
<id>subprofile</id>
<modules>
<module>...various modules...</module>
</modules>
</profile>
<profile>
<id>default</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<modules>
<module>...various modules...</module>
</modules>
</profile>
How, when I invoke maven: mvn -P build_full, can I force the child module (mymodule_server) to use profile subprofile rather than default?
No, you can't activate a child profile from a parent profile. More generally, you can't activate or deactivate any profile from any other profile (there is a JIRA feature-request MNG-3309). What you can do is activate two profiles based on the same property.
First of all, using a profile that is activated by default is generally not a good idea. What you want is to activate a profile based on some condition (OS version, system property...). To solve your problem, you can activate build_full profile when a certain system property is present, and make sure that subprofile is also activated when that same property is present.
A sample configuration would be the following, where both profiles are activated when the fullBuild system property is set to true. Invoking Maven with mvn -DfullBuild=true ... will thus activate both profiles.
<profile>
<id>build_full</id>
<activation>
<property>
<name>fullBuild</name>
<value>true</value>
</property>
</activation>
<modules>
<module>mymodule_interface</module>
<module>mymodule_switch</module>
<module>mymodule_switch_simulator</module>
<module>mymodule_switch_controller</module>
<module>mymodule_server</module>
</modules>
</profile>
<profile>
<id>subprofile</id>
<activation>
<property>
<name>fullBuild</name>
<value>true</value>
</property>
</activation>
<modules>
<module>...various modules...</module>
</modules>
</profile>
In your case, from the top parent/aggregator folder, you could just run:
mvn clean install -Pbuild_full,!default,subprofile
It will disable any profile having name default (and hence disable the profile in the concerned sub-module) and enable any profile having name subprofile (and hence enable the profile you wanted).
Alternatively, you could configure subprofile as such:
<profiles>
<profile>
<id>subprofile</id>
<activation>
<property>
<name>subprofile</name>
<value>true</value>
</property>
</activation>
....
and then run as following:
mvn clean install -Dsubprofile=true -Pbuild_full
It will have the same effect. You can even avoid the value element and simply specify -Dsubprofile, its existence would be enough to activate the profile (in that case a more meaningful name is suggested, like -DactivateSubprofile). Since you active a different profile, automatically Maven will deactivate the default one.
I'm completely new to Maven. I'm trying to set up a new project such that it doesn't require 20 page long word docs with screenshots to set it up. I've got developers on Macs and PCs, so I need to be able to customize the catalina.home directory as I can't just impose a standard location. I thought I'd do it in the ~/.m2/settings.xml file with the following:
<profile>
<id>my-site-dev</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<catalina.home>/path/to/apache-tomcat</catalina.home>
</properties>
</profile>
However, the documentation here: http://maven.apache.org/guides/introduction/introduction-to-profiles.html#Profile_Pitfalls seems to indicate that what I'm trying to accomplish is a bad idea. What's the official way of accomplishing this so that in my pom.xml I can just reference ${catalina.home}?
And now that I've declared my profile with an id, can I fail the build if my pom.xml can't load the profile "my-site-dev"? I'd like to get that <activeByDefault> out of the settings.xml if at all possible. I don't want to interfere with their global settings for no reason, I'd like to keep as much of it self contained as possible.
Don't use activeByDefault, since it will cloak all other profiles:
Here is what you should use:
<profiles>
<profile>
<id>path-to-catalina.home-linux</id>
<activation>
<os>
<family>linux</family>
</os>
</activation>
<properties>
<catalina.home>...</catalina.home>
</properties>
</profile>
<profile>
<id>path-to-catalina.home-mac</id>
<activation>
<os>
<family>mac</family>
</os>
</activation>
<properties>
<catalina.home>...</catalina.home>
</properties>
</profile>
<profile>
<id>path-to-catalina.home-windows</id>
<activation>
<os>
<family>windows</family>
</os>
</activation>
<properties>
<catalina.home>...</catalina.home>
</properties>
</profile>
You could use a profile in your pom that gets activated based on os.
<profiles>
<profile>
<activation>
<os>
...
What are you doing that require catalina.home?
If you're doing deployment to an app server with maven, you are already outside of the 'consistent, portable build' rule set - and outside of the main use case / best practices for maven.
Not that you shouldn't do it - as it's convenient. Just make sure to separate your build projects from the deployment projects.
I currently have a pom with platform specific profiles (e.g. linux 32bit, windows 64 bit, etc...). Additionally, I have set it up to automatically choose the invoker's platform as a default.
Now, assume I am in a linux 32 machine: I also want to build for win64 by invoking mvn -Pwin64 pakage but in doing so, both the linux32 and win64 profiles get activated. I have tried activating the local platform profile with activeProfiles and using ativation tags. The trouble is that -P does not disable all other profiles as explained in the documentation:
This option takes an argument that is a comma-delimited list of
profile-ids to use. When this option is specified, no profiles other
than those specified in the option argument will be activated.
Am I understanding this wrong? How would you handle this?
Note: I know I could run mvn -P-linux32,win64 but that is only valid on linux32 platforms, and any mistakes may result in a bloated build with duplicate classes.
Thanks!
This statement from the profile docs:
As of Maven 3.0, profiles in the POM can also be activated based on properties from active profiles from the settings.xml.
Would lead me to try the solution below. Each developer defines his default platform as a property in his settings.xml file and overrides it on the cmdline if needed.
Developer's settings.xml
<profile>
<id>platform-config</id>
<property>
<name>build.platform</name>
<value>win32</value>
</property>
</profile>
....
<activeProfiles>
<activeProfile>platform-config</activeProfile>
</activeProfiles>
Project's pom.xml
<project>
...
<profiles>
<profile>
<id>win32</id>
<activation>
<property>
<name>build.platform</name>
<value>win32</value>
</property>
</activation>
...
</profile>
<profile>
<id>linux32</id>
<activation>
<property>
<name>build.platform</name>
<value>linux32</value>
</property>
</activation>
...
</profile>
</profiles>
Then, mvn install should activate the win32 profile because the default value for the build.platform property is win32, while mvn install -Dbuild.platform=linux32 will override the default property setting and use the Linux profile instead.
Why don't you use the profile activation by plattform like this:
<project>
...
<profiles>
<profile>
<id>win32</id>
<activation>
<activeByDefault>false</activeByDefault>
<os>
<name>Windows XP</name>
<family>Windows</family>
<arch>x86</arch>
<version>5.1.2600</version>
</os>
</activation>
...
</profile>
</profiles>
</project>
I have a need to detect if a user is using mvn2 or mvn3 in my parent pom in order to load the proper plugin version. I followed the recommendation from here : http://maven.apache.org/plugins/maven-site-plugin/maven-3.html#Using_maven-site-plugin_2.x_with_Maven_2_and_maven-site-plugin_3.x_with_Maven_3
The detection mechanism works great - however, my other profiles that are activatedByDefaul do not get picked up anymore.
Super pom look like below:
<profile>
<id>profile-1</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
</profile>
<profile>
<id>profile-2</id>
<activation>
<activeByDefault>false</activeByDefault>
</activation>
</profile>
<profile>
<id>maven-3</id>
<activation>
<file>
<!-- This employs that the basedir expression is only recognized by Maven 3.x (see MNG-2363) -->
<exists>${basedir}</exists>
</file>
</activation>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>com.company.plugins</groupId>
<artifactId>my-super-plugin</artifactId>
<version>1.0-123</version>
</plugin>
</plugins>
</pluginManagement>
</build>
</profile>
</profiles>
when I run mvn help:active-profiles with mvn3 --> only maven-3 profile get listed. If I use mvn2, profile-1 is rightfully listed.
*Edit * : as it turns out, its actually well documented here : http://maven.apache.org/guides/introduction/introduction-to-profiles.html
This profile will automatically be active for all builds unless another profile in the same POM is activated using one of the previously described methods. All profiles that are active by default are automatically deactivated when a profile in the POM is activated on the command line or through its activation config.
My question is now then : what work around would you recommend to have profile1 activated by default and profile 2 activated if -P profile2, while maven-3 profile activated if maven3 is used?
So far I haven't found anything better than just:
<activation>
<property>
<name>!dummy</name>
</property>
</activation>
where dummy is some kind of stupid variable name that you won't use for sure.
I have a configurable property line.ending that I used during the assembly phase of the building of my project to specify the line ending type of my application property files. For that I have created two profiles LF_DOS and LF_UNIX, so that when I launch :
mvn install
or
mvn install -P LF_DOS
line.ending equals 'dos', and when I launch :
mvn install -P LF_UNIX
line.ending equals 'unix'.
My first attempt to do this was simply :
<profile>
<id>LF_UNIX</id>
<activation>
<activeByDefault>false</activeByDefault>
</activation>
<properties>
<line.ending>unix</line.ending>
</properties>
</profile>
<profile>
<id>LF_DOS</id>
<activation>
<property>
<name>!line.ending</name>
</property>
</activation>
<properties>
<line.ending>dos</line.ending>
</properties>
</profile>
Unfortunately, this always gave me line.ending=dos, whatever LF_UNIX is set or not. Weird... But, the more confusing to me, is that I solved the problem just by changing the profile declaration order, like this :
<profile>
<id>LF_DOS</id>
<activation>
<property>
<name>!line.ending</name>
</property>
</activation>
<properties>
<line.ending>dos</line.ending>
</properties>
</profile>
<profile>
<id>LF_UNIX</id>
<activation>
<activeByDefault>false</activeByDefault>
</activation>
<properties>
<line.ending>unix</line.ending>
</properties>
</profile>
This works exactly like I want.
My questions is : is this a bug ? Or is it something to know about maven profiles, a kind of limitation that makes profiles order declaration particularly matter in such a case ?
The confusion lies in your understanding of how profile activation works.
You think that this:
<activation>
<property>
<name>!line.ending</name>
</property>
</activation>
means if I don't have a maven property named "line.ending" set, activate this profile. What it really means if I didn't specify -Dline.ending=X on the command line, activate this profile. So unless you run something like this:
mvn clean install -Dline.ending=unix
You are activating this profile and thus having the value set to dos.