In the simplest use-case for a BOM, it's just very convenient to import it in the dependencyManagement version and be able to depend on any individual netty artifact without declaring a version. That capability by itself is useful and makes sense.

But there's more. Netty may be "zero dependency", but projects a project depends on may depend on netty themselves. This is not only about what netty depends on, this is about making it easy to depend on netty, be it directly os transitively. If you want to properly handle conflicting transitive dependencies in a maven project (and in gradle too, but differently), it's a good idea to use <dependencyManagement>. Imagine you are depending on two artifacts that depend themselves on some random netty artifacts, but you don't know exactly which ones. Maybe they use netty-codec-http, or netty-codec-mqtt, or something else. Therefore, to be safe, you would need to declare in dependencyManagement section all the depended artifacts. It's much more convenient and less error-prone to just import a BOM project.

There is a big list of common projects out there that produce BOMs, no matter if they have a lot of dependencies or not: Jackson, Spring, JAXB, Jersey, AWS SDK, Guice, HK2...

Examples of very useful BOM projects:
http://search.maven.org/#artifactdetails%7Corg.glassfish.hk2%7Chk2-bom%7C2.5.0-b28%7Cpom
http://search.maven.org/#artifactdetails%7Ccom.amazonaws%7Caws-java-sdk-bom%7C1.11.58%7Cpom

About netty-all, it's not a BOM, it's a JAR that comes with everything. In my opinion this is potentially dangerous, because it makes it possible that some of you projects depend on netty-all and some of your projects depend on netty-whatever, and they could be different versions, potentially making your classpath have two versions of same class. Maven can detect that two projects are depending on different versions of netty-codec-http, but it has no way to notice a version conflict between netty-all and netty-codec-http.

As an example, mockito had also a mockito-all and ditched it in latest version because of all the issues it comes with (mockito/mockito#153). In my opinion, netty-all should be used only in build systems with manual dependencies (pure ant, bazel), but not in build systems with transitive dependencies (ivy, gradle, maven). (clarification: mockito-all also had other terrible problems, such as including external jars...).

If you would consider accepting it, I can try to contribute such artifact. It comes with very little maintenance - just add an entry to the BOM project when a new artifact is added.

Uh oh!

Bill Of Materials (BOM) pom #5994

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions