Support disabling inferred product dependencies about sls-packaging

[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.