In addition to activating the profile, Maven has no logical logic. Therefore, if you want to cancel a property in order to pass it to the plugin, you need to do it yourself. This is a bit awkward, but you can use the build-helper-maven-plugin:bsh-property , which allows you to write a BeanShell script and the exported variables defined in it as Maven properties:
<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>build-helper-maven-plugin</artifactId> <version>1.12</version> <executions> <execution> <id>negate-prop</id> <phase>initialize</phase> <goals> <goal>bsh-property</goal> </goals> <configuration> <source>dontDoSomething = !${doSomething};</source> <properties> <property>dontDoSomething</property> </properties> </configuration> </execution> </executions> </plugin>
You cannot override a property, but you can define a new one containing the result of the negation; in the above example, this is dontDoSomething . This is done in the initialize phase, so other plugins can use it as a parameter with the standard ${dontDoSomething} .
This can be extended to have a default value for dontDoSomething if doSomething does not exist.
<source> value = project.getProperties().getProperty("doSomething"); dontDoSomething = value == null ? false : !Boolean.parseBoolean(value); </source>
BeanShell is a scripting language that is very similar to Java, and you can use existing Java methods. In the above example, the "doSomething" property is retrieved from the project properties (the project is introduced by the plugin during evaluation with the current Maven project); it is not defined, we return false , otherwise we deny the value.
If doSomething is, in particular, a system property, it is also possible (ab) to use the profile activation function and have 2 profiles: one is activated using the true property and sets the other value to false , and the second profile does the opposite:
<profiles> <profile> <id>pro-1</id> <activation> <property> <name>doSomething</name> <value>!false</value> </property> </activation> <properties> <dontDoSomething>false</dontDoSomething> </properties> </profile> <profile> <id>pro-2</id> <activation> <property> <name>doSomething</name> <value>false</value> </property> </activation> <properties> <dontDoSomething>true</dontDoSomething> </properties> </profile> </profiles>
This will not work if doSomething is a Maven property set in the <properties> , for example. It should be passed as a system property with mvn -DdoSomething=true|false . The corresponding profile will be activated in accordance with the value of the system property, which will determine the dontDoSomething property of its inverse. If the property is not defined, pro-1 will be active by setting dontDoSomething to the default value false . All this is pretty ugly though ...