I have a maven module which has some dependencies. In a certain profile, I want to exclude some of those dependencies (to be exact, all dependencies with a certain group id). They however need to be present in all other profiles. Is there a way to specify exclusions from the dependencies for a profile?
-
Can you tell us a bit more about your use case? If your module has dependencies, why do you need to exclude them? – Pascal Thivent Nov 24 '09 at 13:36
-
The module is part of an eclipse RCP application. It depends on other modules of the application as well as lots of RCP bundles. I want to use this profile to create the eclipse target platform. This needs to include all dependencies, except for those that are part of the application. Currently this is done by editing the POM, removing all dependencies that are part of the application itself, running mvn eclipse:installbundles and then editing the POM again. This is obviously very error prone. – Thomas Lötzer Nov 24 '09 at 13:46
6 Answers
To my knowledge, no, you can't deactivate dependencies (you can exclude transitive dependencies but this is not what you are asking for) and yes, what you are currently doing with the POM (manually editing it) is wrong.
So, instead of removing dependencies, you should put them in a profile and either:
- Option #1: use the profile when required or
- Option #2: mark the profile as activated by default or put it in the list of active profiles and deactivate it when required.
A third option would be (not profile based):
- Option #3: separate things in two separated modules (as you have separated concerns) and use inheritance.

- 562,542
- 136
- 1,062
- 1,124
-
The problem with that approach is that I need the dependencies to be there pretty much all the time. I need to create the target platform maybe once every 3 months. So having to specify a profile on every build is much more of a hassle than editing the POM by hand. Profiles marked active by default unfortunately get deactivated when another profile is activated, so that won't help me either as there very often is another profile active. – Thomas Lötzer Nov 24 '09 at 14:08
-
I won't argue about profiles and how you are using them, I'm just giving you possible solutions. But no, you can't deactivate dependencies (you can only exclude transitive dependencies). If you don't want them, create another module. – Pascal Thivent Nov 24 '09 at 14:27
-
I think this is a great answer and can't see why you can't use the Option #2 method. Simply put the said dependency in the default profile and create another profile which has no dependencies and activate it (deactivating the default one) when you want to build in the case you describe. – Brett Ryan Mar 08 '11 at 20:17
Instead of excluding dependencies in a profile, you can set them as provided
in it. This doesn't require any overly complex configuration and will exclude the dependencies you don't want from the final build.
In the desired profile, add a dependencies
section, copy the declaration of the ones you want to exclude and scope them as provided
.
For example, let say you want to exclude slf4j-log4j12
:
<profiles>
<!-- Other profiles -->
<profile>
<id>no-slf4j-log4j12</id>
<dependencies>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.2</version>
<scope>provided</scope>
</dependency>
</dependencies>
</profile>
<!-- Other profiles -->
</profiles>

- 3,646
- 27
- 28
One way that occurs to me is to have the dependencies in a separate pom. You can then add an <exclusions>
section via the profile.
<dependencies>
<dependency>
<groupId>my.company.dependencies</groupId>
<artifactId>my-dependencies</artifactId>
<version>1.0.0-SNAPSHOT</version>
<type>pom</type>
</dependency>
</dependencies>
<profile>
<activation>
<activeByDefault>false</activeByDefault>
<property>
<name>exclude-deps</name>
</property>
</activation>
<dependencies>
<dependency>
<groupId>my.company.dependencies</groupId>
<artifactId>my-dependencies</artifactId>
<version>1.0.0-SNAPSHOT</version>
<type>pom</type>
<exclusions>
<exclusion>
<groupId>my.company</groupId>
<artifactId>bad-dep-1</artifactId>
</exclusion>
<exclusion>
<groupId>my.company</groupId>
<artifactId>bad-dep-2</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
</profile>

- 6,231
- 4
- 25
- 23
I don't think it is possible to exclude direct dependencies either (at least, nothing is mentioned here).
The best thing you can do is to enclose the desired dependencies for each case into different profiles (as suggested already), but, you'll need to create two "mutually exclusive" profiles with the one of them "active by default". The most reliable way to achieve this is by using a parameter for your profile activation e.g.
<profiles>
<profile>
<id>default-profile</id>
<activation>
<property><name>!exclude</name></property>
</activation>
<dependencies>
dependency-A
dependency-B
...
</dependencies>
</profile>
<profile>
<id>exclude-profile</id>
<activation>
<property><name>exclude</name></property>
</activation>
<!-- exclude/replace dependencies here -->
</profile>
</profiles>
Then using "mvn [goal]" will use profile "default-profile", but "mvn [goal] -Dexclude" will use profile "exclude-profile".
Note that using 'activeByDefault' instead of a parameter for your "default" profile might work in some cases but it also might lead to unexpected behavior. The problem is that 'activeByDefault' makes a profile active as long as there is no other active profile in any other module of a multi-module build.

- 2,031
- 1
- 18
- 15
maven is a tool, we can hack it.
- maven runs fine if you have the same artifact + version defined as dependency twice.
- define a profile that eliminates an artifact + version by changing it to another package we already have.
For example, in the pom.xml:
... other pom stuff ...
<properties>
<artifact1>artifact1</artifact1>
<artifact2>artifact2</artifact2>
<artifact1.version>0.4</artifact1.version>
<artifact2.version>0.5</artifact2.version>
</properties>
<profile>
<id>remove-artifact2</id>
<properties>
<artifact1>artifact1</artifact1>
<artifact2>artifact1</artifact2>
<artifact1.version>0.4</artifact1.version>
<artifact2.version>0.4</artifact2.version>
</properties>
</profile>
- Now if you install this pom.xml without the profile,
artifact1:0.4
andartifact2:0.5
will be the dependency. - But if you install this pom.xml with the profile
mvn -P remove-artifact2
The result pom.xml contains onlyartifact1:0.4
This comes quite handy during api migration where artifact are renamed and versions are not compatible.

- 21
- 2
Bit dirty but lightweight solution is to use <scope>import</scope>
.
Unlike the other scopes you could use this:
- will disable compile-time and runtime dependecies; unlike
provided
orruntime
which disables only one at a time - won't mess up your
test
scope - you don't need to specify path to some dummy jar as would
system
scope require
Nothing gets imported as long as you use this hack outside dependencyManagement
.

- 2,799
- 27
- 29