Details

    • New Feature
    • Status: Reopened
    • Major
    • Resolution: Unresolved
    • None
    • FDPFC, POM
    • None

    Description

      I depend on some libraries, which in turn depend on something
      (which in turn depend on something) that I don't want, because I declare
      some other artifact in my pom.xml.

      A concrete example: I don't want that the artifact "xerces" is imported in
      my project because I declare to depend on "xercesImpl" which ships newer
      libraries but with the same namespaces.

      I guess I would need an "exclude transitive dependency at all", either
      globally or from this and that artifact. I saw the <exclusions> tag, but it
      forces me to be very verbose and have exact control on what is required by a
      dependency.

      Attachments

        1. global_excls_maven3_v2.patch
          7 kB
          Jean-Noel Rouvignac
        2. global_excls_it-test_v2.patch
          18 kB
          Jean-Noel Rouvignac
        3. global_excls_it-test_v3.patch
          17 kB
          Jean-Noel Rouvignac
        4. global_excls_maven3_v3.patch
          9 kB
          Jean-Noel Rouvignac

        Issue Links

          Activity

            From MNG-2031:

            Transitive dependencies are cool, however, the limitations are very difficult to work around.

            • specification dependencies
            • jarjar dependencies (spring.jar includes all spring-xxx.jar, so no need to include them)
            • remove warning on relocations for transitive dependencies (it's always difficult to tell users: that's not an error, and we can not do anything)
            • poms on ibiblio are all in m2 and never change
            • exclusions for transitive deps can be overriden if manually included

            One cool feature would be to allow disabling transitive dependencies in the following ways:

            • disable all transitive deps
            • enable transitive dependencies only for modules of the same project
            • enable transitive deps for specific groupIds
            • disable transitive deps for specific groupIds
            • have a tag/attribute to exclude all transitive deps for one dependency (instead of having list all exclusions)
            carlos Carlos Sanchez Gonzalez added a comment - From MNG-2031 : Transitive dependencies are cool, however, the limitations are very difficult to work around. specification dependencies jarjar dependencies (spring.jar includes all spring-xxx.jar, so no need to include them) remove warning on relocations for transitive dependencies (it's always difficult to tell users: that's not an error, and we can not do anything) poms on ibiblio are all in m2 and never change exclusions for transitive deps can be overriden if manually included One cool feature would be to allow disabling transitive dependencies in the following ways: disable all transitive deps enable transitive dependencies only for modules of the same project enable transitive deps for specific groupIds disable transitive deps for specific groupIds have a tag/attribute to exclude all transitive deps for one dependency (instead of having list all exclusions)
            mpo Marc Portier added a comment -

            Adding another possibly featured way to configure:

            • disable all transitive deps for certain scopes

            (e.g.: I'ld like transitive deps marked for 'runtime' and 'compile', but not for 'test')

            mpo Marc Portier added a comment - Adding another possibly featured way to configure: disable all transitive deps for certain scopes (e.g.: I'ld like transitive deps marked for 'runtime' and 'compile', but not for 'test')
            gilles Gilles Bayon added a comment -

            The squeakiest tire get the oil first : That would be indeed a much wanted feature.

            Gilles

            Gilles Tabary

            gilles Gilles Bayon added a comment - The squeakiest tire get the oil first : That would be indeed a much wanted feature. Gilles Gilles Tabary
            steff Stefan Gmeiner added a comment -

            Hi,

            I'm wondering why this, in my eyes, important feature won't be fixed in 2.0x but in 2.1 (next year)? The initial request is more than one year old!

            My project depends on some jars but NOT on their dependencies. Neither at compile nor at test or runtime. Therefore it makes no sense to download these dependecies at all.

            With the current mechanism of using the <exclusions/> element within each dependency separately causes a lot of boilerplate configuration steps. In my case for over 30 dependencies!

            I like the idea of having a global <exclusion/> element within <dependencyManagement/> or allowing wildcards for artifactId and groupId or intrdoucing an attribute transitive="false" on the <dependency/> element.

            Please make this a higher prio, thanks!

            steff Stefan Gmeiner added a comment - Hi, I'm wondering why this, in my eyes, important feature won't be fixed in 2.0x but in 2.1 (next year)? The initial request is more than one year old! My project depends on some jars but NOT on their dependencies. Neither at compile nor at test or runtime. Therefore it makes no sense to download these dependecies at all. With the current mechanism of using the <exclusions/> element within each dependency separately causes a lot of boilerplate configuration steps. In my case for over 30 dependencies! I like the idea of having a global <exclusion/> element within <dependencyManagement/> or allowing wildcards for artifactId and groupId or intrdoucing an attribute transitive="false" on the <dependency/> element. Please make this a higher prio, thanks!

            The main issue it that it can't be specified in the current pom model (4.0.0) and updates to the pom model require the next version aka 2.1.

            There is a way to detect these creeping in, in dependency:analyze-dep-mgt and in the next enforcer release, there will be a rule that can fail the build when any excluded dependencies are found in the build.

            brianf@infinity.nu Brian E. Fox (imported) added a comment - The main issue it that it can't be specified in the current pom model (4.0.0) and updates to the pom model require the next version aka 2.1. There is a way to detect these creeping in, in dependency:analyze-dep-mgt and in the next enforcer release, there will be a rule that can fail the build when any excluded dependencies are found in the build.
            dan.j.allen Dan Allen added a comment -

            I don't know, I will miss all of the late nights and long weekends I spend analyzing the dependency tree trying to get rid of one stupid JAR file that causes the application not to run properly. What will I do with all my extra time? Wow, maybe I can actually DEVELOP something.

            dan.j.allen Dan Allen added a comment - I don't know, I will miss all of the late nights and long weekends I spend analyzing the dependency tree trying to get rid of one stupid JAR file that causes the application not to run properly. What will I do with all my extra time? Wow, maybe I can actually DEVELOP something.

            I can just agree to others here, this is indeed a VERY important feature. It would ease the development a lot. As if you currently have such a bogus dependency you'll have to copy and paste every possible exclusion to every dependency. This is really ugly and costs a lot of time.

            wnagele Wolfgang Nagele added a comment - I can just agree to others here, this is indeed a VERY important feature. It would ease the development a lot. As if you currently have such a bogus dependency you'll have to copy and paste every possible exclusion to every dependency. This is really ugly and costs a lot of time.
            clive.jevons Clive Jevons added a comment -

            I'm currently also suffering from the lack of this feature and would be extremely grateful to see this one added
            Cheers,
            C

            clive.jevons Clive Jevons added a comment - I'm currently also suffering from the lack of this feature and would be extremely grateful to see this one added Cheers, C
            djencks David Jencks added a comment -

            It seems to me that the original problem would be solved better by artifact substitution or aliasing rather than more exclusions. e.g if you want to use something reasonable such as slf4j to imitate commons logging usage you want to replace any dependency on commons-logging with one on jcl-over-slf4j. Similarly you might want to swap spec implementations, say to use the geronimo ones no matter which copies the original projects were built against, or use geronimo's activation implementation instead of sun's. This isn't quite the same as what osgi gives you but is quite powerful.

            djencks David Jencks added a comment - It seems to me that the original problem would be solved better by artifact substitution or aliasing rather than more exclusions. e.g if you want to use something reasonable such as slf4j to imitate commons logging usage you want to replace any dependency on commons-logging with one on jcl-over-slf4j. Similarly you might want to swap spec implementations, say to use the geronimo ones no matter which copies the original projects were built against, or use geronimo's activation implementation instead of sun's. This isn't quite the same as what osgi gives you but is quite powerful.
            kdekooter Kees de Kooter added a comment -

            You are right David, that would solve the original problem in an elegant way. Is this an existing feature I missed or should we submit a new jira issue for this?

            kdekooter Kees de Kooter added a comment - You are right David, that would solve the original problem in an elegant way. Is this an existing feature I missed or should we submit a new jira issue for this?
            memelet Barry Kaplan added a comment -

            Aliasing would be nice. But I would also like to be able to specify that, for example, junit-3.8.1 should NEVER be downloaded and never be resolved as a dependency for my projects. I don't ever want junit-3.8.1 and junit-4.5 to both be in the same classpath.

            memelet Barry Kaplan added a comment - Aliasing would be nice. But I would also like to be able to specify that, for example, junit-3.8.1 should NEVER be downloaded and never be resolved as a dependency for my projects. I don't ever want junit-3.8.1 and junit-4.5 to both be in the same classpath.

            This just became a total showstopper with SpringSource effectively cloning the entire maven dependency set in their "enterprise" repo.
            I know that's not maven's fault, but both global exclusions (e.g. as protections again known bad poms) and aliasing (to always substitute slf4j for clogging) would really fix a lot of problems that this has caused.

            h2o Holger Hoffstätte added a comment - This just became a total showstopper with SpringSource effectively cloning the entire maven dependency set in their "enterprise" repo. I know that's not maven's fault, but both global exclusions (e.g. as protections again known bad poms) and aliasing (to always substitute slf4j for clogging) would really fix a lot of problems that this has caused.

            That's a lovely development. If you use Nexus, you can control which artifacts come from a given repo so you can prevent the springsource repo from polluting your team. There's nothing that can be done inside maven for global exclusions until 3.0 since it requires a model change in the pom.

            brianf@infinity.nu Brian E. Fox (imported) added a comment - That's a lovely development. If you use Nexus, you can control which artifacts come from a given repo so you can prevent the springsource repo from polluting your team. There's nothing that can be done inside maven for global exclusions until 3.0 since it requires a model change in the pom.
            zepag Pierre-Antoine Grégoire added a comment - - edited

            It's a sad thing that this will never be available for backports because the pom model cannot be changed..

            This is a very much awaited feature. And though I like a lot tools of the like of Nexus (Artifactory is also very nice BTW), I think Maven should provide these mechanisms and that maybe 2.1 release was a bit rushed in this prospect.

            Is there a timeframe for 3.0 already?

            Why is this not planned for 2.2 for example?

            Oh, and BTW: my simple wishes http://blog.zepag.org/2009/05/my-wishes-for-better-maven-2.html

            zepag Pierre-Antoine Grégoire added a comment - - edited It's a sad thing that this will never be available for backports because the pom model cannot be changed.. This is a very much awaited feature. And though I like a lot tools of the like of Nexus (Artifactory is also very nice BTW), I think Maven should provide these mechanisms and that maybe 2.1 release was a bit rushed in this prospect. Is there a timeframe for 3.0 already? Why is this not planned for 2.2 for example? Oh, and BTW: my simple wishes http://blog.zepag.org/2009/05/my-wishes-for-better-maven-2.html

            Pierre,

            The pom format can't be changed until Maven 3.x. The alphas of 3.x are close by, but currently it's focused on 2.x compatibility with the new code and a process to handle pom model changes hasn't been built yet.

            brianf@infinity.nu Brian E. Fox (imported) added a comment - Pierre, The pom format can't be changed until Maven 3.x. The alphas of 3.x are close by, but currently it's focused on 2.x compatibility with the new code and a process to handle pom model changes hasn't been built yet.
            nealeu Neale Upstone added a comment -

            For those needing aliasing/substitution, there is a proposal at MNG-4391.

            I note that David and Kees were suggesting this a year back.

            nealeu Neale Upstone added a comment - For those needing aliasing/substitution, there is a proposal at MNG-4391 . I note that David and Kees were suggesting this a year back.
            mahoney Robert Elliot added a comment -

            Could this not be achieved via a new scope? I'm thinking:
            <dependency>
            <groupId>commons-logging</groupId>
            <artifactId>commons-logging</artifactId>
            <version>1.1.1</version>
            <scope>excluded</scope>
            </dependency>

            Semantics would be that any artifactId declared in this way would be guaranteed not to be on either the test or main runtime or compile time classpath, and neither would any of its transitive dependencies, and its transitive dependencies would not be added to the declaring pom's transitive dependencies, regardless of version number or where in the transitive dependency tree it occurred.

            mahoney Robert Elliot added a comment - Could this not be achieved via a new scope? I'm thinking: <dependency> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> <version>1.1.1</version> <scope>excluded</scope> </dependency> Semantics would be that any artifactId declared in this way would be guaranteed not to be on either the test or main runtime or compile time classpath, and neither would any of its transitive dependencies, and its transitive dependencies would not be added to the declaring pom's transitive dependencies, regardless of version number or where in the transitive dependency tree it occurred.
            mahoney Robert Elliot added a comment -

            (This is effectively how people are achieving the desired effect already, by using scope "provided" - but that has the negative that the artifact and all of its transitive dependencies are still on the compile classpath raising the possibility of errors only discovered at runtime.)

            mahoney Robert Elliot added a comment - (This is effectively how people are achieving the desired effect already, by using scope "provided" - but that has the negative that the artifact and all of its transitive dependencies are still on the compile classpath raising the possibility of errors only discovered at runtime.)

            Hi Robert,

            You are right to observe that the provided scope has the inconvenience of placing the thus "excluded" artifact on the project's class path within the IDE, in particular Eclipse. However, as far as I know, the artifact is effectively excluded during build time by Maven. The provided scope is unsatisfactory during development time within the IDE, i.e. within Eclipse or IDEA.

            ceki@qos.ch Ceki GĂĽlcĂĽ added a comment - Hi Robert, You are right to observe that the provided scope has the inconvenience of placing the thus "excluded" artifact on the project's class path within the IDE, in particular Eclipse. However, as far as I know, the artifact is effectively excluded during build time by Maven. The provided scope is unsatisfactory during development time within the IDE, i.e. within Eclipse or IDEA.
            mahoney Robert Elliot added a comment -

            Maven definitely makes provided scope dependencies available at compile time - otherwise no library compiled against the servlet api would compile. A good example in the logging context would be someone who desired to use slf4j-over-log4j instead of log4j. Making log4j itself have scope provided would have the desired runtime behaviour of excluding the log4j jar if any transitive dependency brought it in, thereby preventing any non-determinate behaviour depending on which version of the log4j classes the classloader loaded first; however, at compile time Maven would happily be able to compile code dependent on classes that are included in log4j but are not in slf4j-over-log4j, and the user would only discover the problem at runtime.

            mahoney Robert Elliot added a comment - Maven definitely makes provided scope dependencies available at compile time - otherwise no library compiled against the servlet api would compile. A good example in the logging context would be someone who desired to use slf4j-over-log4j instead of log4j. Making log4j itself have scope provided would have the desired runtime behaviour of excluding the log4j jar if any transitive dependency brought it in, thereby preventing any non-determinate behaviour depending on which version of the log4j classes the classloader loaded first; however, at compile time Maven would happily be able to compile code dependent on classes that are included in log4j but are not in slf4j-over-log4j, and the user would only discover the problem at runtime.

            D'oh! Thanks for the explanation.

            ceki@qos.ch Ceki GĂĽlcĂĽ added a comment - D'oh! Thanks for the explanation.
            jnrouvignac Jean-Noel Rouvignac added a comment - - edited

            Hello,

            I gave a go at this new feature following
            Rob Elliot's idea of using a

            <scope>excluded</scope>

            . And it works a treat for me.

            I uploaded the maven changes + integration test as patches.

            Thanks,
            Jean-Noel

            jnrouvignac Jean-Noel Rouvignac added a comment - - edited Hello, I gave a go at this new feature following Rob Elliot's idea of using a <scope>excluded</scope> . And it works a treat for me. I uploaded the maven changes + integration test as patches. Thanks, Jean-Noel

            Hi, I didn't review your patch thus I won't judge about it.
            I really dislike this idea to continue to play with the lake of control in old maven versions which will ignore things they don't know in the POM.
            For me such change must be done only in a new POM version and with all mechanisms to be used with previous and future maven versions.
            Did you test such POM with Maven 3.0.x ? I think it at least display a warning if there is a scope it doesn't know (I don't remember but perhaps it breaks the build).
            And when a maven version ignores it, what does it do ? It uses the compile scope ? #fail in that case, instead of excluding it, you explicitely add it (transitively)

            Cheers

            aheritier Arnaud Heritier added a comment - Hi, I didn't review your patch thus I won't judge about it. I really dislike this idea to continue to play with the lake of control in old maven versions which will ignore things they don't know in the POM. For me such change must be done only in a new POM version and with all mechanisms to be used with previous and future maven versions. Did you test such POM with Maven 3.0.x ? I think it at least display a warning if there is a scope it doesn't know (I don't remember but perhaps it breaks the build). And when a maven version ignores it, what does it do ? It uses the compile scope ? #fail in that case, instead of excluding it, you explicitely add it (transitively) Cheers

            Hello,

            BTW the <scope>excluded</scope> solution doesn't really helps in any way to deal easily with excludes.
            It looks like a hard-wired work-around.
            Adding a <transitive>true|false</transitive> or a <handling>transitive|simple</handling> (maybe better to allow further unforeseen improvements) both at the level of all <dependencies></dependencies> or at the level of a single <dependency></dependency> wouldn't be hard to deal with (just a test to trigger the transitive search of the underlying tree) and would achieve the expected result.

            I thought that the pom model was supposed to evolve from version 3.0.x on?

            Regards.

            Pierre-Antoine.

            zepag Pierre-Antoine Grégoire added a comment - Hello, BTW the <scope>excluded</scope> solution doesn't really helps in any way to deal easily with excludes. It looks like a hard-wired work-around. Adding a <transitive>true|false</transitive> or a <handling>transitive|simple</handling> (maybe better to allow further unforeseen improvements) both at the level of all <dependencies></dependencies> or at the level of a single <dependency></dependency> wouldn't be hard to deal with (just a test to trigger the transitive search of the underlying tree) and would achieve the expected result. I thought that the pom model was supposed to evolve from version 3.0.x on? Regards. Pierre-Antoine.
            jnrouvignac Jean-Noel Rouvignac added a comment - - edited

            @Arnaud Sorry, I went for the easiest to implement. If you do not like it this way, fair enough, we can do it otherwise. I originally started with such change to the pom.xml:

            <project>
                <dependencies>
                    <exclusions>
                        <exclusion>
                            <groupId>com.mycompany</groupId>
                            <artifactId>myproject</artifactId>
                            <classifier>optional</classifier>
                        </exclusion>
                    </exclusions>
                    <dependency>
                        ...
                    </dependency>
                    ...
                </dependencies>
                ...
            </project>

            No I did not test with older versions of maven.
            I saw that maven-3 has got some validation mechanism for the scope so I think it would reject it.
            For maven-2 I need to check. Indeed the following scenario would be catastrophic:
            "And when a maven version ignores it, what does it do ? It uses the compile scope ? #fail in that case, instead of excluding it, you explicitely add it (transitively)".
            I will test both of these and let you know.

            Same, it does not really matter to me which mechanism you prefer to use. Just tell me how you want it to look in the pom.xml and I can have a look at doing it.

            Jean-Noel

            jnrouvignac Jean-Noel Rouvignac added a comment - - edited @Arnaud Sorry, I went for the easiest to implement. If you do not like it this way, fair enough, we can do it otherwise. I originally started with such change to the pom.xml: <project> <dependencies> <exclusions> <exclusion> <groupId>com.mycompany</groupId> <artifactId>myproject</artifactId> <classifier>optional</classifier> </exclusion> </exclusions> <dependency> ... </dependency> ... </dependencies> ... </project> No I did not test with older versions of maven. I saw that maven-3 has got some validation mechanism for the scope so I think it would reject it. For maven-2 I need to check. Indeed the following scenario would be catastrophic: "And when a maven version ignores it, what does it do ? It uses the compile scope ? #fail in that case, instead of excluding it, you explicitely add it (transitively)". I will test both of these and let you know. Same, it does not really matter to me which mechanism you prefer to use. Just tell me how you want it to look in the pom.xml and I can have a look at doing it. Jean-Noel

            Hi Arnaud,

            You were right, using <scope>excluded</scope> with older versions of maven (I used v2.2.1) gives the opposite result to what is intended. The excluded scope is ignored and replaced with a compile scope.

            How do you want to proceed now? I suppose we now need to do a pom.xml format change. If I understood correctly , this is scheduled for maven 3.1.

            Do you want to go for the solution I suggested in my last comment?
            http://jira.codehaus.org/browse/MNG-1977?focusedCommentId=277793&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-277793

            Or do you want to do it differently?

            Please let me know your suggestions and I will try to implement it.

            Thanks,
            Jean-Noël

            jnrouvignac Jean-Noel Rouvignac added a comment - Hi Arnaud, You were right, using <scope>excluded</scope> with older versions of maven (I used v2.2.1) gives the opposite result to what is intended. The excluded scope is ignored and replaced with a compile scope. How do you want to proceed now? I suppose we now need to do a pom.xml format change. If I understood correctly , this is scheduled for maven 3.1. Do you want to go for the solution I suggested in my last comment? http://jira.codehaus.org/browse/MNG-1977?focusedCommentId=277793&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-277793 Or do you want to do it differently? Please let me know your suggestions and I will try to implement it. Thanks, Jean-Noël

            Might be that this is already commented, but here's what we need:

            • Possibility to exclude transitive dependencies using groupId only (meaning all artifacts/versions within that groupId)
            • Another nice feature would be, a global pom setting that says: "Use transitive dependencies during compile, but not during packaging". Meaning: You can quickly get up developing code (getting all dependencies needed), but when bundling ex a war file, exclude trans. dep. because you want to control the war content.
            • Also a nice feature would be to turn off transitive dependencies all together
            morten Morten Jorgensen added a comment - Might be that this is already commented, but here's what we need: Possibility to exclude transitive dependencies using groupId only (meaning all artifacts/versions within that groupId) Another nice feature would be, a global pom setting that says: "Use transitive dependencies during compile, but not during packaging". Meaning: You can quickly get up developing code (getting all dependencies needed), but when bundling ex a war file, exclude trans. dep. because you want to control the war content. Also a nice feature would be to turn off transitive dependencies all together
            nealeu Neale Upstone added a comment -

            I think there's some allusion to a version 5 of pom.xml, which would be interesting.

            If nothing else, I certainly support the idea of <scope>exclude</scope>.

            It is time that we got a release that solved some of the longest standing issues and gave us an opportunity to move forwards rather than to live with backwards compatibility that kills us.

            I love the idea of allowing a switch to change

            compile -> compile = compile

            to what was originally intended, that

            compile -> compile = runtime

            This would make many builds far more robust to changes in child dependencies.

            nealeu Neale Upstone added a comment - I think there's some allusion to a version 5 of pom.xml, which would be interesting. If nothing else, I certainly support the idea of <scope>exclude</scope>. It is time that we got a release that solved some of the longest standing issues and gave us an opportunity to move forwards rather than to live with backwards compatibility that kills us. I love the idea of allowing a switch to change compile -> compile = compile to what was originally intended, that compile -> compile = runtime This would make many builds far more robust to changes in child dependencies.

            @Morten: I think that "Include transitive dependencies during packaging" should rather be a feature of war, shade and other packaging plugins. There must already be enough information available to plugins through project meta-data, because maven-assembly-plugin has already got an option to filter out transitive dependencies.

            sergei_ivanov@mail.ru Sergei S. Ivanov added a comment - @Morten: I think that "Include transitive dependencies during packaging" should rather be a feature of war, shade and other packaging plugins. There must already be enough information available to plugins through project meta-data, because maven-assembly-plugin has already got an option to filter out transitive dependencies.

            @Neale: I agree that it would make a lot of sense to promote transitive compile dependencies into runtime scope, but unfortunately that does not solve the problem of polluting the runtime scope with unwanted transitive dependencies.
            More flexible exclusion mechanism using patterns or some other configuration is still needed.

            sergei_ivanov@mail.ru Sergei S. Ivanov added a comment - @Neale: I agree that it would make a lot of sense to promote transitive compile dependencies into runtime scope, but unfortunately that does not solve the problem of polluting the runtime scope with unwanted transitive dependencies. More flexible exclusion mechanism using patterns or some other configuration is still needed.
            joehni Joerg Schaible added a comment -

            compile -> compile = runtime

            This would make many builds far more robust to changes in child dependencies.

            You can simulate this if you use a global master pom. Then you would not only set the version in the depMgmt, but also the scope of all deps to runtime. That will have the same effect, you would have to set compile scope explicitly everywhere in our project. Been there and reverted it ... you'll see yourself, if you try

            joehni Joerg Schaible added a comment - compile -> compile = runtime This would make many builds far more robust to changes in child dependencies. You can simulate this if you use a global master pom. Then you would not only set the version in the depMgmt, but also the scope of all deps to runtime. That will have the same effect, you would have to set compile scope explicitly everywhere in our project. Been there and reverted it ... you'll see yourself, if you try

            Thanks for the feedback guys.

            My use case is as simple as that: I want to exclude some transitive dependencies accross all dependencies to allow compiling GWT code. Otherwise I get the error "the input line is too long" on windows. So far we have to exclude the same transitive dependencies for all the dependencies where they exist which can be as many as 8 today. Not nice :-/, hence why I am looking at this solution. A simple global exclude would solve the problem for us.

            It looks to me the code I did is good enough to handle my use case. I just need to know how the Maven team wants this configuration to look in the pom.xml file and then I can look at doing it.

            jnrouvignac Jean-Noel Rouvignac added a comment - Thanks for the feedback guys. My use case is as simple as that: I want to exclude some transitive dependencies accross all dependencies to allow compiling GWT code. Otherwise I get the error "the input line is too long" on windows. So far we have to exclude the same transitive dependencies for all the dependencies where they exist which can be as many as 8 today. Not nice :-/, hence why I am looking at this solution. A simple global exclude would solve the problem for us. It looks to me the code I did is good enough to handle my use case. I just need to know how the Maven team wants this configuration to look in the pom.xml file and then I can look at doing it.

            Hello,

            I gave another go at this issue.
            This time, I specified the exclusions in the pom.xml file by following this approach:

            <project>
              <dependencies>
                ...
              </dependencies>
              ...
              <exclusions>
                <exclusion>
                  <groupId>com.mycompany</groupId>
                  <artifactId>myproject</artifactId>
                </exclusion>
              </exclusions>
            
              ...
            </project>
            

            Please let me know what you think of these patches.

            Thanks,
            Jean-Noel

            jnrouvignac Jean-Noel Rouvignac added a comment - Hello, I gave another go at this issue. This time, I specified the exclusions in the pom.xml file by following this approach: <project> <dependencies> ... </dependencies> ... <exclusions> <exclusion> <groupId>com.mycompany</groupId> <artifactId>myproject</artifactId> </exclusion> </exclusions> ... </project> Please let me know what you think of these patches. Thanks, Jean-Noel
            heymjo Jorg Heymans added a comment -

            +1 to this, though i'm not sure if maven is still being actively developed ?

            heymjo Jorg Heymans added a comment - +1 to this, though i'm not sure if maven is still being actively developed ?
            nealeu Neale Upstone added a comment -

            JvZ - why not Maven 3.1 for this? It's highly voted and there's a patch, yet no comment on the patch has been made. That's not good for goodwill

            nealeu Neale Upstone added a comment - JvZ - why not Maven 3.1 for this? It's highly voted and there's a patch, yet no comment on the patch has been made. That's not good for goodwill
            chenrici Christoph Henrici added a comment - - edited

            A real world problem needs a solution. Is there any real intention to adress this?

            chenrici Christoph Henrici added a comment - - edited A real world problem needs a solution. Is there any real intention to adress this?
            kdekooter Kees de Kooter added a comment -

            8 years, 155 votes, 5 duplicates and 4 patches later I wonder: should I be proud or embarrassed that the issue is still unresolved?

            kdekooter Kees de Kooter added a comment - 8 years, 155 votes, 5 duplicates and 4 patches later I wonder: should I be proud or embarrassed that the issue is still unresolved?
            ojs Oliver Siegmar added a comment -

            This issue and MNG-624 (which is even older) are two reasons why I switched to Gradle.

            ojs Oliver Siegmar added a comment - This issue and MNG-624 (which is even older) are two reasons why I switched to Gradle.
            radai Radai Rosenblatt added a comment - - edited

            i just lost 2 days peppering my poms with individual exclusions. can we please have this feature?

            radai Radai Rosenblatt added a comment - - edited i just lost 2 days peppering my poms with individual exclusions. can we please have this feature?
            danielywoo Daniel Woo added a comment -

            It has been always a problem for anyone who hates common loggings
            Really, this is a MUST-HAVE.

            danielywoo Daniel Woo added a comment - It has been always a problem for anyone who hates common loggings Really, this is a MUST-HAVE.
            miru Michael Rumpf added a comment -

            When using log4j2 there is a Jakarta Commons Logging Bridge that has the full commons-logging.jar as a dependency.
            That means the global exclusion needs to make sure that I can exclude all transitive deps to "commons-logging", except for the log4j-jcl.jar.

            Maybe like this:

            <project>
             <exclusions>
                <exclusion>
                  <groupId>commons-logging</groupId>
                  <artifactId>commons-logging</artifactId>
                </exclusion>
              </exclusions>
            </project>
            

            and for the log4j-jcl dependency:

            <dependency>
                <groupId>org.apache.logging.log4j</groupId>
                <artifactId>log4j-jcl</artifactId>
                <version>${log4j2.version}</version>
                <inclusions>
                    <!-- ... -->
                </inclusions>
            </dependency>
            
            miru Michael Rumpf added a comment - When using log4j2 there is a Jakarta Commons Logging Bridge that has the full commons-logging.jar as a dependency. That means the global exclusion needs to make sure that I can exclude all transitive deps to "commons-logging", except for the log4j-jcl.jar. Maybe like this: <project> <exclusions> <exclusion> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> </exclusion> </exclusions> </project> and for the log4j-jcl dependency: <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-jcl</artifactId> <version>${log4j2.version}</version> <inclusions> <!-- ... --> </inclusions> </dependency>

            Starting with Maven 3.2.1 there is simply a solution which excludes all transitve dependencies:

             <dependencies>
                <dependency>
                  <groupId>org.apache.maven</groupId>
                  <artifactId>maven-embedder</artifactId>
                  <version>3.1.0</version>
                  <exclusions>
                    <exclusion>
                      <groupId>*</groupId>
                      <artifactId>*</artifactId>
                    </exclusion>
                  </exclusions>
                </dependency>
                ...
              </dependencies>
            
            khmarbaise Karl Heinz Marbaise added a comment - Starting with Maven 3.2.1 there is simply a solution which excludes all transitve dependencies: <dependencies> <dependency> <groupId> org.apache.maven </groupId> <artifactId> maven-embedder </artifactId> <version> 3.1.0 </version> <exclusions> <exclusion> <groupId> * </groupId> <artifactId> * </artifactId> </exclusion> </exclusions> </dependency> ... </dependencies>
            vongosling Von Gosling added a comment - - edited

            maven-embedder,it's aim to embeded maven?,where can i find some more details about this maven plugin.here https://maven.apache.org/ref/3.3.3/maven-embedder/index.html too little infos.

            vongosling Von Gosling added a comment - - edited maven-embedder,it's aim to embeded maven?,where can i find some more details about this maven plugin.here https://maven.apache.org/ref/3.3.3/maven-embedder/index.html too little infos.

            Starting with Maven 3.4, you can manage dependencies to optional in dependency management. That is the same as excluding them globally when not explicitly declared as a direct dependency.

            schulte77 Christian Schulte added a comment - Starting with Maven 3.4, you can manage dependencies to optional in dependency management. That is the same as excluding them globally when not explicitly declared as a direct dependency.

            This has been revert for 3.4 and got postponed for 3.5.

            schulte77 Christian Schulte added a comment - This has been revert for 3.4 and got postponed for 3.5.

            Looking at the original ask, the correct solution is, rather that global exclusions, the ability to say X supplies Y as in something along the lines of either MNG-177 or MNG-5652

            IMHO a global excludes both complicates things for users as well as acting as a siren's call... applying exclusions is really an indication that somebody has done something wrong. We should not remove the ability to apply one-off per dependency fix-ups... individual projects can and will make mistakes from time to time... but a global exclusion, to my mind, indicates that the project that declares the global exclusion has made a mistake... they should just fix the mistake, rather than continue to propagate it further

            stephenc Stephen Connolly added a comment - Looking at the original ask, the correct solution is, rather that global exclusions, the ability to say X supplies Y as in something along the lines of either MNG-177 or MNG-5652 IMHO a global excludes both complicates things for users as well as acting as a siren's call... applying exclusions is really an indication that somebody has done something wrong. We should not remove the ability to apply one-off per dependency fix-ups... individual projects can and will make mistakes from time to time... but a global exclusion, to my mind, indicates that the project that declares the global exclusion has made a mistake... they should just fix the mistake, rather than continue to propagate it further

            Not targetted for 3.5.0

            stephenc Stephen Connolly added a comment - Not targetted for 3.5.0
            jonenst Jon Harper added a comment -

            Also, people are actually deploying high availability maven repositories containing only "99-version-does-not-exist" of empty artifacts ( https://www.slf4j.org/faq.html#excludingJCL ) just to get around this problem. This shows how badly this is needed..

            jonenst Jon Harper added a comment - Also, people are actually deploying high availability maven repositories containing only "99-version-does-not-exist" of empty artifacts ( https://www.slf4j.org/faq.html#excludingJCL ) just to get around this problem. This shows how badly this is needed..

            Well of course we have people saying "if you need this feature, you're doing it wrong"... so ok, if a huge number of us maintaining projects in the real world are "doing it wrong", let's discuss how to do it right for a very specific, concrete use case:

            Now first, don't get me wrong, I agree with this statement: If there's a need for a global exclusion, SOMEONE most likely did SOMETHING wrong. The problem is, "someone" isn't always the group that needs the exclusion, and "something" isn't always under that group's control.

            I've found it's very common that an artifact started out with one groupId and later switched to another groupId. Often this is because the original groupId was not good - like we could talk about stax:stax-api:1.0

            But even if the original groupId was a nice "inverted domain"-prefixed identifier, maybe maintenance of the artifact changes hands and the new folks switch to THEIR domain. Whatever. The point is, maven doesn't recognize new.group:artifact:2.0 as conflicting with old.group:artifact:1.0

            Now, did SOMEONE do SOMETHING wrong? Sure, I won't argue about that. But I still have to write a pom that says "I'm using javax.xml.stream:stax-api:1.1 and I don't need/want/have the luxury to tolerate stax:stax-api:1.0 on my classpath"; I'd rather that did not turn into a game of whack-a-mole.

            So, you prefer to provide an artifact aliasing mechanism of some sort instead of global exclusions? Cool, that idea's apparently been under discussion for years; so if you ACTUALLY PROVIDE IT then I'll accept it as a counter to my claim that I need a global exclusion.

            So, have I missed a feature, or are all the explanations of what I should do to solve this problem just talk that I can't use?

            adelsbergerm Mark Adelsberger added a comment - Well of course we have people saying "if you need this feature, you're doing it wrong"... so ok, if a huge number of us maintaining projects in the real world are "doing it wrong", let's discuss how to do it right for a very specific, concrete use case: Now first, don't get me wrong, I agree with this statement: If there's a need for a global exclusion, SOMEONE most likely did SOMETHING wrong. The problem is, "someone" isn't always the group that needs the exclusion, and "something" isn't always under that group's control. I've found it's very common that an artifact started out with one groupId and later switched to another groupId. Often this is because the original groupId was not good - like we could talk about stax:stax-api:1.0 But even if the original groupId was a nice "inverted domain"-prefixed identifier, maybe maintenance of the artifact changes hands and the new folks switch to THEIR domain. Whatever. The point is, maven doesn't recognize new.group:artifact:2.0 as conflicting with old.group:artifact:1.0 Now, did SOMEONE do SOMETHING wrong? Sure, I won't argue about that. But I still have to write a pom that says "I'm using javax.xml.stream:stax-api:1.1 and I don't need/want/have the luxury to tolerate stax:stax-api:1.0 on my classpath"; I'd rather that did not turn into a game of whack-a-mole. So, you prefer to provide an artifact aliasing mechanism of some sort instead of global exclusions? Cool, that idea's apparently been under discussion for years; so if you ACTUALLY PROVIDE IT then I'll accept it as a counter to my claim that I need a global exclusion. So, have I missed a feature, or are all the explanations of what I should do to solve this problem just talk that I can't use?

            What an old issue, but still so actual :-/

            The problem I get in all my maven suites, professional and personal ones, for years, is about slf4j and exclusions of alternate logging frameworks, but I guess this is the general case (seen some tickets about xerces/xercesImpl, this seems lookalike to me).

            What I do now, is "exclusions/exclusion" in dependencyManagement, but it requires to add dependencies in all sub-modules to fix the missing exclusions.

            What I would like is some sort of "patch" on the dependency pom that hurts me, juste once in the maven suite, in the dependencyManagement, for exemple :

            <dependencyManagement>
            <dependencies>
            <dependency>
            <groupId>org.apache.zookeeper</groupId>
            <artifactId>zookeeper</artifactId>
            <exclusions>
            <exclusion>
            <groupId>log4j</groupId>
            <artifactId>log4j</artifactId>
            </exclusion>
            </exclusions>
            <inclusions>
            <inclusion>
            <groupId>org.slf4j</groupId>
            <artifactId>log4j-over-slf4j</artifactId>
            </inclusion>
            </inclusions>
            </dependency>
            </dependencies>

            </dependencyManagement>

            I don't realy care on a new syntax for a possible new format (inclusions/inclusion is just what comes first with existing exclusions/exclusion), compatibility issues may possibly drive to the above proposal, or maybe dependencyPatch, is it this ? whatever, just my actual thoughts on this subject.

            This seems to be a general subject. not just exclusion of some dependencies : idea seems imho to replace/patch dependencies with alternative/native ones, or none at all, AT the <dependencyManagement> level.

            Hope those thougts helped to focus on the "right" side for this ticket.

            mykeul Mickaël Remars added a comment - What an old issue, but still so actual :-/ The problem I get in all my maven suites, professional and personal ones, for years, is about slf4j and exclusions of alternate logging frameworks, but I guess this is the general case (seen some tickets about xerces/xercesImpl, this seems lookalike to me). What I do now, is "exclusions/exclusion" in dependencyManagement, but it requires to add dependencies in all sub-modules to fix the missing exclusions. What I would like is some sort of "patch" on the dependency pom that hurts me, juste once in the maven suite, in the dependencyManagement, for exemple : <dependencyManagement> <dependencies> <dependency> <groupId>org.apache.zookeeper</groupId> <artifactId>zookeeper</artifactId> <exclusions> <exclusion> <groupId>log4j</groupId> <artifactId>log4j</artifactId> </exclusion> </exclusions> <inclusions> <inclusion> <groupId>org.slf4j</groupId> <artifactId>log4j-over-slf4j</artifactId> </inclusion> </inclusions> </dependency> </dependencies> </dependencyManagement> I don't realy care on a new syntax for a possible new format (inclusions/inclusion is just what comes first with existing exclusions/exclusion), compatibility issues may possibly drive to the above proposal, or maybe dependencyPatch, is it this ? whatever, just my actual thoughts on this subject. This seems to be a general subject. not just exclusion of some dependencies : idea seems imho to replace/patch dependencies with alternative/native ones, or none at all, AT the <dependencyManagement> level. Hope those thougts helped to focus on the "right" side for this ticket.

            This is issue is very actual.

            In my case I need to globally  replace guice dependency with guice with  "no_aop" classifer and there is still no easy way to do it

             

            <dependency>
            <groupId>com.google.inject</groupId>
            <artifactId>guice</artifactId>
            <version>4.2.3</version>
            <classifier>no-aop</classifier>
            </dependency>

            Dunemaster Vasiliy Kudriavtsev added a comment - This is issue is very actual. In my case I need to globally  replace guice dependency with guice with  "no_aop" classifer and there is still no easy way to do it   <dependency> <groupId>com.google.inject</groupId> <artifactId>guice</artifactId> <version>4.2.3</version> <classifier>no-aop</classifier> </dependency>
            cbaldan Cleber Baldan added a comment -

            I also feel it would be great if Maven actually had this functionality. I needed this multiple times.

            Right now I'm migrating a large corporate project from log4j to log4j2.

            Multiple dependencies are not updated, and won't be, so I'm using the <exclusion> settings to remove log4j1 and use bridging APIs to handle it.

            But the case is that I have to do the same exclusion in so many dependencies! Plus, pom gets clogged up with the same exclusion over and over.

            With such functionality it would be much easier to tackle these scenarios.

            cbaldan Cleber Baldan added a comment - I also feel it would be great if Maven actually had this functionality. I needed this multiple times. Right now I'm migrating a large corporate project from  log4j  to  log4j2 . Multiple dependencies are not updated, and won't be, so I'm using the <exclusion> settings to remove log4j1 and use bridging APIs to handle it. But the case is that I have to do the same exclusion in so many dependencies! Plus, pom gets clogged up with the same exclusion over and over. With such functionality it would be much easier to tackle these scenarios.
            SR-G Serge added a comment -

            I can confirm that in enterprise context, with big inter-connected projects (and sometimes with old dependencies), this feature is really lacking since the beginning. And that manually handling these exclusions over time is such a nightmare and such a time sink / waste of time. Additionnaly it is something that has to be under constant analysis, as new dependencies, or worst, an upgrade of an old one, may introduce again a dependency that was already excluded everywhere else ... leading to the same issue to be analyzed again (mvn dependency:tree to find the culprit, add the local exclusion, check again, ...).

            In comparison gradle is offering since the beginning some global exclusions, and that's saving a lot of time.

             

            Indeed it's really about handling corner cases, like log4j / slf4j dependencies when you are only relying on log4j2, or excluding some stax api in some situations.

             

            It does not seem insanely difficult to be added inside Maven and it would really be a huge benefit.

            SR-G Serge added a comment - I can confirm that in enterprise context, with big inter-connected projects (and sometimes with old dependencies), this feature is really lacking since the beginning. And that manually handling these exclusions over time is such a nightmare and such a time sink / waste of time. Additionnaly it is something that has to be under constant analysis, as new dependencies, or worst, an upgrade of an old one, may introduce again a dependency that was already excluded everywhere else ... leading to the same issue to be analyzed again (mvn dependency:tree to find the culprit, add the local exclusion, check again, ...). In comparison gradle is offering since the beginning some global exclusions, and that's saving a lot of time.   Indeed it's really about handling corner cases, like log4j / slf4j dependencies when you are only relying on log4j2, or excluding some stax api in some situations.   It does not seem insanely difficult to be added inside Maven and it would really be a huge benefit.
            Arkel Gael SELIG added a comment -

            This feature will be very useful in security context, to remove an unused vulnerable dependency without adding all exclusions one by one.

            Arkel Gael SELIG added a comment - This feature will be very useful in security context, to remove an unused vulnerable dependency without adding all exclusions one by one.
            jrg James Grinter added a comment -

            It would be especially useful given that the dependency:tree command no longer has an option to show every point at which a dependency is being included transitively (third party project dependencies transitively including commons-logging, xerces:xercesImpl, javax.activation, javax.xml.bind, are other common culprits).

            Add exclusion, run mvn dependency:tree, repeat... becomes a slow and tiresome process.

            jrg James Grinter added a comment - It would be especially useful given that the dependency:tree command no longer has an option to show every point at which a dependency is being included transitively (third party project dependencies transitively including commons-logging, xerces:xercesImpl, javax.activation, javax.xml.bind, are other common culprits). Add exclusion, run mvn dependency:tree, repeat... becomes a slow and tiresome process.
            lhoriman Jeff Schnitzer added a comment -

            Guessing I'm not the only one arriving here today looking for a way to globally ensure log4j* doesn't get included in my build. It wasn't, thankfully, but there's always the risk that some future dependency will pull it in.

            This hack seems like it will work? I want an error if somehow I end up transitively pulling in log4j.

            	<dependencyManagement>
            		<dependencies>
            			<dependency>
            				<groupId>org.apache.logging.log4j</groupId>
            				<artifactId>log4j</artifactId>
            				<version>invalid-do-not-use</version>
            			</dependency>
            		</dependencies>
            	</dependencyManagement>
            
            lhoriman Jeff Schnitzer added a comment - Guessing I'm not the only one arriving here today looking for a way to globally ensure log4j* doesn't get included in my build. It wasn't, thankfully, but there's always the risk that some future dependency will pull it in. This hack seems like it will work? I want an error if somehow I end up transitively pulling in log4j. <dependencyManagement> <dependencies> <dependency> <groupId> org.apache.logging.log4j </groupId> <artifactId> log4j </artifactId> <version> invalid-do-not-use </version> </dependency> </dependencies> </dependencyManagement>
            • Normally you only get this as a dependency because it is used somewhere in the code.
            • So probably you need to specify a replacement for the class files somehow.
            • A method I used for years now successfully is to set the scope to provided for the dependency I want to exclude and instead include the replacement in scope runtime. Below snippet is from a company parent pom and as we agreed there to use slf4j for logging only, we include the other stuff during runtime only.
            <dependencyManagement>
                   <dependencies>
                        <dependency>
                            <groupId>org.slf4j</groupId>
                            <artifactId>log4j-over-slf4j</artifactId>
                            <version>${org.slf4j.version}</version>
                            <!-- so libraries  will not include this by chance! -->
                            <scope>runtime</scope>
                        </dependency>
                        <dependency>
                            <groupId>log4j</groupId>
                            <artifactId>log4j</artifactId>
                            <version>1.2.17</version>
                            <!-- by org.slf4j:log4j-over-slf4j -->
                            <scope>provided</scope>
                        </dependency>
                   </dependencies>
            </dependencyManagement>
            
            mfriedenhagen Mirko Friedenhagen added a comment - Normally you only get this as a dependency because it is used somewhere in the code. So probably you need to specify a replacement for the class files somehow. A method I used for years now successfully is to set the scope to provided for the dependency I want to exclude and instead include the replacement in scope runtime . Below snippet is from a company parent pom and as we agreed there to use slf4j for logging only, we include the other stuff during runtime only. <dependencyManagement> <dependencies> <dependency> <groupId>org.slf4j</groupId> <artifactId>log4j-over-slf4j</artifactId> <version>${org.slf4j.version}</version> <!-- so libraries will not include this by chance! --> <scope>runtime</scope> </dependency> <dependency> <groupId>log4j</groupId> <artifactId>log4j</artifactId> <version>1.2.17</version> <!-- by org.slf4j:log4j-over-slf4j --> <scope>provided</scope> </dependency> </dependencies> </dependencyManagement>
            kdekooter Kees de Kooter added a comment -

            I hope this issue will be resolved before my retirement. This baby is allowed to buy alcohol by now.

            kdekooter Kees de Kooter added a comment - I hope this issue will be resolved before my retirement. This baby is allowed to buy alcohol by now.

            People

              Unassigned Unassigned
              kdekooter Kees de Kooter
              Votes:
              161 Vote for this issue
              Watchers:
              127 Start watching this issue

              Dates

                Created:
                Updated: