11:32 a.m.
Hi folks,
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.
There is a PR[2] open to address that problem by introducing a
*testbom* which
contains such dependencies. Any
module depending on such dependencies can add the *testbom* with an import
scope.
The PR tries to move the following dependencies from WildFly-core's root
pom to the new created *testbom*:
- commons-io:commons-io
- com.fasterxml.jackson.core:jackson-databind
- xalan:xalan
Once the PR gets approved, it needs any project depending on
wildfly-core's root pom to check, like adding
the commons-io:commons-io dependency in case of WildFly full[3].
Does anyone see problems with such a move? Thank you !
[1] https://issues.redhat.com/browse/WFLY-14431
[2] https://github.com/wildfly/wildfly-core/pull/4572
[3]
https://github.com/wildfly/wildfly/compare/master...gaol:update_test_depe...
Best Regards
--
Lin Gao
Senior Software Engineer
JBoss Sustaining Engineering Team
9:59 a.m.
New subject: Move some dependencies to a new testbom in wildfly-core
Hi Lin,
On 24 Apr 2021, at 11:32, Lin Gao <lgao(a)redhat.com> wrote:
Hi folks,
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.
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?
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?
Thanks,
Jeff
--
Jeff Mesnil
Principal Software Engineer
Red Hat
http://jmesnil.net/
11:23 a.m.
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
1089
days inactive
1091
days old
2 comments
2 participants
participants (2)
-
Jean-Frederic Mesnil -
Lin Gao