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: 
  https://github.com/nebula-plugins/gradle-dependency-lock-plugin[nebula.dependency-lock]
  
  - A plugin to allow people using dynamic dependency versions to lock them to specific versions.
  
  Unfortunately there is no plugin which match all requirements. There are some good ideas and implementations in these
  plugins, but it is not possible to combine plugins.
  
negative.code: . If the dependency is listed in the dependency filter the version is not used and
  .. an error is thrown.
  .. the version is taken from the filter configuration.
  . In case of a transitiv dependency downstream from a configured dependency with a version that does not match - an error is thrown.
  
  Since all use cases are conceivable options, each should be configurable.
  
  - Which format should be used for lock files and configuration files?
  
  I think JSON format is readable and easy to use.
  
  == Workflow - Automatic Updates for Internal Dependencies
  .  Triggered by new available release versions (check repository for changes)
  .. https://marketplace.atlassian.com/plugins/com.entertainment.bamboo.plugins.httpclient/server/overview
  .. https://marketplace.atlassian.com/plugins/fr.armotic.bamboo.plugins.filedownloader/server/overview
  .. https://marketplace.atlassian.com/plugins/org.gaptap.bamboo.maven.maven-artifact-download-plugin/server/overview
  .. Implement own plugin for Bamboo.
  . Commit changes to VCS, because the change must be used and the build takes more time.
  . An automatic build is triggered due to the change in the VCS.
  . If a build fails a message must be sent to a group of people.
  
  == Development Workflow - Update External Libraries
  . Project with dependency decleration can be used:
  .. For testing dependencies.
  .. Analyzing transitiv dependencies.
  .. The result of this project can be published to a local repository.
  
  . The result from step 1 can be used in the real projects for testing.
  .. The update of this configuration should be supported by special Gradle tasks.
  .. It should be possible to unlock the version in a special file. So that an automatic update is feasible.
  
  . After testing it is possible to use the same configuration for all projects.
  
  