jboss-integration/jboss-integration-platform-bom

Common BOM for projects involved in the Integration Platforms

jboss-integration-platform-bom's Issues

EAP dependencies need to be listed separatly from other-dependencies

Currently the bom looks something like this (the version number are mostly fictional):

<version.org.freemarker>2.7</> // whatever version we want
<version.org.hibernate>3.3</> // 3.3 because EAP target is 6.3-redhat-2 which has hibernate 3.3-redhat-2
<version.org.jfreechart>1.7</> // whatever version we want
<version.org.resteasy>1.3</> // 1.3 because EAP target is 6.3-redhat-2 which has resteasy 1.3-redhat-2
<version.org.weld>2.3</> // 2.3 because EAP target is 6.3-redhat-2 which has weld 2.3-redhat-2
// ... 300 other dependencies

We need to refactor this into:

<!-- EAP 6.3 dependencies -->
<version.org.hibernate>3.3</> // 3.3 because EAP target is 6.3-redhat-2 which has hibernate 3.3-redhat-2
<version.org.resteasy>1.3</> // 1.3 because EAP target is 6.3-redhat-2 which has resteasy 1.3-redhat-2
<version.org.weld>2.3</> // 2.3 because EAP target is 6.3-redhat-2 which has weld 2.3-redhat-2
// ... 100 other dependencies
<!-- Other dependencies -->
<version.org.freemarker>2.7</> // whatever version we want
<version.org.jfreechart>1.7</> // whatever version we want
// ... 200 other dependencies

So we can then extract the "community EAP" bom , like this:

<version.org.eap-bom-community-mimic>6.3</> // 6.3 because EAP target is 6.3-redhat-2 which has hibernate 3.3-redhat-2, resteasy 1.3-redhat-2, weld 2.3-redhat-2
<!-- Other dependencies -->
<version.org.freemarker>2.7</> // whatever version we want
<version.org.jfreechart>1.7</> // whatever version we want
// ... 200 other dependencies

So we get a structure like this:

 ip-bom/pom.xml // imports bom eap-bom-community-mimic
 eap-bom-community-mimic/pom.xml

That way, when productization does a product build of this, they can simply replace the eap-bom-community-mimic with the real EAP bom, instead of replacing all EAP subcomponent versions one by one.

Future ideas

Instead of eap-bom-community-mimic we could also use the wildfly-9 bom. That's a new, separate issue, which depends on completing this issue first.

It implies that our community development targets EE 7 (instead of EE 6) (with Java 7 instead of Java 6). It also means our new community work cannot be productized until WildFly 10 and EAP 7 are out. It also means that backporting from community to product will be very hard because an architecture based on EE 7 diverges a lot from an architecture based on EE 6 (for example CDI 2 instead of CDI 1). For all these reasons, I 'd vote against using the wildfly-9 bom for the foreseeable future.