$ mvn clean install

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.teiid</groupId>
            <artifactId>teiid-bom</artifactId>
            <version>1.0.0-SNAPSHOT</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

<parent>
    <groupId>org.teiid</groupId>
    <artifactId>project-bom-parent</artifactId>
    <version>10.0-SNAPSHOT</version>
</parent>

When you want to add or change a dependency X:

1. When adding/changing a dependency and version property, the preferred format for the version property is version.groupId

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

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

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

This BOM has it’s own version numbering and release lifecycle.

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 1.0.x

  • Projects

    • Teiid

    • Teiid-Komodo

Directory project-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 {project-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).

Example: ./run-deps-test.sh teiid-bom