Add a BOM artifact

[ghost]

In a multi-module project, we want to declare versions in the parent POM, and only the dependencies in the data-access modules. The parent POM looks like (excerpt of the relevant parts):

<project ...>
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>1.5.16.RELEASE</version>
        <relativePath />
    </parent>

    <properties>
        <mybatis-spring-boot.version>1.3.2</mybatis-spring-boot.version>
    </properties>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.mybatis.spring.boot</groupId>
                <artifactId>mybatis-spring-boot</artifactId>
                <version>${mybatis-spring-boot.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>
</project>

However, this approach ends up overwriting Spring Boot 1.5.16.RELEASE dependency management with Spring Boot 1.5.10.RELEASE (because it's imported in mybatis-spring-boot).

A separate BOM artifact for dependency management will solve this problem for multi-module projects, and wouldn't impact mybatis-spring-boot-starter users.

[Edit reason: wrong C&P; the dependency I was referring to is mybatis-spring-boot, not mybatis-spring-boot-starter-test]

[kazuki43zoo]

Could you provide small reproduce project via GitHub or zip file?

[ghost]

Yes, of course: demo.zip To reproduce the problem simply run mvn verify.

As commented in app\pom.xml, 3rd party dependencies are following the dependency management of Spring Boot 1.5.10.RELEASE (instead of 1.5.16.RELEASE):

• spring-* is 4.3.14.RELEASE (instead of 4.3.19.RELEASE),
• jackson-databind is 2.8.10 (instead of 2.8.11.2),
• and quite possibly other dependencies are downgraded too.

[kazuki43zoo]

@nsanchob thanks for your feedback!

At first, you should understand that the mybatis-spring-boot is not designed to be used as a BOM. And we have't a plan to add the BOM sub project as this project at currently.

If you want to use the mybatis-spring-boot as BOM, you can resolve this problem that apply the follow workaround:

<dependency> <!--  Add to import spring-boot-dependencies at before mybatis-spring-boot -->
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-dependencies</artifactId>
  <version>1.5.16.RELEASE</version>
  <type>pom</type>
  <scope>import</scope>
</dependency>

<dependency>
  <groupId>org.mybatis.spring.boot</groupId>
  <artifactId>mybatis-spring-boot</artifactId>
  <version>1.3.2</version>
  <type>pom</type>
  <scope>import</scope>
</dependency>

[ghost]

Thanks!

That's was our first approach. But we are using this POM as a generic parent for projects, and we lose the ability to redefine Spring Boot Dependencies properties to upgrade or downgrade libraries in specific projects.

So at the moment this is our set-up (excerpt of the relevant parts):

<project ...>
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>1.5.16.RELEASE</version>
        <relativePath /> <!-- lookup parent from repository -->
    </parent>
    <properties>
        <!-- == Overriden Spring Boot Dependencies == -->
        <lombok.version>1.18.2</lombok.version>
        <!-- == 3rd party == -->
        <mybatis.version>3.4.6</mybatis.version>
        <mybatis-spring.version>1.3.2</mybatis-spring.version>
        <mybatis-spring-boot.version>1.3.2</mybatis-spring-boot.version>
    </properties>
    <dependencyManagement>
        <dependencies>
            <!-- Spring Boot Support for MyBatis -->
            <!-- Note: import of org.mybatis.spring.boot:mybatis-spring-boot as a BOM
                overrides the dependencyManagement of org.springframework.boot:spring-boot-dependencies -->
            <dependency>
                <groupId>org.mybatis</groupId>
                <artifactId>mybatis</artifactId>
                <version>${mybatis.version}</version>
            </dependency>
            <dependency>
                <groupId>org.mybatis</groupId>
                <artifactId>mybatis-spring</artifactId>
                <version>${mybatis-spring.version}</version>
            </dependency>
            <dependency>
                <groupId>org.mybatis.spring.boot</groupId>
                <artifactId>mybatis-spring-boot-autoconfigure</artifactId>
                <version>${mybatis-spring-boot.version}</version>
            </dependency>
            <dependency>
                <groupId>org.mybatis.spring.boot</groupId>
                <artifactId>mybatis-spring-boot-starter</artifactId>
                <version>${mybatis-spring-boot.version}</version>
            </dependency>
            <dependency>
                <groupId>org.mybatis.spring.boot</groupId>
                <artifactId>mybatis-spring-boot-test-autoconfigure</artifactId>
                <version>${mybatis-spring-boot.version}</version>
            </dependency>
            <dependency>
                <groupId>org.mybatis.spring.boot</groupId>
                <artifactId>mybatis-spring-boot-starter-test</artifactId>
                <version>${mybatis-spring-boot.version}</version>
            </dependency>
        </dependencies>
    </dependencyManagement>
</project>

[hazendaz]

@kazuki43zoo Going to close as what you suggested would be the same even if a bom was used. So long as we state we need spring boot (didn't check) in compile scope rather than provided, that issue would persist. From a maven standpoint, its the order then that matters and anything can be forced into a bom style.

Now to your point initially, the correct thing for mybatis is a bom for all of mybatis. That I think we do need but also need to review our scopes throughout. I can work on getting a bom together, but that probably means we need to release all modules a bit more frequently based off mybatis core so that will be some longer work in pregress before any release.

@joshlong We will look at getting a bom together for mybatis in general separately and review the scopes we have placed on usage throughout.