Issues

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.

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)
• more of the information is likely to be in the repository, so we can report on it (more mid poms than end poms in the repo)
• doesn't make the assumption that an optional dependency is wrong
• its more like what users want, which means less re-education

Arguments against:

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

Use cases

velocity's inclusion of jdbc

velocity requires jdbc for it's jdbc resource loader. If you are not using the resource loader, you don't need jdbc.

plexus-velocity depends on velocity - should it expose the jdbc resource loader (and hence jdbc dep) to dependees, or should it hide that, and make dependees introduce a velocity dep if they use the jdbc resource loader?

jpox inclusion of oracle's jdbc driver

jpox requires this for clob support. modello generates a jpox store but does not use clobs, so that code will never be touched. Should all modello dependees filter out ojdbc, or should modello-plugins-jpox filter it out?

betwixt's inclusion of beanutils

betwixt requires digester to do its parsing. In some instances, it also requires beanutils. However, I recently changed some code in the m1 project loading and realised the portion of betwixt I am using did not need beanutils at all. If mevenide was to depend on the m1 project loading, it would have no knowledge of the use of betwixt - should it receive the beanutils dep?

Design where filters are transitive

<dependency>
  <groupId>...</groupId>
  ...
  <exclusions>
    <exclusion>
      <groupId>jdbc</groupId>
      <artifactId>jdbc</artifactId>
    </exclusion>
  </exclusions>
</dependency>

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

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