Add Bill of Materials (BOM)

[mpkorstanje]

A typical problem I see on Stack Overflow is that people use a mismatched set of Cucumber dependencies. This could be avoided by introducing a Bill of Material (BOM) artefact and changing the documentation to reference this BOM.

I would like to see an implementation this BOM. Preferably one that is either automatically generated or used by the project itself to ensure it stays up to date without manual maintenance. A PR that adds a BOM should also update the documentation in Cucumber-JVM and change the cucumber-archetype to use the BOM. Updating the documentation outside of of this project is not required to complete this merge request but listed for completeness:

• https://github.com/cucumber/docs.cucumber.io
• https://github.com/cucumber/cucumber-java-skeleton

An alternative would be to use cucumber-jvm as a BOM. However to avoid the issues from #1900 it should be cleaned from all non essential dependencies which I don't think is feasible.

There are a few styles to implement a BOM:

• A root module as describe by https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
• A module listing the versions of all modules in the project https://search.maven.org/artifact/org.junit/junit-bom/5.7.0-M1/pom
• A module with third party dependencies https://search.maven.org/artifact/org.springframework.boot/spring-boot-dependencies/2.3.1.RELEASE/pom

If possible I'd like to avoid introducing another root module. So the JUnit 5 style seems to be most appropriate. It will avoid introducing non-cucumber dependencies. However unlike JUnit 5, not all io.cucumber dependencies are part of cucumber-jvm. This may require some additional work.

---

A valid conclusion may also be that it's not worth the effort to add a Bill of Materials. A typical project only needs 3 cucumber dependencies. All others are transitive. The typical problem on stack overflow includes everything and the kitchen sink as a dependency.

        <dependency>
            <groupId>io.cucumber</groupId>
            <artifactId>cucumber-spring</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>io.cucumber</groupId>
            <artifactId>cucumber-java</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>io.cucumber</groupId>
            <artifactId>cucumber-junit-platform-engine</artifactId>
            <scope>test</scope>
        </dependency>

[stepio]

With the release of 6.10.0 version I joined the community of people whose project stoped compiling because of dependency resolution error in cucumber.

The problem was solved by defining versions for io.cucumber:cucumber-core & io.cucumber:gherkin.

A valid conclusion may also be that it's not worth the effort to add a Bill of Materials. A typical project only needs 3 cucumber dependencies.

True, but sometimes Maven (and probably Gradle too) still fail to resolve the dependent ones properly.

In my particular case conflict was most probably caused by an additional external dependency de.monochromata.cucumber:reporting-plugin with pretty layout for test reports.

Anyway, BOM does not require you to include all the possible dependencies to the test scope, as you can simply add next block into the <dependencyManagement> section:

<dependency>
  <groupId>io.cucumber</groupId>
  <artifactId>cucumber-bom</artifactId>
  <version>${cucumber-version}</artifactId>
  <type>pom</type>
  <scope>import</scope>
</dependency>

Most of the regular maintenance will be handled by renovate for external dependencies (such as gherkin & messages) & by adjusting your release script for the internal ones.

As a possible option you may like the "separate repository" approach used in Jackson:
https://github.com/FasterXML/jackson-bom
But could be an overkill here.

So voted for this ticket, happy to contribute defining the module with pom - should be relatively easy.

[aslakhellesoy]

I've added a $300 bounty to this issue for whomever contributes a fix that lands this on master. Just send an invoice via the ❤️ Sponsor button at the top :-)

[dcendents]

In my particular case conflict was most probably caused by an additional external dependency de.monochromata.cucumber:reporting-plugin with pretty layout for test reports.

Maven has its own dependency resolution mechanism. In my opinion the reporting-plugin should have defined its dependency on cucumber as optional to prevent this kind of problem.

What I suggest you do is exclude transitive dependencies from the reporting-plugin so it stops messing with your project:

<exclusions>
    <exclusion>
        <groupId>io.cucumber</groupId>
        <artifactId>*</artifactId>
    </exclusion>
</exclusions>

But I still believe a BOM would be a great feature to add.