why dropwizard-bom?

[Brent Ryan]

I was just curious as to why dropwizard moved to using dropwizard-bom + <dependencyManagement> vs. parent pom.xml containing <properties> with versions specified?  It seems like this sorta bypasses the enforcer plugin because <dependencyManagement> is used for everything so I was wondering what the point of enforcer plugin was with this then?

Brent

[Brent Ryan]

Anyone know why?

[Tristan Burch]

I think the advantage of having a bom module is to be able to get all the Dropwizard dependencies managed and then being able to upgrade them all with a single version change (yes, you could use a property, but then you still need to manage the version of the dependencies that Dropwizard depends on). see https://java.awsblog.com/post/TxQPN0AEKT3F48/Managing-Dependencies-with-AWS-SDK-for-Java-Bill-of-Materials-module-BOM

On Sunday, April 10, 2016 at 7:53:18 PM UTC-6, Brent Ryan wrote:

Anyone know why?

[Brent Ryan]

Ya, this all makes sense. I was just curious on why keep the enforcer plugin though because this basically hides all dependencies from that plugin rendering it useless. Unless I'm missing something?

--
You received this message because you are subscribed to a topic in the Google Groups "dropwizard-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dropwizard-dev/9JZJNgTmN-k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dropwizard-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brent Ryan]

I've read a bunch of material on the "bom" pattern, but I still lack to see the benefit over using this vs just having a parent pom.xml file with a <dependencyManagement> section unless you plan on composing this from multiple bom files.  However, in the case of dropwizard it looks like the project always imports only 1 bom file so couldn't all of these dependencies just be in the <dependencyManagement> section of the dropwizard parent pom file?

Maybe this was done with some intent behind it from other dropwizard consumers or something?  Any dropwizard developers around who can answer?

Thanks,

Brent

To unsubscribe from this group and all its topics, send an email to dropwizard-dev+unsubscribe@googlegroups.com.

[Christopher Currie]

The bom is not for the dropwizard project itself, but for end users. As a *user* of dropwizard, the bom is helpful for me because I can import the bom in my own parent pom's dependencyManagement section, without having to individually specify the versions of all of the dropwizard components I may end up using. This is especially convenient as new dropwizard components are added; I simply update the version of the bom that I import, and my parent pom is up-to-date without any additional work on my part. I thank the Dropwizard team profusely for adding this to the build!

To unsubscribe from this group and all its topics, send an email to dropwizard-de...@googlegroups.com.

[Brent Ryan]

That makes sense. However, the dropwizard project also does use this internally and even if you put this in the parent pom of dropwizard there's nothing stopping you from importing the dependencies from there either. Still seems like you could accomplish the same thing using the parent Pom and it would reduce the need to put the dependencyManagement import block in every sub module.

I'm not saying this pattern is bad at all. I'm just trying to understand if there's more to it.

[Christopher Currie]

There's actually a problem with putting the dependencies in the parent pom. Since the BOM has the parent pom as a parent, any dependencyManagement that gets put into the parent pom is also transitively a part of the BOM, which then gets exposed to end users. This issue came up recently in the AWS Java SDK (https://github.com/aws/aws-sdk-java/issues/805).

You received this message because you are subscribed to the Google Groups "dropwizard-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dropwizard-de...@googlegroups.com.

[Brent Ryan]

It makes sense to keep it separate if there are dependency differences between what you want to enforce externally vs internally to the project but it looks like every dropwizard module just imports the bom file anyways. There is like 3 dependencies in the current parent and they didn't seem all that critical. I wonder if it's just left around on accident.