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>
Related
I use maven 3.8.5 in a web application with different layer. The parent pom is something similar to the follow:
<profiles>
<profile>
<id>dev</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<dependencies>
<dependency>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-core</artifactId>
<version>6.4.0</version>
</dependency>
</dependencies>
</profile>
<profile>
<id>other</id>
<activation>
<activeByDefault>false</activeByDefault>
</activation>
</profile>
</profiles>
Now if I manually change the activationByDefault of dev profile from true to false and activationByDefault of other profile from false to true when I build (mvn clean package) everything goes fine.
Instead If I perform a build command like follow to obtain the same result:
mvn clean package -P other
doesn't work.. and I still find flyway library in my project. What's wrong?
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 get the following after i pull the latest code from the githud repository.
problem encountered while building effective model for org.codehaus.mo
The full description of the error is below.
1 problem was encountered while building the effective model for
org.codehaus.mojo:aspectj-maven-plugin:1.8
[ERROR] 'dependencies.dependency.systemPath' for com.sun:tools:jar must specify an absolute path but is ${toolsjarSystemPath} #
I am using java1.8 and sts 3.6.4
Most likely JAVA_HOME environmental variable points to JDK instead of JRE. Change the environment variable and restart Eclipse.
aspectj-maven-plugin contains following:
<profile>
<id>standardToolsJar-profile</id>
<activation>
<activeByDefault>true</activeByDefault>
<file>
<exists>${java.home}/../lib/tools.jar</exists>
</file>
</activation>
<properties>
<toolsjarSystemPath>${java.home}/../lib/tools.jar</toolsjarSystemPath>
</properties>
</profile>
<profile>
<id>appleJdkToolsJar-profile</id>
<activation>
<activeByDefault>false</activeByDefault>
<file>
<exists>${java.home}/../Classes/classes.jar</exists>
</file>
</activation>
<properties>
<toolsjarSystemPath>${java.home}/../Classes/classes.jar</toolsjarSystemPath>
</properties>
</profile>
<profile>
<id>java8</id>
<activation>
<jdk>1.8</jdk>
</activation>
<properties>
<additionalparam>-Xdoclint:none</additionalparam>
</properties>
</profile>
I think the reason this fails is that activeByDefault will not trigger because java8 profile activation is triggered. file->exists condition will not trigger because of incorrect ${java.home}. ${toolsjarSystemPath} will not get set, and attempt to use it will cause the exception.
I'm new to maven and i got this issue when sometimes when i run maven i want to have a property with 1 value and sometimes the other.
I tried to do the following but still something is missing:
<profiles>
<profile>
<id>production</id>
<activation>
<property>
<name>com.sencha.cmd.dir</name>
<value>
${env.SENCHA_PATH}\senchaCmd-${com.sencha.cmd.version}\Sencha\Cmd\${com.sencha.cmd.version}
</value>
</property>
</activation>
</profile>
</profiles>
<properties>
<com.sencha.cmd.dir> ${env.SENCHA_PATH}\senchaCmd- ${com.sencha.cmd.version}\Sencha\Cmd\${com.sencha.cmd.version}</com.sencha.cmd.dir>
my question is how to replace the value of the property com.sencha.cmd.dir according to the availability of the profile?
Hope this is clear enough
It's really simple
<profiles>
<profile>
<id>profile 1</id>
<activation>
...
</activation>
<properties>
<my.property> xxx </my.property>
</properties>
</profile>
<profile>
<id>profile 2</id>
<activation>
...
</activation>
<properties>
<my.property> yyy </my.property>
</properties>
</profile>
</profiles>
and then you can use your my.properties outside, even in an other one properties
<properties>
<my.next.property> abc ${my.property} def </my.next.property>
</properties>
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.