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.