Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3


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