Many projects these days have a bill of materials (BOM) project that just allows to import all the managed dependencies for a project with a single entry in dependencyManagement.
It would be great to have such BOM in netty.
flozano
All 5 comments
@flozano not sure what you are asking for... isnt it enough for you to import netty-all ?
normanmaurer
on 14 Nov 2016
@normanmaurer
isnt it enough for you to import netty-all ?
No. netty-all is not a bom.
http://howtodoinjava.com/maven/maven-bom-bill-of-materials-dependency/
http://stackoverflow.com/questions/38496022/maven-bom-bill-of-materials-dependency
fenik17
on 14 Nov 2016
I don't think this makes sense at all, Netty is "zero" dependency.
johnou
on 18 Nov 2016
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 (https://github.com/mockito/mockito/issues/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.
flozano
on 21 Nov 2016
normanmaurer
on 1 Mar 2017
Related issues
njhill
路
4Comments
philsttr
路
3Comments
micfra
路
4Comments
isdom
路
6Comments
JuKu
路
4Comments
Most helpful comment
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 independencyManagementsection 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-alland ditched it in latest version because of all the issues it comes with (https://github.com/mockito/mockito/issues/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.