Is there anyway to exclude artifacts inherited from a parent POM

Question

Artifacts from dependencies can be excluded by declaring an  lt exclusions gt  element inside a  lt dependency gt  But in this case it s needed to exclude an artifact inherited from a parent project  An excerpt of the POM under discussion follows    lt project gt     lt modelVersion gt 4 0 0 lt  modelVersion gt     lt groupId gt test lt  groupId gt     lt artifactId gt jruby lt  artifactId gt       lt version gt 0 0 1-SNAPSHOT lt  version gt       lt parent gt           lt artifactId gt base lt  artifactId gt           lt groupId gt es uniovi innova lt  groupId gt           lt version gt 1 0 0 lt  version gt       lt  parent gt        lt dependencies gt                 lt dependency gt               lt groupId gt com liferay portal lt  groupId gt               lt artifactId gt ALL-DEPS lt  artifactId gt               lt version gt 1 0 lt  version gt               lt scope gt provided lt  scope gt               lt type gt pom lt  type gt           lt  dependency gt       lt  dependencies gt   lt  project gt    base artifact  depends on  javax mail mail-1 4 jar  and ALL-DEPS depends on another version of the same library  Due to the fact that mail jar from ALL-DEPS exist on the execution environment  although not exported  collides with the mail jar that exists on the parent  which is scoped as compile   A solution could be to rid off mail jar from the parent POM  but most of the projects that inherit base  need it  as is a transtive dependency for log4j   So What I would like to do is to simply exclude parent s library from the child project  as it could be done if base was a dependency and not the parent pom            lt dependency gt           lt artifactId gt base lt  artifactId gt           lt groupId gt es uniovi innova lt  groupId gt           lt version gt 1 0 0 lt  version gt           lt type gt pom lt type gt           lt exclusions gt             lt exclusion gt                lt groupId gt javax mail lt  groupId gt                lt artifactId gt mail lt  artifactId gt             lt  exclusion gt           lt  exclusions gt       lt  dependency gt

User · Answer

You can group your dependencies within a different project with packaging pom as described by Sonatypes Best Practices:

<project>
    <modelVersion>4.0.0</modelVersion>
    <artifactId>base-dependencies</artifactId>
    <groupId>es.uniovi.innova</groupId>
    <version>1.0.0</version>
    <packaging>pom</packaging>
    <dependencies>
        <dependency>
            <groupId>javax.mail</groupId>
            <artifactId>mail</artifactId>
            <version>1.4</version>
        </dependency>
    </dependencies>
</project>

and reference them from your parent-pom (watch the dependency <type>pom</type>):

<project>
    <modelVersion>4.0.0</modelVersion>
    <artifactId>base</artifactId>
    <groupId>es.uniovi.innova</groupId>
    <version>1.0.0</version>
    <packaging>pom</packaging>
    <dependencies>
        <dependency>
            <artifactId>base-dependencies</artifactId>
            <groupId>es.uniovi.innova</groupId>
            <version>1.0.0</version>
            <type>pom</type>
        </dependency>
    </dependencies>
</project>

Your child-project inherits this parent-pom as before. But now, the mail dependency can be excluded in the child-project within the dependencyManagement block:

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>test</groupId>
    <artifactId>jruby</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <parent>
        <artifactId>base</artifactId>
        <groupId>es.uniovi.innova</groupId>
        <version>1.0.0</version>
    </parent>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <artifactId>base-dependencies</artifactId>
                <groupId>es.uniovi.innova</groupId>
                <version>1.0.0</version>
                <exclusions>
                    <exclusion>
                        <groupId>javax.mail</groupId>
                        <artifactId>mail</artifactId>
                    </exclusion>
                </exclusions>
            </dependency>
        </dependencies>
    </dependencyManagement>
</project>

User · Answer

Have you tried explicitly declaring the version of mail jar you want   Maven s dependency resolution should use this for dependency resolution over all other versions    lt project gt     lt modelVersion gt 4 0 0 lt  modelVersion gt     lt groupId gt test lt  groupId gt     lt artifactId gt jruby lt  artifactId gt       lt version gt 0 0 1-SNAPSHOT lt  version gt       lt parent gt           lt artifactId gt base lt  artifactId gt           lt groupId gt es uniovi innova lt  groupId gt           lt version gt 1 0 0 lt  version gt       lt  parent gt       lt dependencies gt                     lt dependency gt               lt groupId gt javax mail lt  groupId gt               lt artifactId gt mail lt  artifactId gt               lt version gt VERSION-  lt  version gt               lt scope gt provided lt  scope gt           lt  dependency gt            lt dependency gt               lt groupId gt com liferay portal lt  groupId gt               lt artifactId gt ALL-DEPS lt  artifactId gt               lt version gt 1 0 lt  version gt               lt scope gt provided lt  scope gt               lt type gt pom lt  type gt           lt  dependency gt       lt  dependencies gt   lt  project gt

User · Answer

Some ideas    Maybe you could simply not inherit from the parent in that case  and declare a dependency on base with the exclusion   Not handy if you have lot of stuff in the parent pom  Another thing to test would be to declare the mail artifact with the version required by ALL-DEPS under the dependencyManagement in the parent pom to force the convergence  although I m not sure this will solve the scoping problem      lt dependencyManagement gt     lt dependencies gt       lt dependency gt             lt groupId gt javax mail lt  groupId gt         lt artifactId gt mail lt  artifactId gt         lt version gt     lt  version gt  lt  -- put the  right  version here -- gt       lt  dependency gt     lt  dependencies gt   lt  dependencyManagement gt     Or you could exclude the mail dependency from log4j if you re not using the features relying on it  and this is what I would do      lt dependency gt     lt groupId gt log4j lt  groupId gt     lt artifactId gt log4j lt  artifactId gt     lt version gt 1 2 15 lt  version gt     lt scope gt provided lt  scope gt     lt exclusions gt       lt exclusion gt         lt groupId gt javax mail lt  groupId gt         lt artifactId gt mail lt  artifactId gt       lt  exclusion gt       lt exclusion gt         lt groupId gt javax jms lt  groupId gt         lt artifactId gt jms lt  artifactId gt       lt  exclusion gt       lt exclusion gt         lt groupId gt com sun jdmk lt  groupId gt         lt artifactId gt jmxtools lt  artifactId gt       lt  exclusion gt       lt exclusion gt         lt groupId gt com sun jmx lt  groupId gt         lt artifactId gt jmxri lt  artifactId gt       lt  exclusion gt     lt  exclusions gt   lt  dependency gt     Or you could revert to the version 1 2 14 of log4j instead of the heretic 1 2 15 version  why didn t they mark the above dependencies as optional

User · Answer

When you call a package but do not want some of its dependencies you can do a thing like this  in this case I did not want the old log4j to be added because I needed to use the newer one     lt dependency gt     lt groupId gt package lt  groupId gt     lt artifactId gt package-pk lt  artifactId gt     lt version gt   package-pk version  lt  version gt      lt exclusions gt       lt exclusion gt         lt groupId gt org apache logging log4j lt  groupId gt         lt artifactId gt log4j-core lt  artifactId gt       lt  exclusion gt       lt exclusion gt         lt groupId gt org apache logging log4j lt  groupId gt         lt artifactId gt log4j-api lt  artifactId gt       lt  exclusion gt     lt  exclusions gt   lt  dependency gt    lt  -- LOG4J -- gt   lt dependency gt     lt groupId gt org apache logging log4j lt  groupId gt     lt artifactId gt log4j-core lt  artifactId gt     lt version gt 2 5 lt  version gt   lt  dependency gt   lt dependency gt     lt groupId gt org apache logging log4j lt  groupId gt     lt artifactId gt log4j-api lt  artifactId gt     lt version gt 2 5 lt  version gt   lt  dependency gt    This works for me    but I am pretty new to java maven so it is maybe not optimum

User · Answer

Don t use a parent pom  This might sound extreme  but the same way  inheritance hell  is a reason some people turn their backs on Object Oriented Programming  or prefer composition over inheritance   remove the problematic  lt parent gt  block and copy and paste whatever  lt dependencies gt  you need  if your team gives you this liberty    The assumption that splitting of poms into a parent and child for  reuse  and  avoidance of redunancy  should be ignored and you should serve your immediate needs first  the cure is worst than the disease   Besides  redundancy has its advantages - namely independence of external changes  i e stability    This is easier than it sounds if you generate the effective pom  eclipse provides it but you can generate it from the command line with mvn help effective    Example  I want to use logback as my slf4j binding  but my parent pom includes the log4j dependency  I don t want to go and have to push the other children s dependence on log4j down into their own pom xml files so that mine is unobstructed

User · Answer

We can add the parent pom as a dependency with type pom and make exclusion on that  Because anyhow parent pom is downloaded  This worked for me   lt dependency gt     lt groupId gt com abc boot lt  groupId gt     lt artifactId gt abc-boot-starter-parent lt  artifactId gt     lt version gt 2 1 5 RELEASE lt  version gt     lt type gt pom lt  type gt     lt exclusions gt       lt exclusion gt         lt groupId gt com google code gson lt  groupId gt         lt artifactId gt gson lt  artifactId gt       lt  exclusion gt     lt  exclusions gt      lt  dependency gt

User · Answer

I really needed to do this dirty thing    Here is how  I redefined those dependencies with scope test  Scope provided did not work for me    We use spring Boot plugin to build fat jar  We have module common which defines common libraries  for example Springfox swagger-2  My super-service needs to have parent common  it does not want to do so  but company rules force    So my parent or commons has pom    lt dependencyManagement gt        lt  - I do not need Springfox in one child but in others - gt        lt dependencies gt           lt dependency gt               lt groupId gt io springfox lt  groupId gt               lt artifactId gt springfox-swagger2 lt  artifactId gt               lt version gt   swagger version  lt  version gt               lt exclusions gt                   lt exclusion gt                       lt groupId gt com google guava lt  groupId gt                       lt artifactId gt guava lt  artifactId gt                   lt  exclusion gt               lt  exclusions gt           lt  dependency gt           lt dependency gt               lt groupId gt io springfox lt  groupId gt               lt artifactId gt springfox-swagger-ui lt  artifactId gt               lt version gt   swagger version  lt  version gt           lt  dependency gt           lt dependency gt               lt groupId gt io springfox lt  groupId gt               lt artifactId gt springfox-bean-validators lt  artifactId gt               lt version gt   swagger version  lt  version gt           lt  dependency gt           lt  - All services need them - gt           lt dependency gt               lt groupId gt junit lt  groupId gt               lt artifactId gt junit lt  artifactId gt               lt version gt   junit version  lt  version gt           lt  dependency gt           lt dependency gt               lt groupId gt org apache poi lt  groupId gt               lt artifactId gt poi-ooxml lt  artifactId gt               lt version gt   apache poi version  lt  version gt           lt  dependency gt       lt  dependencies gt   lt  dependencyManagement gt    And my super-service pom    lt name gt super-service lt  name gt   lt parent gt       lt groupId gt com company lt  groupId gt       lt artifactId gt common lt  artifactId gt       lt version gt 1 lt  version gt   lt  parent gt    lt dependencies gt        lt  - I don t need them - gt        lt dependency gt           lt groupId gt io springfox lt  groupId gt           lt artifactId gt springfox-swagger2 lt  artifactId gt           lt scope gt test lt  scope gt       lt  dependency gt       lt dependency gt           lt groupId gt io springfox lt  groupId gt           lt artifactId gt springfox-bean-validators lt  artifactId gt           lt scope gt test lt  scope gt       lt  dependency gt       lt dependency gt           lt groupId gt io springfox lt  groupId gt           lt artifactId gt springfox-core lt  artifactId gt           lt version gt 2 8 0 lt  version gt           lt scope gt test lt  scope gt       lt  dependency gt        lt  - Required dependencies - gt        lt dependency gt           lt groupId gt org springframework boot lt  groupId gt           lt artifactId gt spring-boot-starter-web lt  artifactId gt       lt  dependency gt        lt dependency gt           lt groupId gt junit lt  groupId gt           lt artifactId gt junit lt  artifactId gt       lt  dependency gt       lt dependency gt           lt groupId gt org apache poi lt  groupId gt           lt artifactId gt poi-ooxml lt  artifactId gt       lt  dependency gt   lt  dependencies gt    This is size of the final fat artifact  82 3 MB  86 351 753 bytes  - redefined dependency with scope test 86 1 MB  90 335 466 bytes  - redefined dependency with scope provided 86 1 MB  90 335 489 bytes  - without exclusion   Also this answer is worth mentioning - I wanted to do so  but I am lazy    https   stackoverflow com a 48103554 4587961

User · Answer

Best bet is to make the dependencies you don t always want to inherit intransitive   You can do this by marking them in the parent pom with scope provided   If you still want the parent to manage versions of these deps  you can use the  lt dependencyManagement gt  tag to setup the versions you want without explicitly inheriting them  or passing that inheritance along to children

User · Answer

Redefine the dependency  in the child pom  with scope system pointing to an empty jar     lt dependency gt       lt groupId gt dependency coming lt  groupId gt       lt artifactId gt from parent lt  artifactId gt       lt version gt 0 lt  version gt       lt scope gt system lt  scope gt       lt systemPath gt   project basedir  empty jar lt  systemPath gt   lt  dependency gt    The jar can contain just a single empty file    touch empty txt jar cvf empty txt

User · Answer

Repeat the parent s dependency in child pom xml and insert the exclusion there   lt dependency gt       lt groupId gt org springframework boot lt  groupId gt       lt artifactId gt spring-boot-starter-test lt  artifactId gt       lt scope gt test lt  scope gt       lt exclusions gt           lt exclusion gt               lt groupId gt com vaadin external google lt  groupId gt               lt artifactId gt android-json lt  artifactId gt           lt  exclusion gt       lt  exclusions gt   lt  dependency gt

[java] Is there anyway to exclude artifacts inherited from a parent POM?

Examples related to java

Examples related to maven

Examples related to maven-2

Examples related to pom.xml