Versions Compared

Old Version 1

changes.mady.by.user Brett Porter

Saved on

compared with

New Version 2

changes.mady.by.user Brett Porter

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Users have expressed the desire to turn off transitive dependencies and/or filter out some dependencies obtained transitively. This design attempts to allow the latter.

Note
title"Undecided"

This design was not agreed on as:

  • we are uncertain whether it is a problem we want get into solving instead of requiring the correction of metadata.
  • the affect of declaring scope=none in dependency management inside the pom of a transitive dependency would mean that it would need to be repeated at each level that wanted to exclude it
  • could cause confusion if a user has used it poorly

Filtering out unwanted transitive dependencies

...

There is one contentious issue: should these filters be transitive?

Arguments in favour:

  • less poms affected (only needs to specified to 1 level, not N)
  • no need to know anything about the dependencies of your dependencies
  • can be specified at a per dependency level, so less potential to be harmful (eg, you block jdbc knowing you don't need it from p-v, but some other dep introduces it too and really does need it)

Arguments against:

  • potential to be harmful (p-v blocks jdbc, but down the foodchain someone uses velocity via p-v and triggers jdbc code)

Design where filters are transitive

Code Block
xml
xml
<dependency>
  <!-- Never use jdbc -->
<groupId>...</groupId>
  ...
  <exclusions>
    <exclusion>
      <groupId>jdbc</groupId>
      <artifactId>jdbc</artifactId>
    </exclusion>
  <scope>none<</scope>exclusions>
</dependency>

The none scope means that the dependency is not resolved, and excluded from all class paths.

...

Reasoning:
  • makes a nice artifact filter for use when transitively resolving that dependency
  • do it per dependency so it is clear where it is coming from and doesn't accidentally filter out elsewhere
  • works for both Maven and Ant tasks
  • Can easily produce a report from the repository showing how it is used/abused
  • normally transitive because if you don't use it, then those depending on you should declare it explictly if they need it, as they're dependency on you only implies they need what you need + what they say they need
  • use it in dependencies to make it transitive. If you want a non-transitive version, it is also available in dependencyMgmt
Design where filters are not transitive
 Code Block
xml
xml

<dependencyManagement>
  <exclusions>
    <exclusion>
      <groupId>jdbc</groupId>
      <artifactId>jdbc</artifactId>
    </exclusion>
  </exclusions>
</dependencyManagement>