Support for bom bill of materials

[rverma-nikiai]

Maven bom is a way to declare a collection of artifacts with a specific version of each artifact which is recommended to use with another artifact from the same collection.

Consider support for it, maybe in maven_install we can create a target a bom, which specified should allow declaring a versionless artifact. Technically this is not versionless like maven RELEASE/LATEST and it will be a deterministic and idempotent build, the only difference is artifact pinning is happening based on an external definition.

[jin]

Are you blocked by the lack of this feature? Can you still download artifacts you want without BOM support?

[rverma-nikiai]

yes I can download the artifacts by pinning each artifact manually. Although it would be something which I look forward to using in the longer run.

[mandrean]

I'd chime in that I'm also blocked by this!

[mandrean]

@jin

https://github.com/mandrean/rules-jvm-bom-deps/blob/master/WORKSPACE#L18

and

https://github.com/mandrean/rules-jvm-bom-deps/blob/master/src/main/java/se/mandrean/rulesjvmbomdeps/BUILD#L5

(If I use "com.fasterxml.jackson.core:jackson-annotations:2.9.10" instead of "com.fasterxml.jackson:jackson-bom:2.9.10" then obviously it works, but that defeats the purpose of using the BOM.)

[Tony-Proum]

+1 I would like to use a com.google.cloud:libraries-bom and was surprise to see that this was not supported. We were able to retrieve version of all the child libs but I think that it's not ideal

[nfisher]

I think the main benefit of using the BOM is so that you could be explicit about the BOM version and implicit about the version for the direct dependencies inheriting them from the BOM. An example I think that would be useful is something along the lines of:

maven_install(
    imports = [
       "com.google.cloud:libraries-bom:3.4.0",
    ],
    artifacts = [
        "com.google.cloud:google-cloud-storage",
    ],
    repositories = [
        "https://repo1.maven.org/maven2",
    ],
)

Basically all of the imports would be resolved first and where groupID + artifactId is lacking a version it can be pulled from the BOM for direct dependencies. As Tony mentioned this is useful for Cloud provider SDKs as well as projects like Reactor, Spring, etc.

[natewest]

Also blocked by this. The project I am working on regularly generated BOMS with Maven/pom files. There is no equivalent convenient functionality with rules_jvm.

[joca-bt]

+1. When using Spring Boot it's quite common to only declare the Spring Boot version we're depending and import their bom which defines versions for integrated packages. Rarely had to explicitly declare the version of any external packages since we can rely on the bom.

[elharo]

+1 from me too. Is there someone I can talk to internally about the need for this?

[shs96c]

To be clear, is this support for generating a BOM, or for consuming one?

[shs96c]

If it's for consuming a BOM, we need support in coursier (which is the underlying tool we use for dependency resolution). The underlying issue is coursier/coursier#1390 and once that's resolved, we can do an update of coursier we use.

If it's for generating a BOM, we most likely need to add a new rule to allow artifacts to be grouped so we can then generate a meaningful BOM which can be shared across multiple targets. This implies that all those artifacts would be published at the same time.

[elharo]

consuming one

[jin]

If it's for consuming a BOM, we need support in coursier (which is the underlying tool we use for dependency resolution). The underlying issue is coursier/coursier#1390 and once that's resolved, we can do an update of coursier we use.

This is correct; this issue is currently blocked by Coursier support for BOM. Once that is resolved (help is greatly appreciated!), then rules_jvm_external can be integrated with it.

[aiuto]

FYI, the Bazel team has been actively working on the combined problems of precise OSS license attestation, compliance audit, and SBOM generation. The tools will be landing in bazel, rules_license, various repository rules (like jvm external), and bzlmod over the next few quarters.

Since these topics have recently become hot ones, I just created a discussion list: https://groups.google.com/a/bazel.build/g/bazel-slsa

The list is new, so there is no history of posts, much of the thinking was done in docs floated around bazel-discuss or from the proposals repo. I'll be announcing progress and roadmaps on it.

[NathanHowell]

FYI, the Bazel team has been actively working on the combined problems of precise OSS license attestation, compliance audit, and SBOM generation.

@aiuto this issue is about adding support for importing Maven BOMs and using them to pin library versions while resolving version constraints. is this license project related?

https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms

[jin]

Yeah, I'm not sure if this is related. It'll be great if RJE works with these general support of software BOM across projects, but this is related to Maven BOM resolution with Coursier to be exported as @maven dependencies.

[shs96c]

You can now use the maven_bom rule to generate a Maven BOM from a set of java_export targets