[
https://issues.jboss.org/browse/WFLY-9911?page=com.atlassian.jira.plugin....
]
Tomaz Cerar updated WFLY-9911:
------------------------------
Description:
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.
was:
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.
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.
Move dependency managment under separate bom
--------------------------------------------
Key: WFLY-9911
URL:
https://issues.jboss.org/browse/WFLY-9911
Project: WildFly
Issue Type: Task
Components: Build System
Reporter: Tomaz Cerar
Assignee: Tomaz Cerar
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.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)