Support for bom bill of materials

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.

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

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.

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

@jin

@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.)

+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

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.

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.

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

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

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

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.

consuming one

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.

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.

@aiuto

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

@maven

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.

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

FYI BOM support is about to ship in the upcoming coursier release (2.1.17). Command-line options for it have been added in coursier/coursier#3143, while the core of BOM support has been added by coursier/coursier#3097.

https://github.com/bazel-contrib/rules_jvm_external?tab=readme-ov-file#experimental-support-for-maven-bom-files has support for download Maven BOMs. It uses RJE's custom Maven resolver.

We have not started integration to use Coursier's BOM support yet (#229 (comment)), but if there's interest in it, please let us know.

Navigation Menu

Repository navigation

Support for bom bill of materials #229

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Support for bom bill of materials #229

Description

Activity

jin commented on Sep 17, 2019

rverma-nikiai commented on Sep 18, 2019

mandrean commented on Sep 24, 2019

mandrean commented on Sep 26, 2019

Tony-Proum commented on Jan 8, 2020

nfisher commented on Jun 8, 2020

natewest commented on Oct 8, 2020

joca-bt commented on Jan 19, 2021

elharo commented on Jun 15, 2021

shs96c commented on Jun 15, 2021

shs96c commented on Jun 15, 2021

elharo commented on Jun 15, 2021

jin commented on Jun 22, 2021

aiuto commented on Jul 29, 2022

NathanHowell commented on Jul 29, 2022

jin commented on Jul 29, 2022

shs96c commented on Sep 2, 2022

alexarchambault commented on Nov 7, 2024

jin commented on Jan 13, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions