Skip to content

Consider removing io.zipkin.zipkin2:zipkin from zipkin-reporter-bom #274

@wilkinsona

Description

@wilkinsona

IMO, this is somewhere between a bug and a feature depending on how you look at it. Of the choices available, I went with feature. Please let me know if you'd like this to be described differently.

Feature

Provide a bill of materials that only manages modules that are part of this project and that are released and versioned together.

Rationale

It allows the bom to be used without influencing the version of other dependencies that have a separate release cycle.

Example Scenario

I would argue that anyone importing zipkin-reporter-bom will benefit as it avoids unexpected management of io.zipkin.zipkin2:zipkin which is part of a separate project with a separate release cycle.

Prior Art

https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Bill_of_Materials_.28BOM.29_POMs

Imports are most effective when used for defining a "library" of related artifacts that are generally part of a multiproject build. It is fairly common for one project to use one or more artifacts from these libraries. However, it has sometimes been difficult to keep the versions in the project using the artifacts in synch with the versions distributed in the library. The pattern below illustrates how a "bill of materials" (BOM) can be created for use by other projects.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions