library dependencies in maven. best practices

2019-05-24 06:57发布

I'm writing testing library with my own junit runner. it extends BlockJUnit4ClassRunner which is available since 4.5 till... who knows. user of my library should be able to choose whatever junit version (with BlockJUnit4ClassRunner of course). and i don't know how to define dependency on junit (let's say current version is 4.10).

  • if i make [4.5, 4.10] provided, then i have to release new version with every junit release
  • i'm not sure if [4.5, ) is good a good practise because it implicitly chooses the newest version and build may not be repeatable

e.g. mockito uses ant and junit 4.10 only for compilation and have no maven dependency on it. i also don't know if it's a good practice.

how should i solve this dependency problem

3条回答
啃猪蹄的小仙女
2楼-- · 2019-05-24 07:19

In case you always want to stick to the latest version of junit then use

<version>LATEST</version>

The above will always refer to the latest released or snapshot version of junit.

If you use

<version>RELEASE</version>

then it'll refer to the last released/non-snapshot version present in the repository.

Also there is no issue in declaring an open-ended version range which will include the latest version after x.y.z, i.e.

<version>[x.y.z,)</version>

But things turn sour when there may happen API level changes in the junit world that are incompatible with your artifact. In that sense, it's better to provide an exact version and mandate the client to follow the same.

查看更多
可以哭但决不认输i
3楼-- · 2019-05-24 07:39

The problem with the version markers LATEST and RELEASE they are only supported by Maven 2.2.1 and before but no longer for Maven 3. So the thing is to avoid them.

Furthermore if you define your dependency to JUnit as provided users can use a different version instead of the defined version.

查看更多
小情绪 Triste *
4楼-- · 2019-05-24 07:43

In general, JUnit releases are backward compatible[*]. The developers take great care so that they are backward compatible. One option would be to declare a dependency on JUnit 4.5, and then the user can override that version in their pom (with version 4.10), and it should still work.

If you're doing the above and claiming that it works with all versions after 4.5, then you should be testing with all versions as well, which should be reasonably easy to do.

[*] Classes and methods are deprecated of course, but things should still work.

查看更多
登录 后发表回答