Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a bill of materials (BOM) #2321

Closed
realdadfish opened this issue Jun 10, 2021 · 16 comments
Closed

Provide a bill of materials (BOM) #2321

realdadfish opened this issue Jun 10, 2021 · 16 comments

Comments

@realdadfish
Copy link
Contributor

realdadfish commented Jun 10, 2021

I figured that the number of Mockito artifacts grows, so it might be useful to provide a BOM (Bill Of Materials) that lists all versions of all artifacts in a central place.

Such a thing could then be consumed in a Gradle multi project build through

// my.platform.project:test
plugins {
    id("java-platform")
}

dependencies {
    api(platform("org.mockito:mockito-bom:$someVersion"))
}

and this could be referenced in individual module files like so:

dependencies {
    testImplementation(platform("my.platform.project:test"))

    testImplementation("org.mockito:mockito-core")
    testImplementation("org.mockito:mockito-junit-jupiter")
}

Creating and publishing such a BOM should be fairly easy. Thanks!

@realdadfish
Copy link
Contributor Author

On a related note, sister projects like https://github.com/mockito/mockito-testng, https://github.com/mockito/mockito-scala or https://github.com/mockito/mockito-kotlin have a different versioning scheme, but all depend on a specific mockito version internally. If there is such a thing as compatibility, it might be useful to list the versions of those particular libraries in the BOM as well, to provide some kind of "tested set" of Mockito utilities for different languages.

@TimvdLippe
Copy link
Contributor

I am not intimately familiar with a BOM file, but if it is relatively easy to generate and helps users in certain situations, I guess we could. Could you submit a PR?

@realdadfish
Copy link
Contributor Author

I can easily come up with an automated way of creating such a BOM based on the current Gradle configuration, however I'm not familiar with the background of the mentioned side projects. If the BOM could / should list more than Mockito's very own artifacts for compatibility reasons, one would go down a different route and compile the BOM differently. Or would you say that if we start with Mockito's own artifacts this would suffice all users (again, I'm not aware of compatibility issues between the aforementioned subprojects, but of course there could be some).

@TimvdLippe
Copy link
Contributor

The side projects have a different release cadence and version scheme, so I don't think we should include these in the mockito-core BOM. The artifacts that are versioned together are:

  • mockito-core
  • mockito-inline
  • mockito-android
  • mockito-junit-jupiter
  • mockito-errorprone

@realdadfish
Copy link
Contributor Author

Ok, understood. I just asked because all of these projects themselves depend on a specific version of "mockito-core", so if they're used in conjunction with plain Mockito dependencies from the BOM, they render the version pinning aspect of it kind of useless. E.g. a user that creates a dependency graph like this

testImplementation(platform("org.mockito:mockito-bom:3.11"))
testImplementation("org.mockito:mockito-core")
testImplementation("org.mockito:mockito-kotlin:<some-version>")

would get it's "mockito-core" dependency silently overridden by "mockito-kotlin" if this specifies another (higher) version of "mockito-core", unless the user specifies

testImplementation(enforcedPlatform("org.mockito:mockito-bom:3.11"))

instead, which would downgrade whatever "mockito-kotlin" would depend on, eventually introducing compatibility issues / bugs.

But anyways, I'd follow your lead here, I just wanted to make clear what I meant :)

@TimvdLippe
Copy link
Contributor

Ah I see. Yes mockito-kotlin is free to use its own versioning scheme, so we can't guarantee they would use the same version.

Does that mean the value proposition of a BOM file is low and maybe therefore not worth doing? 😢

@pzygielo
Copy link
Contributor

Does that mean the value proposition of a BOM file is low and maybe therefore not worth doing?

As the user - I'd like to use BOM to manage listed modules sharing release lifecycle, in one import in maven project.
I can't offer help to actually do it, but should it exist - I'm sure plenty of projects would benefit from it.

@realdadfish
Copy link
Contributor Author

Does that mean the value proposition of a BOM file is low and maybe therefore not worth doing?

Well, one can obviously already start with it anyways. If more modules are added in the future, the situation for users will only get better. And maybe one day the other projects will chime in as well and have their versions fixed in cadence of the "mothership" project, so I'd probably still do it.

@TimvdLippe
Copy link
Contributor

Okay, that sounds good to me. I am happy to review a PR that introduces a BOM file for the artifacts listed in #2321 (comment)

@realdadfish
Copy link
Contributor Author

realdadfish commented Jun 11, 2021

Done, this is what it looks like:

<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.mockito</groupId>
  <artifactId>mockito-bom</artifactId>
  <version>3.11.1-SNAPSHOT</version>
  <packaging>pom</packaging>
  <name>mockito-bom</name>
  <description>Mockito Bill of Materials (BOM)</description>
  <url>https://github.com/mockito/mockito</url>
  <licenses>
    <license>
      <name>The MIT License</name>
      <url>https://github.com/mockito/mockito/blob/main/LICENSE</url>
      <distribution>repo</distribution>
    </license>
  </licenses>
  <developers>
    <developer>
      <id>mockitoguy</id>
      <name>Szczepan Faber</name>
      <url>https://github.com/mockitoguy</url>
      <roles>
        <role>Core developer</role>
      </roles>
    </developer>
    <developer>
      <id>bric3</id>
      <name>Brice Dutheil</name>
      <url>https://github.com/bric3</url>
      <roles>
        <role>Core developer</role>
      </roles>
    </developer>
    <developer>
      <id>raphw</id>
      <name>Rafael Winterhalter</name>
      <url>https://github.com/raphw</url>
      <roles>
        <role>Core developer</role>
      </roles>
    </developer>
    <developer>
      <id>TimvdLippe</id>
      <name>Tim van der Lippe</name>
      <url>https://github.com/TimvdLippe</url>
      <roles>
        <role>Core developer</role>
      </roles>
    </developer>
  </developers>
  <scm>
    <url>https://github.com/mockito/mockito.git</url>
  </scm>
  <issueManagement>
    <system>GitHub issues</system>
    <url>https://github.com/mockito/mockito/issues</url>
  </issueManagement>
  <ciManagement>
    <system>GH Actions</system>
    <url>https://github.com/mockito/mockito/actions</url>
  </ciManagement>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.mockito</groupId>
        <artifactId>mockito-android</artifactId>
        <version>3.11.1-SNAPSHOT</version>
      </dependency>
      <dependency>
        <groupId>org.mockito</groupId>
        <artifactId>mockito-errorprone</artifactId>
        <version>3.11.1-SNAPSHOT</version>
      </dependency>
      <dependency>
        <groupId>org.mockito</groupId>
        <artifactId>mockito-inline</artifactId>
        <version>3.11.1-SNAPSHOT</version>
      </dependency>
      <dependency>
        <groupId>org.mockito</groupId>
        <artifactId>mockito-junit-jupiter</artifactId>
        <version>3.11.1-SNAPSHOT</version>
      </dependency>
    </dependencies>
  </dependencyManagement>
</project>

realdadfish pushed a commit to realdadfish/mockito that referenced this issue Jun 11, 2021
xuelin2020 pushed a commit to xuelin2020/mockito that referenced this issue Dec 28, 2021
…o#2323)

Co-authored-by: Thomas Keller <thomas.keller-extern@deutschebahn.com>
@TimvdLippe
Copy link
Contributor

FYI this artifact is now available at https://repo1.maven.org/maven2/org/mockito/mockito-bom/

@pzygielo
Copy link
Contributor

Confused, #2321 (comment)

  • mockito-core
  • mockito-inline
  • mockito-android
  • mockito-junit-jupiter
  • mockito-errorprone

but there is unlisted earlier

  • mockito-proxy

Is mockito-core not managed intentionally?

@TimvdLippe
Copy link
Contributor

@realdadfish probably knows best, but if we were to add mockito-core to the BOM, I think we would have to add api(project.rootProject) to

constraints {

@famod
Copy link

famod commented Jan 24, 2022

Just wanted to switch to the new BOM in Quarkus and was equally confused by missing mockito-core.

@TimvdLippe
Copy link
Contributor

I think that makes sense and we can publish a patch release to include it. Can anybody send us a PR with the fix (most likely the fix in #2321 (comment) should work) and verify that indeed fixes the issue?

@TimvdLippe
Copy link
Contributor

Mockito 4.3.1 is being published to Maven Central and should be available later today: https://github.com/mockito/mockito/actions/runs/1746133222

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants