I would like to have a Maven property that is set to a default unless -Dmy.prop is set.
So I went into my parent pom and added the property:
<properties>
<my.prop>ABC</my.prop>
</properties>
I ran mvn clean install -Dmy.prop=XYZ, hoping the XYZ would override the ABC but it did not.
You could use a profile to achieve that behaviour.
<profile>
<id>default-prop-a</id>
<activation>
<property>
<name>!prop.a</name>
</property>
</activation>
<properties>
<prop.a>VALUE</prop.a>
</properties>
</profile>
Related
I have the following profile below, instead of using activeByDefault I would like to active it through a property instead. I saw this comment (https://stackoverflow.com/a/18890159/1959534) in passing about being able to do so through maven assembly plugin but I couldn't figure out how to specify that. Any input on how to accomplish this?
<project ...>
...
<profiles>
<profile>
<id>myProfile</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<dependencies>
<dependency>
<!-- Extra dependency just for this profile -->
</dependency>
</dependencies>
</profile>
</profiles>
</project>
Figured it out!
Defined a system variable in the project's /.mvn/jvm.config and then changed the activation step to be through property instead of activeByDefault. Then used this tips to throw config out to my .properties file: https://stackoverflow.com/a/14386303/1959534
jvm.config
-Dmy.property=true
pom.xml
<profiles>
<profile>
...
<activation>
<property>
<name>my.property</name>
<value>true</value>
</property>
</activation>
</profile>
</profiles>
I would like to be able to use an environment variable if it's set or a default fallback value that I set in pom.xml similar to ${VARIABLE:-default} in bash. Is it possible? Something like:
${env.BUILD_NUMBER:0}
I wasn't really satisfied with the accepted approach, so I simplified it a little.
Basically set a default property in the normal properties block, and only override when appropriate (instead of an effective switch statement):
<properties>
<!-- Sane default -->
<buildNumber>0</buildNumber>
<!-- the other props you use -->
</properties>
<profiles>
<profile>
<id>ci</id>
<activation>
<property>
<name>env.buildNumber</name>
</property>
</activation>
<properties>
<!-- Override only if necessary -->
<buildNumber>${env.buildNumber}</buildNumber>
</properties>
</profile>
</profiles>
You could use profiles to achieve this:
<profiles>
<profile>
<id>buildnumber-defined</id>
<activation>
<property>
<name>env.BUILD_NUMBER</name>
</property>
</activation>
<properties>
<buildnumber>${env.BUILD_NUMBER}</buildnumber>
</properties>
</profile>
<profile>
<id>buildnumber-undefined</id>
<activation>
<property>
<name>!env.BUILD_NUMBER</name>
</property>
</activation>
<properties>
<buildnumber>0</buildnumber>
</properties>
</profile>
</profiles>
A bit more verbose than bash...
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 would like to create two sets of Sonar reports from the same project. One would have everything covered and the other one would have some packages excluded.
Is this possible and if so, how to do such?
Edit: Setting exclusions is not a problem but having two reports is.
Create new profile in maven and add call sonar with new branch for each profile: mvn clean install -Pprofile1 sonar:sonar -Dsonar.branch=BRANCH1
<properties>
<sonar.branch>
DEFAULT_BRANCH
</sonar.branch>
</properties>
<profiles>
<profile>
<id>sonar</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<sonar.host.url>
http://localhost:9000
</sonar.host.url>
</properties>
</profile>
<profile>
<id>profile1</id>
<properties>
<!-- Optional URL to server. Default value is http://localhost:9000 -->
<sonar.host.url>
http://myserver:9000
</sonar.host.url>
</properties>
</profile>
</profiles>
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.