Support disabling inferred product dependencies

[chrismale]

What happened?

I am trying to migrate a large monorepo away from a very old fork of sls-packaging. For some of the services the inferred product dependencies do not correctly convey the range of support versions. While this is not great, it enables the services to make use of new APIs from jars that maintain backwards compatibility. The enforcement that the newer APIs are only used when the new versions of the dependent services are deployed is enforced at runtime instead.

What did you want to happen?

A given distribution can disable product-dependency inference and instead only uses its explicitly declared product-dependencies. This can be default to false, meaning all other existing consumers are unaffected.

[iamdanfox]

I'm a bit reticent to bring back granular control of product-dependency declarations... this was the state of the world back in the 2.x series of sls-packaging, but we found that people would frequently declare a product dependency that may have been correct at one point, but would quickly become stale and out of sync with the actual method calls.

We did the whole 3.X major rev to get rid of that behaviour and switch to inferring everywhere.

How feasible would it be to fix the embedded product dependencies upstream?

[chrismale]

The situation I have is product A depends on product B where B has both a 1.x and 2.x, with 2.x backwards compatible but also includes new APIs. Migrating all installations of product B to 2.x is happening over time but today 1.x is a valid supported version so the dependency range is min:1.x, max 2.x. Internally product A compiles against the 2.x libraries in order to make use of the new APIs and guards at runtime whether it is taking to 1.x or 2.x of product B. Because product A compiles against 2.x, sls-packaging sets the min:2.x, meaning installations of 1.x are considered invalid.

I can't quite see how to resolve that but open to options.

[markelliot]

On the producer side, consider creating an (additional) api jar that does not embed its product dependency mapping, and in projects where you manage the dependency ranges yourself, depend on the nodep (variant of the) jar.