...
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
...