Gradle
Generate Bill of Material (BOM) with Gradle maven-publish plugin
Simplify the life of your libraries’ clients by providing a Bill of Material
A Bill of Material is a maven dependency that defines a list of libraries with their versions. The goal is to enumerate versions of libraries that work well together.
It’s the SDK developers’ responsibility to test the compatibility between their library versions.
By using a BOM, as a client of these libraries, you avoid compatibility issues so you have fewer tests to do because SDK developers have done.
The BOM dependency contains no code, no resources, only a .pom file with library versions.
Examples of well-known libraries with a BOM
- OkHttp: Java HTTP client (define versions for logging-interceptor, urlconnection…)
- Android Firebase SDK: App development platform (defines all the versions for Crashlytics, Analytics…)
- Jetpack Compose: Modern UI toolkit to develop native UI.
How to create and release a BOM
Where to write the logic
To create and release a BOM, we create a new gradle module. This module only has a build.gradle(.kts) file, nothing else.
We use the publishing task from the maven-publish plugin to publish a BOM.
The publishing task and the declaration of which libraries are in the BOM are in this gradle module.
There are 2 ways to create a BOM:
- By using the java-platform plugin. Works with Groovy DSL and Kotlin DSL.
- By manually writing library versions in the generated .pom file. Works with Groovy DSL. I didn’t succeed in making it work with Kotlin DSL.
Scenario
In the following example, we are a company called MyLittleCompany. This company develops several libraries to easily:
- send events
- manage AB-tests
- manage user authentication
MyLittleCompany provides a BOM to improve the developer experience of its client developers. No more risk of conflict between library versions.
Project structure
All these libraries are in the same project. A library is also called a kit. We have 4 gradle modules:
- event_kit
- abtest_kit
- authentication_kit
- appkits: It’s the name of the gradle module dedicated to the BOM generation and release.
Method 1: Use the java-platform plugin to generate a BOM
- Indicate that you use the java-platform plugin and also the maven-publish plugin.
2. Define libraries that will be in the BOM.
We could define each library we want in the BOM one by one, but here, we prefer to add a small logic to always add all of them (except appkits itself).
Constraints bloc allows to define dependencies with their versions, but these dependencies are only added in the client project if the project defines them.
Api indicates that the dependency will be available during the compilation step.
3. Configure maven-publish plugin to do the release.
Dependencies declared above are added to the component java-platform. We must indicate that the publication will publish this component (L.14).
4. Last step to generate and publish your BOM, execute the following command that will release all modules with the maven-publish plugin setup:
./gradlew publishMethod 2: Manually write library versions in the pom to generate a BOM
- Configure maven-publish plugin to do the release.
2. Now, we can add to the previous code the following lines that override the generated .pom file and injects dependencies information.
3. Last step to generate and publish your BOM, execute the following command that will release all modules with the maven-publish plugin setup:
./gradlew publishHow to use the BOM in your project
In your application build.gradle, you must use the keyword platform to define a BOM dependency.
After that, you don’t have to give a version for the libraries defined in the BOM.
Override a library version (at your own risk!)
If you want to override a library version, you can define it like you usually define a library version. This one will override the one in the BOM.
Conclusion
If you are an SDK developer and your libraries work together and have independent versions, a way to improve developer experience is to provide a bill of material.
We saw 2 methods to do that:
- java-platform: the easiest solution. With very few lines, we can generate a BOM containing the library versions present in the project.
- Manually writing library versions in the pom: Require a little bit more code but allows to declare anything we want in the BOM (because we directly write in the .pom file whatever we want), like a library’s version not present in the project.
No matter which method you choose, in less than 30 minutes, you can significantly improve the life of your clients. You have no reason not to provide a BOM!
