anchor.diff:  == Initial Situation
   
   === Internal Project Dependencies
  -- frequent changes on patch or minor level for released versions
  -- the trunk of different projects use integration releases
  -- update is maintained manually
  -- small number of projects ( < 20 )
  +- Frequent changes on patch or minor level for released versions
  +- The trunks of different projects are using integration releases
  +- Update is maintained manually
  +- Small number of projects ( < 20 )
   
   === External Project Dependencies
  -- more than 100 dependencies in the platform project
  -- other projects have 25, 11 or none different dependencies
  -- conflicts between internal projects are possible
  -- updates are difficult, because there are a lot of transitive dependencies with conflicts
  +- More than 100 dependencies in the platform project
  +- Other projects have 25, 11 or none different dependencies.
  +- Conflicts between internal projects are possible.
  +- Updates are difficult, because there are a lot of transitive dependencies that may cause conflicts.
   
   == Requirements
   === Product or Internal Project Dependencies
  -- updates of internal should be maintained automatically
  -* based on a branch of the main product the version of the dependencies should be updated automatically and tested
  -* the update must consider the used version of the branch so that the main version always remains stable
  -* the order of versions must be correct handled
  -* it is necessary to support Subversion as well Git
  +- Updates of internal should be maintained automatically.
  +* Based on a branch of the main product the version of the dependencies should be updated automatically and tested
  +* The update must consider the used version of the branch. This ensures that the main version always remains stable.
  +* The order of versions must be handled correctly.
  +* Support of Subversion and Git is mandatory.
   
   .order of the ivy resolver for `1.0.+`
   ----
  
positive.code:         latest: 1.0.1
  ----
  
  - a developer must be able to override these versions easily and reproducibly with a local version
  ** this configuration must be handled in a separate file
  ** the file must not be stored in the VCS, furthermore it must be possible to create a configuration in the VCS, that prevent the storage
  ** the handling should be supported by some helper tasks
  - it must be possible to specify a version of a component or a version of a filter configuration
  - the configuration of internal dependencies must be configured in a separated file
  
  === Standards Filter Formats
  - bom
  
negative.code: - properties
  
  === External Library Dependencies
  - All external dependencies should be maintained in one single configuration.
  ** This dependency management configuration should be handled like any other internal project.
  ** The result of this project should be published via a Maven or an Ivy project.
  ** Other projects should use the dependency management configuration like a filter for versions.
  ** The update of this dependencies should be maintained manually, but supported by some helper tasks.
  ** It must be possible to control the update process.
  *** Updates for all dependencies should be done on the same level (major, minor, patch).
  *** Conflicts must be logged.
  *** A conflict resolution must be configurable.
  - Versions of some libraries do not follow semantic versioning. Nonetheless it must be possible to specify an update rule also for these special dependencies.
  - The dependency management configuration must be deliverable to all customers.
  ** In a customer project, this configuration must also be overwritten.
  ** It should be possible to use other configurations for filtering dependencies with a version.
  -  Updates should be pulled only from configured repositories.
  
  === Questions and Answers - Issues and Discussion
  - What should happen if a dependency with a correct version is specified?
  