Debugging notes - PDEPs

[raiju]

While using sls-packaging, we hit some issues. Here are some notes in case they are helpful to guide some fixes in the create manifest logic.

• While working on a PR we got this error: `Differing product dependency recommendations found for '$PRODUCT_DEP' in '$LIBRARY_ONE' and '$LIBRARY_TWO'. Note the lack of information on what the conflict was.
• Some digging later (by attaching a debugger to the gradle process), we realized that while the two libraries are producing compatible PDEPs, LIBRARY_ONE was producing: {min: 1.2.3, recommended: 1.2.4, max: 1.x.x}, while LIBRARY_TWO was producing: {min: 1.2.4, recommended: 1.2.4, max: 1.x.x}
• The code is doing an exact comparison, instead of tracking max/min compatibility
• After going through the documentation, and eventually the code, we realized there is no way to override the decision.
• While trying to understand why it was suddenly failing, we noticed we had added a dependency (that was pulling in LIBRARY_ONE & LIBRARY_TWO) in a service distribution. This same dependency had been pulled in safely into an asset distribution for months. The difference was that while the asset distribution uses the assetBundle configuration to track which PDEPs to check (a configuration we do not use), the service distribution uses the runtime configuration. This means the main reason things worked is that the check is not running in 99% of the cases.

As a personal side-note: I'm a bit nervous about adding a secondary dependency system on top of gradle/maven. To get to a usable degree we'll need tooling (e.g. overrides/excludes, ideally also something like dependencyInsight). If this can be implemented on top of gradle configurations I could see it work (not sure it can handle version range compat checking?), I'd be a lot happier. Otherwise I'm afraid we'll end up with a subpar ad-hoc dependency system.

[jared2501]

Hey @raiju --

When I wrote the prdeps extension I had discussed with @uschi2000 about how to handle the case when a library has dependencies that give conflicting recommendations. We came to the conclusion that, as you hint, that conflict resolution on top of product dependencies is a nightmare. We had instead imagined that we want to avoid handling this situation by encouraging product owners to:

• Ensure that only API jars would contain pdep recommendations. Ideally, there is a bijection between API jar and pdep recommendation.
• Shared libraries should not take API jar dependencies (See Add ability to generate product-dependencies from published recommendations #242 (comment)).
• Therefore, the only source of pdep recommendations should be direct API dependencies from a service's runtime configuration. Gradle will ensure that there is only one version of a jar in the configuration, and therefore only one recommendation for a product.

Obviously, some misbehaved shared libraries can cause the issue you describe. We had discussed cleaning up those shared libraries by having these shared library introducing an interface that could be trivially implemented by a consumer using the API jar, and removing the API jar dependency from the shared library.