Provide a Bill of Materials (BOM) artifact

[breun]

The Java Library Best Practices site recommends multi-module projects should publish a Bill of Materials (BOM): https://jlbp.dev/JLBP-15.html

This would make it easier for projects to use AsyncHttpClient artifacts, because they would only need to add a single entry to their dependency management, like this:

<dependencyManagement>
  <dependency>
    <groupId>org.asynchttpclient</groupId>
    <artifactId>async-http-client-bom</artifactId>
    <version>2.10.4</version>
    <type>pom</type>
    <scope>import</scope>
  </dependency>
</dependencyManagement>

[breun]

Note that the effective BOM should not have async-http-client-project as a parent, because async-http-client-project declares dependencyManagement and dependencies that should not be transitively passed on to users of the BOM.

The downside of not being able to use async-http-client-project as a parent is that you cannot use ${project.version} for the version of the artifacts listed in the BOM. One way around this is to use the flatten-maven-plugin

<build>
    <plugins>
        <plugin>
            <!-- This plugins allows using a parent for this file, so project.version can be resolved.
                 A clean BOM without a reference to a parent is generated, so that dependencies cannot
                 interfere with projects that use this BOM. -->
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>flatten-maven-plugin</artifactId>
            <inherited>false</inherited>
            <executions>
                <execution>
                    <id>flatten</id>
                    <phase>process-resources</phase>
                    <goals>
                        <goal>flatten</goal>
                    </goals>
                    <configuration>
                        <flattenMode>bom</flattenMode>
                        <pomElements>
                            <properties>remove</properties>
                            <repositories>remove</repositories>
                        </pomElements>
                    </configuration>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

This allows using async-http-client-project as a parent in the source, but will generate a BOM without a parent reference when building.

[slandelle]

I don't think that's a good idea.
The actual client is the client module that only depends on the netty-utils one, which is transitively pulled.
Extra modules are exactly that: extras that only a few people are likely to use, and people using one are very unlikely to use a second one.
Adding a BOM would make it look like it's the recommended solution, which it really is not as it would add excessive useless luggage in the classpath.

[breun]

A BOM just imports dependency management, so the classpath is not changed by it.

I actually use the extras modules on all projects that I use async-http-client in, so having a BOM would clean up my pom.xml files. Even if my use case is ‘very unlikely’, why not support it?

I would be willing to contribute a BOM module. Or would it be rejected if I created a pull request for it?

[slandelle]

I stand corrected. Yes, please provide a PR, just make sure it doesn't break anything for existing users.

Thanks.