Generate @package_metadata info for jvm_import targets
#1410
Conversation
private/dependency_tree_parser.bzl
Outdated
| @@ -84,6 +84,15 @@ def _get_maven_url(artifact_urls): | |||
| # Return anything | |||
| return artifact_urls[0] | |||
|
|
|||
| def _create_purl(coordinates): | |||
There was a problem hiding this comment.
The jvm_import rule exposes the provider directly. We should do the same here.
There was a problem hiding this comment.
I don't think we should: users (companies) will want to override or add some attributes of package_metadata with info they need. They way this will work is that companies can define a toolchain for all the overrides/additions, keyed by the label of the package_metadata target. if we generate PackageMetadataInfo outside of package_metadata, that'll need to integrate with all the override toolchain stuff, which is probably not something I want rules to do.
See bazel-contrib/supply-chain#1 (comment) for a draft how the overrides are going to work
There was a problem hiding this comment.
Won't that happen at the point where people are consuming this data? In your example, the users will be the ones who want to (eg) annotate a dual-licensed project as using one specific license for their use.
private/dependency_tree_parser.bzl
Outdated
| @@ -84,6 +84,15 @@ def _get_maven_url(artifact_urls): | |||
| # Return anything | |||
| return artifact_urls[0] | |||
|
|
|||
| def _create_purl(coordinates): | |||
There was a problem hiding this comment.
Won't that happen at the point where people are consuming this data? In your example, the users will be the ones who want to (eg) annotate a dual-licensed project as using one specific license for their use.
|
Happy to merge this once the already existing |
|
Switched to |
No description provided.