Hi Jeff,

> WildFly-core's root pom acting as BOM and getting imported into WildFly's root pom via dependencyManagement
> to be able to align the shared dependencies, it works good most of the time but has problems[1] on dependencies
> which are used only for testing in wildfly-core but are used in production in WildFly full. Please refer to the
> Jira issue[1] for more detail and context.

I like the idea overall.

Thanks :)

However, I want to better understand the maintenance of that new BOM.
It contains dependencies that are in "test for WildFly core and “runtime” for WildFly.
Past the 3 dependencies that you have identified, how can be keep these dependencies up to date?

If new versions of these 3 dependencies are needed by WildFly core, it can be upgraded in the new test BOM.

Next time, we want to add a test dependency to WildFly Core, we will have to first check if WildFly is already depending on it in ’runtime’ scope. If that’s the case, it will go to that testbom module. Otherwise, it will be added as a regular “test” scope dependency in WIldFly Core.
Is that correct?

For now, it contains 3 dependencies that are used for testing in WildFly core and are used for production in WildFly,

but I think it can include any test dependencies used by WildFly core in the future. An side effect is that for any module

that depends on the new test dependency, it needs to add the following to the moule's pom:

<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.wildfly.core</groupId>
<artifactId>wildfly-core-testbom</artifactId>
<version>${project.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>

Best regards

Lin Gao
Senior Software Engineer
JBoss Sustaining Engineering Team