-
Task
-
Resolution: Done
-
Major
-
None
-
None
Move all dependency management under single pom. so it is easy to import all build dependencies provided by WildFly
By doing this we do gain many nice side affects such as
- users can import component-matrix bom of WildFly / WildFly core into their applications if they need for debugging and they will have access to full dependency tree not just public jars / API we provide as part of wildfly-boms
- layered products can easier depend on WildFly / EAP dependencies without importing wildfly-parent which has much more things unrelated to version management
- we get "all compile / test bom" for free
- easier to consume in quickstarts
- it enforcer stricter version management for WildFly build itself, by making sure we only import what we really need, such example is wildfly-arquillian parent that we imported as bom, which means we got also wildfly-core & wildlfly dependencies from previous versions (ones used to build wildfly-arquillian) on testsuite classpath.
- it makes sure that testsuite doesn't existentially consume something it wasn't meant to consume.
- it helps unify boms across upstream and downstream builds.
Going forward we could also split this into few boms, by having build / test / build provided deps separate, or even go step further by having dependency management per feature pack, but that is a list of nice to haves, more than anything else.
- is related to
-
WFLY-10157 version of the modules defined in wildfly core cannot be overrided in wildfly full build
- Closed
-
WFLY-10330 Revert component-matrix change
- Closed