Parent and Bill Of Materials for SwitchYard, Drools, OptaPlanner, jBPM, ModeShape, Overlord, …
Align the dependencies of the Integration Platform projects early on in the development lifecycle.
The BOM may be imported into your dependency management, for example a release version or a SNAPSHOT deployed by Jenkins.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.jboss.integration-platform</groupId>
<artifactId>jboss-integration-platform-bom</artifactId>
<version>6.0.0-SNAPSHOT</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
Any dependencies should be placed in the dependency management in jboss-integration-platform-bom. Explicit versions should not be used; instead use a property which should be placed in jboss-integration-platform-parent.
Your project should inherit:
<parent>
<groupId>org.jboss.integration-platform</groupId>
<artifactId>jboss-integration-platform-parent</artifactId>
<version>6.0.0-SNAPSHOT</version>
</parent>
By inheriting the jboss-integration-platform-parent:
-
The properties used by the BOM are visible to the project.
-
It inherits from org.jboss:jboss-parent:10.
-
Any further plugin alignments (e.g. GWT) may be done here.
Discussion mailing list: jboss-integration-platform-developers
Any project lead of the Integration Platform (IP) project can change or release the BOM as he/she sees fit, provided that the following rules have been taken into account:
When you want to add or change a dependency X:
-
Send in a pull request (PR) with the changes you propose.
-
All project leads will review the changes and acknowledge the PR in principle, which means they have the intention to accept the change.
-
A project lead will normally not actually test the changes on his project (as that’s not practical): So he reserves the right to submit a pull request to revert the changes later on.
-
Most projects do not depend on the bom’s SNAPSHOT directly, to avoid sudden surprises. Instead they depend on a released version or on a timestamped snapshot (from this list). They then update their bom dependency’s version frequently, after testing the impact locally.
-
ACK’s are done by commenting on the PR, not on the mailing list.
-
If a project lead (or his deputy) doesn’t acknowledge in reasonable time, chase him for an answer.
-
Any project lead can reject the PR if he gives a good reason.
-
On the master branch, no PR can be rejected due to time concerns (deadlines, no time to review, PTO, …) because any project/product that is about to release should be using the release branch.
-
-
-
After all project leads have acknowledge the PR in principle, merge the changes.
|
Important
|
EAP always wins: The BOM targets a specific EAP version. If that EAP version already depends on X, then the BOM must use the same version as EAP. |
|
Important
|
In the public bom, a dependency version must never end with -redhat-0, -redhat-1, etc. The public bom cannot depend on productization builds, as anyone should be able to build all its dependencies from source. |
|
Note
|
During conflicts, (all things being equal) prefer the latest and greatest version of a dependency in the BOM. |
Dependency exclusions should be avoided, because they cannot be overwritten by child poms.
A dependency exclusion is only allowed to fix an undisputed bug in the dependency’s pom. All IP developers needs to unanimous (undisputed) to keep the exclusion. So as soon as 1 IP developer calls for the removal of an exclusion, he/she can immediately remove it.
The master branch is never released. Release are done from a release branch. The integration platform has multiple projects, but they use the same bom. So there are no parallel release branches. There is only 1 latest release branch.
The release branch names simply increment the minor version number. The correlation between the bom version and project/product versions is below in the section "version mapping".
To mimic a release without pushing any changes:
$ mvn clean install $ mvn release:prepare -DdryRun $ mvn release:clean
To actually release:
$ mvn release:prepare $ mvn release:perform
Then go to Nexus and log in. Find your staging repository, close it and release it.