-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Linkage Monitor failed to catch missing transitive dependencies of google-cloud-spanner-jdbc #1831
Comments
I'm not yet convinced it should have caught anything. If the exclusion was at fault, then google-cloud-spanner would not have compiled. The problem is that the sample code was missing a dependency, and linkage monitor never checked that. When google-cloud-spanner removed a transitive dependency it didn't need, the sample broke. This is why projects should declare all their dependencies and not rely on transitive dependencies. |
Google-cloud-spanner is fine. I'm suspecting google-cloud-spanner-jdbc's dependency on it with the exclusions. |
Giving more background. Running LinkageCheckerMain with
This is the very problem we were looking for in GoogleCloudPlatform/java-docs-samples#4278 (comment). On the other hand, LinkageCheckerMain with Google-cloud-bom's Linkage Monitor could have found this if we ran Linkage Monitor differently. |
To file a bug to maven-flatten-plugin. |
Periodic check for the published artifacts? |
|
the flatten plugin works as install phase, "verify" phase might be able to catch this at the library's repository's pull request. |
This is an interesting issue. If you look at however, when a side question is why are these deps (e.g., |
That's an interesting observation. I think the fact that Maven ignores non-direct test-scope dependencies ("test: ... This scope is not transitive.") explain the difference.
If a project uses a class of an artifact, then it's better to declare to the artifact explicitly. "strict deps" in Bazel's term https://github.com/GoogleCloudPlatform/cloud-opensource-java/pull/1767/files#diff-957ff069d393343b026a87ea30d4000884c8cf0ba1622ec861eb6598e034d91eR9
An workaround has been in place : googleapis/java-spanner-jdbc#278 |
Anything linkage monitor needs to do or should we close this? |
Nothing on Linkage Monitor. We may come up with a solution to validate artifacts one by one in future. |
GoogleCloudPlatform/java-docs-samples#4278 (comment)
Linkage Monitor couldn't catch the missing classes because Linkage Monitor checks one big dependency tree that is generated by the list of BOM artifacts. If it would check the artifact one by one, it could detect the missing classes due to the excluded dependencies.
The text was updated successfully, but these errors were encountered: