$ mvn clean install

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.jboss.integration-platform</groupId>
            <artifactId>jboss-integration-platform-bom</artifactId>
            <version>7.0.0-SNAPSHOT</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

<parent>
    <groupId>org.jboss.integration-platform</groupId>
    <artifactId>jboss-integration-platform-parent</artifactId>
    <version>7.0.0-SNAPSHOT</version>
</parent>

When you want to add or change a dependency X:

1. Send in a pull request (PR) with the changes you propose.

2. 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.

3. After all project leads have acknowledge the PR in principle, merge the changes.

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.

Releases are done both from master and older branches. The integration platform has multiple projects, but they use the same BOM. There is usually one release branch per major version of EAP.

The release branch names simply increment the minor/patch version number. The correlation between the BOM version and project/product versions is below in the section "version mapping".

This BOM has it’s own version numbering and release lifecycle. Any similarity with Drools, jBPM or SwitchYard versions is a coincidence.

If you release the BOM, bump the hotfix version number.

$ mvn clean install
$ mvn release:prepare -DdryRun
$ mvn release:clean

$ mvn release:prepare
$ mvn release:perform -s <path-to-settings-xml-with-nexus-deploy-credentials> # unless you have those stored in ~/.m2/settings.xml

This section records which project/product versions use which BOM version.

• BOM 7.0.x

  • Projects

    • KIE (Drools, jBPM, OptaPlanner) 7.0

• BOM 6.0.x

  • Projects

    • KIE (Drools, jBPM, OptaPlanner) 6.0, 6.1, 6.2, 6.3, 6.4

  • Products

    • BxMS 6.0, 6.1, 6.2

Directory ip-bom-deps-available-test contains simple Bash script that can be used to verify that all the dependencies declared in <dependencyManagement> are actually available (downloadable). The script uses ip-bom to get list of all dependencies under <dependencyManagement> and then uses that list to create new POM that depends on all of them. Simple dependency:resolve Maven build is executed to make sure all dependencies are available. If there is one or more dependencies not available the build will fail. Following remote repositories are used: Maven Central, JBoss.org Nexus and Red Hat Public Product Repo (for *-redhat-X exceptions).