I wonder what is the best practise for dependency resolution for projects which produce addons for a given third-party system where there is a given set of installed libraries?
The situation is as follows:
- There is some core product (also built with gradle) with around 80 dependencies that is already installed with the version of the libraries the product was developed and tested with.
- There is some addon project that should add some new functionality to the core product with it’s own dependencies (one dependency on the core product and several others)
- the build of the addon project should produce a distribution which contains the generated jar for the addon project along with all the libraries which are required by the addon and are NOT already installed by the core product
I now have the case that if some dependency of the addon has a transitive dependency on an artifact which is already in the dependency tree of the core product (but with a different version), the build produces a dsitribution that also contains this dependent library in the different version. If someone installs that addon to the core system, this will lead to having different versions of the same library in the classpath.
The idea is: mark the dependency to the core system as a kind of “provided” or “pinned” dependency resulting in some kind of “pinning” of all the libraries of this dependency-subtree to the versions required by the core system.
So the resolution should not use newer versions of a dependent library if the versions doesn’t match but fail to indicate that there are some conflict.
So - what would be the best practise for doing such things?