0

I'm currently working on a dbunit extension library. Thus this library depends on dbunit.

I extracted the version as a maven property.

<properties>
    <dbunit.version>2.4.8</dbunit.version>
</properties>

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.dbunit</groupId>
            <artifactId>dbunit</artifactId>
            <version>${dbunit.version}</version>
        </dependency>
    </dependencies>
</dependencyManagement>

This allows me to run the maven build with another dbunit version

mvn test -Ddbunit.version=2.7.3

But it also change the dbunit version that the compiler uses. Thus I test source code compatibility to another dbunit version.

The question I want to answer with my maven build is:

Does my library work normal, as specified by the tests, if I use the library that was build against dbunit 2.4.8 with dbunit 2.7.3 at runtime?

I would like to introduce version ranges so that clients of the library can choose which version they want to use, but to do that I want to test which versions work.

The maven-surefire-plugin allows me to add additional classpath entries. But only if I know the path of a lib. I would like to use the GAV (group artifact version) format.

How can I solve this? Do you know another plugin that can handle such cases.

René Link
  • 48,224
  • 13
  • 108
  • 140
  • You can run your tests in a different module, which has the compiled module as a dependency. In the test module you can use the other version of dbunit. – tgdavies Apr 29 '22 at 12:25
  • Good idea that pointed me to the right direction. I used the maven-invoker-plugin. Hope I will find time to post my own answer here soon. For now I will just link the repo here [dbunit-extensions on github](https://github.com/link-intersystems/dbunit-extensions) – René Link Apr 29 '22 at 14:43
  • First I would suggest not to introduce version ranges. Furthermore you should define the dependency as a provided scope. – khmarbaise Apr 29 '22 at 16:42
  • @khmarbaise That's a good suggestion. I guess you mean the problems that can arise with snapshot dependencies and version ranges. I removed the version range. I also figured out that the dependency mananagement is enough. If I put the version in the dependency management it is overridden by the client pom's dependency management version. Thus I don't need version ranges, nor set it provided. – René Link May 01 '22 at 08:47

0 Answers0