Optionally restrict 'updateReferences' to given projects

[spacehorst]

Currently the updateReferences command sets the given dependency version in all found dependent projects of the universe.
This is a feature request to extend the updateReferences command by a third optional argument where the dependent project(s) to be changed can be listed explicitly.

Rationale:
The full power of semantic versioning and version ranges can only be leveraged, when dependent projects only change their compatibilty version range if it is neccessary. This avoids unneccessary updates of projects only due to changed 'meta data'.

Example:
Assume the following project setup:

project /home/me/workspace/com.inventage.project.library
project /home/me/workspace/com.inventage.project.depending_plugin1
project /home/me/workspace/com.inventage.project.depending_plugin2

library has a current version of 2.2.1
depending_plugin1 requires library with a version range of [1.3.0,3.0.0)
depending_plugin2 requires library with a version range of [2.2.0,3.0.0)
depending_plugin2 has a current version of 4.1.1

Now a new method is introduced in library (compatible API extension) which is only consumed by depending_plugin2. So the new versions should be:

library 2.3.0
depending_plugin1 requires library with a version range of [1.3.0,3.0.0)
depending_plugin2 requires library with a version range of [2.3.0,3.0.0)
depending_plugin2 4.1.2

This should be achieved using the proposed new parameter:
updateReferences com.inventage.project.library ${version:com.inventage.project.library} com.inventage.project.depending_plugin2
incrementBugfix com.inventage.project.depending_plugin2

Thanks for the good work. This project really allows us to use a gitflow-like development process, maven (tycho) based builds and the eclipse / OSGi conventions for runtime modularity all together.

[b8]

Thanks for the suggestion and the flowers! In general, it's been the idea of the 'universe' to define where references are updated. But there are commands missing for easier updating/cleaning the project list in the universe (if it changes in the same batch file).

It seems somewhat strange to only introduce an additional parameter in updateReferences (as you proposed) because, all version commands are updating references in other projects.

Maybe we should be able to give versiontiger some hints in the pom, e.g. more details about dependency ranges.

We'll find a solution...