Maven
  1. Maven
  2. MNG-2315

Add option to exclude all transitive dependencies for a particular one

    Details

    • Type: New Feature New Feature
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.0.4
    • Fix Version/s: 3.2.1
    • Component/s: Dependencies
    • Labels:
      None
    • Complexity:
      Intermediate
    • Number of attachments :
      1

      Description

      Something like

      <dependency>
      ...
      <excludeTransitive>true</excludeTransitive>
      </dependency>

        Issue Links

          Activity

          Hide
          Saminda Wishwajith Abeyruwan added a comment -

          Maven2 is all about dependency management, and transient dependencies are an important part of it. Giving a switch to exclude all the transient dependencies would be an cogent thing to do.

          Having been able to obtain transient dependencies is an powerful feature. With the scenarios we have encountered so far, it has been obvious that a some sort of control over transient dependency is a viable solution.

          If we could restrict that, Maven2 should look for particular depth in the transient tree, rather than all the way down, it would be a much more valuable thing for the users.

          Thus,

          <dependency>
          ...
          <transientDepth>1</transientDepth>

          </dependency>

          Thus, EII transientDepth would contain the depth that the transient resolution framework should look in the transient dependent tree. Value of 1 mean, dependencies in the next level only.

          if transientDepth is 0, it is same as <excludeTransitive>true</excludeTransitive>.

          We know Maven2 rocks and has addressed many of the building issues. Hope we would get a way to control the transient dependencies as well. (What about 2.0.8 )

          Show
          Saminda Wishwajith Abeyruwan added a comment - Maven2 is all about dependency management, and transient dependencies are an important part of it. Giving a switch to exclude all the transient dependencies would be an cogent thing to do. Having been able to obtain transient dependencies is an powerful feature. With the scenarios we have encountered so far, it has been obvious that a some sort of control over transient dependency is a viable solution. If we could restrict that, Maven2 should look for particular depth in the transient tree, rather than all the way down, it would be a much more valuable thing for the users. Thus, <dependency> ... <transientDepth>1</transientDepth> </dependency> Thus, EII transientDepth would contain the depth that the transient resolution framework should look in the transient dependent tree. Value of 1 mean, dependencies in the next level only. if transientDepth is 0, it is same as <excludeTransitive>true</excludeTransitive>. We know Maven2 rocks and has addressed many of the building issues. Hope we would get a way to control the transient dependencies as well. (What about 2.0.8 )
          Hide
          Matthew Smith added a comment -

          While transitive dependencies is what maven is all about and makes it the wonderful tool it is, there are times when those dependencies need a finer grain control. Not every pom is created equal and there are time when it is a good thing to be able to exclude all the dependencies and only include the few that are really required by a specific use case.

          This is of course the exception, but an exceptional tool should be able to handle the exceptional cases.

          Show
          Matthew Smith added a comment - While transitive dependencies is what maven is all about and makes it the wonderful tool it is, there are times when those dependencies need a finer grain control. Not every pom is created equal and there are time when it is a good thing to be able to exclude all the dependencies and only include the few that are really required by a specific use case. This is of course the exception, but an exceptional tool should be able to handle the exceptional cases.
          Hide
          Carlos Garcia Rodriguez added a comment -

          Yep, it will be a very nice feature for some specific situations.

          Show
          Carlos Garcia Rodriguez added a comment - Yep, it will be a very nice feature for some specific situations.
          Hide
          Mike Nereson added a comment -

          I need this. Here is my usecase. I am using an assembly to package the dependencies of my jars into the jar. My web app bootstraps the jars and extracts the dependencies from inside the jar to the web-app's WEB-INF\lib.

          My web app depends on these jars and so includes all of their dependencies. So I have to manually exclude them all. And update that exclude each time any of my modules add a new dependency.

          Show
          Mike Nereson added a comment - I need this. Here is my usecase. I am using an assembly to package the dependencies of my jars into the jar. My web app bootstraps the jars and extracts the dependencies from inside the jar to the web-app's WEB-INF\lib. My web app depends on these jars and so includes all of their dependencies. So I have to manually exclude them all. And update that exclude each time any of my modules add a new dependency.
          Hide
          Brad Lee added a comment - - edited
          Show
          Brad Lee added a comment - - edited I like this idea as well. Useful in the assemblage cases: http://www.sonatype.com/books/maven-book/reference/assemblies-sect-assembling-via-depend.html
          Hide
          Blaine Simpson added a comment -

          Always years behind Ivy for anything to do with dependency specifications.

          Show
          Blaine Simpson added a comment - Always years behind Ivy for anything to do with dependency specifications.
          Hide
          Lo-Tan added a comment -

          I have come across this and found it would be useful as well. The use case for us was all of our projects build normally (EAR + skinny WARs), but when we get to the final deployment, our resulting EAR file contains only the libraries we create. We put all the third party libraries into a shared Java EE library (running WebLogic server) and thus, in the EAR we have to exclude all the transitives from all of our projects It's harsh to have to do it for each and every transitive.

          Show
          Lo-Tan added a comment - I have come across this and found it would be useful as well. The use case for us was all of our projects build normally (EAR + skinny WARs), but when we get to the final deployment, our resulting EAR file contains only the libraries we create. We put all the third party libraries into a shared Java EE library (running WebLogic server) and thus, in the EAR we have to exclude all the transitives from all of our projects It's harsh to have to do it for each and every transitive.
          Hide
          Samuel Langlois added a comment -

          Like the 134 other people who voted for it, I'd love to see this implemented.
          There are quite a few bad poms in Central, especially for old artifacts, and they will be here forever.

          In case you haven't seen it on MNG-3832, a workaround is to use wildcard on exclusion:

          <exclusion>
            <groupId>*</groupId>
            <artifactId>*</artifactId>
          </exclusion>
          

          It works in Maven 3, although it produces a nasty warning about threatened build stability and support in future versions.

          I guess the fix could simply be to remove this warning...

          Show
          Samuel Langlois added a comment - Like the 134 other people who voted for it, I'd love to see this implemented. There are quite a few bad poms in Central, especially for old artifacts, and they will be here forever. In case you haven't seen it on MNG-3832 , a workaround is to use wildcard on exclusion: <exclusion> <groupId>*</groupId> <artifactId>*</artifactId> </exclusion> It works in Maven 3, although it produces a nasty warning about threatened build stability and support in future versions. I guess the fix could simply be to remove this warning...
          Hide
          Robert Balazsi added a comment -

          Ok, I removed the warning messages, please find the patch attached.

          I solved it by updating the DefaultModelValidator class so that its ID_REGEX constant would include the '*' character. Also updated its corresponding unit test, DefaultModelValidatorTest.

          I also find this "<transientDepth>" idea useful and I'm actually planning to implement it. I will provide updates on my progress.

          Show
          Robert Balazsi added a comment - Ok, I removed the warning messages, please find the patch attached. I solved it by updating the DefaultModelValidator class so that its ID_REGEX constant would include the '*' character. Also updated its corresponding unit test, DefaultModelValidatorTest. I also find this "<transientDepth>" idea useful and I'm actually planning to implement it. I will provide updates on my progress.
          Hide
          Robert Scholte added a comment -

          Fixed as part of MNG-3832.
          This means: to exclude all transitive dependencies, specify:

            <exclusion>
              <groupId>*</groupId>
              <artifactId>*</artifactId>
            </exclusion>
          

          This has been added with the first versions of Maven3 due to its implementation by Aether.

          Adding new elements to the pom.xml is tricky, since a lot of tools and frameworks already depend on the current structure of the POM.
          The wildcard construction is just as strong as the suggested element <excludeTransitive/>, without XML Schema changes.

          Show
          Robert Scholte added a comment - Fixed as part of MNG-3832 . This means: to exclude all transitive dependencies, specify: <exclusion> <groupId> * </groupId> <artifactId> * </artifactId> </exclusion> This has been added with the first versions of Maven3 due to its implementation by Aether. Adding new elements to the pom.xml is tricky, since a lot of tools and frameworks already depend on the current structure of the POM. The wildcard construction is just as strong as the suggested element <excludeTransitive/> , without XML Schema changes.

            People

            • Assignee:
              Robert Scholte
              Reporter:
              Carlos Sanchez
            • Votes:
              160 Vote for this issue
              Watchers:
              111 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: