24

I want to exclude a direct dependency of a Maven plugin and the approach described in this answer does not work (as indicated by this comment).

As a particular example:

<build>
    <plugins>
        <plugin>
            <groupId>org.jvnet.jaxb2.maven2</groupId>
            <artifactId>maven-jaxb2-plugin</artifactId>
            <version>0.13.2</version>
            <!-- more config -->
            <dependencies>
                <dependency>
                    <groupId>org.jvnet.jaxb2.maven2</groupId>
                    <artifactId>maven-jaxb2-plugin</artifactId>
                    <version>0.13.2</version>
                    <exclusions>
                        <exclusion>
                            <groupId>javax.xml.bind</groupId>
                            <artifactId>jaxb-api</artifactId>
                        </exclusion>
                    </exclusions>
                </dependency>
            </dependencies>
        </plugin>
    </plugins>
</build>

I still see javax.xml.bind:jaxb-api in the list of dependencies (with mvn ... -X). What am I doing wrong?

(In case someone has an idea for how to replace the dependency on that artifact with the JDK 9 equivalent for that API [as seems to happen on Java 8, where "JAXB API os loaded from the [jar:...jre/lib/rt.jar]"], I'm happy to open a new issue for that.)

Update

Running out of ideas and this being an experiment anyways, I excluded the dependency by editing the plugin's pom.xml in my local repository. Now mvn ... -X shows that there is also an indirect dependency (in this case by org.jvnet.jaxb2.maven2:maven-jaxb22-plugin) that I can successfully exclude with the mechanism above. Just using both excludes, from maven-jaxb2-plugin and maven-jaxb22-plugin, does not do the trick. This indicates that exclusion works in general but apparently not on a plugin's direct dependency.

(By the way, this indeed lead to "Java JAXB API is loaded from the [jrt:/java.xml.bind]", which was my goal.)

Community
  • 1
  • 1
Nicolai Parlog
  • 47,972
  • 24
  • 125
  • 255
  • Maybe `javax.xml.bind:jaxb-api` is included somehow else? As a dependency of your project or of another dependency? – Uwe Allner Apr 26 '17 at 09:34
  • I updated the question to address your comment. – Nicolai Parlog Apr 26 '17 at 10:11
  • Maybe better answer the question yourself: excluding a plugin's direct dependency does not seem possible with current Maven versions. – Boris Terzic Apr 26 '17 at 13:01
  • Up until now there hasn't been any reason to do this, but this seems like a valid one. Most clean solution I can think of is allowing to override the scope with "none" for plugin dependencies. – Robert Scholte Apr 26 '17 at 20:17
  • @RobertScholte Would you consider turning your comment into an answer, preferably with a link to where the docs explain this (if they do, I didn't see it) or maybe even an issue addressed at remedying the situation? – Nicolai Parlog Apr 27 '17 at 06:41

3 Answers3

12

Up until now there hasn't been any reason to do this, but this seems like a valid one. Most clean solution I can think of is allowing to override the scope with "none" for plugin dependencies.

I've created MNG-6222 for it, not sure if we'll fix this for a Maven3, but it makes sense to do it at least for the next major.

Robert Scholte
  • 11,889
  • 2
  • 35
  • 44
  • Another valid reason: the build-helper plugin depends (directly) on bsh-2.04b (groupId: org.beanshell). bsh versions before 2.06b have a remote execution vulnerability ( https://nvd.nist.gov/vuln/detail/CVE-2016-2510 ), so it is necessary to eliminate the older bsh. However, the newer version has a new groupId (org.apache-extras.beanshell), so it is not enough to declare org.apache-extras.beanshell:bsh:2.06b as dependency, org.beanshell:bsh must be excluded, which is (still) not possible with the current maven (3.6.2). – uk4sx Nov 26 '19 at 05:32
2

I had a similar situation with maven-linkcheck-plugin in the end I did a more brute force approach to remove the doxia-linkcheck dependency and make it use my fork by forking maven-linkcheck-plugin and creating my own with the proper dependencies.

Archimedes Trajano
  • 35,625
  • 19
  • 175
  • 265
-1

Check your dependency list with dependency:tree and solve whichever lib is introducing that lib dependency, then exclude it. Maybe your dependency couldn't be a direct one.

Just follow your dependency hierarchy

Dharman
  • 30,962
  • 25
  • 85
  • 135
Israel Romero
  • 15
  • 4
  • 7
    The dependency is not introduced by a lib but by the plugin and I know where it comes from - my question is why the exclusion mechanism doesn't work. – Nicolai Parlog Apr 26 '17 at 10:13