I don't think so, because doing so would prevent projects from doing things in the community that product would never use.

For example, ModeShape can be embedded into a JavaSE application where AS7/EAP6/Wildfly do NOT exist. That application might already be using SLF4J, at which point ModeShape can tied into their logging framework. This would never be possible inside our products, so it is irrelevant to the integration BOM.

IMO, the integration BOM should only include those things that will be used by those projects when they are installed/packaged into the platform. For some projects that only run in our app server, there's not much difference. But for other projects that have a lot of capability beyond the EAP integration, the extra stuff in the integration BOM only makes our lives (and those of our users) far uglier.

Test dependencies are even questionable. First of all, test artifacts never go into the platform, but they may get put into the Wolf Maven repository. If two projects depend on different versions of JUnit and they both have some test artifacts to into the Wolf repository, then the Wolf repository would have to include both versions of JUnit. I don't understand how that's a bad thing _other than making the Wolf repository much bigger than ideal.

Now, I would concede that it'd be nice if we all used the same versions of core things like JUnit. But when the integration BOM includes stuff used by one project but not another, it puts an undue burden on the other project's test dependencies. Consider this example:

Project A uses library X version 1.4
Project B doesn't use library X at directly in any of its code, but it has a _test_ dependency on library Y that depends on library X version 1.1.

If the BOM included library X version 1.4, then when Project B imports it, the `dependencyManagement` section defines a dependency for library X version 1.4. Then, when Project B runs a test using library Y, the classpath for the test includes library X version 1.4 and _not_ the version 1.1 that library Y expected. Thus, the test will likely fail with no meaningful message.

This is what @hchiorean  and I call the "transitive dependency problem" of BOMs.

The only thing Project B can do is override the dependency in its POM _and keep it up-to-date as it changes different versions of library Y_. This becomes a maintenance nightmare for Project B, especially when you've got lots of these cases.

Alternatively, if Project B *inherits* from the Integration BOM (which means that properties from the BOM are inherited and can be overridden) then perhaps Project B can simply override that specific property. This still is not ideal, but it is simpler than overriding a dependency.

Also, our users will experience the same transitive dependency problem that we're experiencing, except it will be worse because they're far more likely to bring in other libraries that will conflict (either directly or transitively) with versions specified in the integration BOM.

I understand that the BOM is to help align versions of libraries, but OTOH the more the BOM specifies, the more probable this transitive dependency problem will be. The correct way to do that is to make sure the BOM only specifies those dependencies that go into the platform that are truly common to multiple projects. And that's not even ideal, since Project A and C might depend on library X version 1.4, while Projects B, D, E and F do not yet each might still have to deal with the transitive dependency problem.)

I don't have a solution other than to minimize what the integration BOM contains while also require a lot more coordination between the projects to be sure that when a library becomes needed by multiple projects that it go into the BOM as a single version.

What I do know is that the transitive dependency problem is real with the current approach, that ModeShape is experiencing it now, and that the users of all of our projects will also likely experience it.

BTW, projects should create BOMs that their *users* can import into their Maven projects, but these user-level BOMs should only declare the project's specific modules and let transitive dependencies come in naturally based upon the user's POM. And these user-level BOMs should have no relationship to any parent or integration BOM.