junit-dep and maven: wrong dependency scope

[alexeev]

The junit-dep module has the compile-scope dependency on hamcrest-core lib. I think it's wrong, since the build-in hamcrest-version appears in the classpath and can lead to conflicts. Maven configuration

<dependency>
  <groupId>junit</groupId>
  <artifactId>junit-dep</artifactId>
  <version>4.10</version>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>org.hamcrest</groupId>
  <artifactId>hamcrest-all</artifactId>
  <version>1.2</version>
  <scope>test</scope>
</dependency>

results in Compile- and Runtime- availability of

• junit-dep-4.10
• hamcrest-core-1.1
• hamcrest-all-1.2

It would be better to set the dependency-scope of hamcrest-core to "provided" in the junit-dep module. The Maven configuration above would then result in:

• junit-dep-4.10
• hamcrest-all-1.2

At the moment we help ourself with exclusions as a workaround, in order to get a proper Compile- and Runtime classpath.

[StefanPenndorf]

Thats not an issue of junit, I think. The problem is that hamcrest-all does not declare that it includes hamcrest-core. You should open an issue for hamcrest project.

Setting the scope to "provided" will force all junit users to include/declare an explicit hamcrest dependency. At the moment it is/was possible to use all hamcrest 1.1 matchers without explicitly including hamcrest as test or compile dependency. (maven will automaticall include the transitive dependency to hamcrest).

In my opinion JUnit's maven configuration / pom is absolutely correct.

Btw I couldn't find hamcrest-all in version 1.2 in maven central. See also Issue 12 at hamcrest project. Or maybe you'll file an issue at hamcrest maven integration.

[alexeev]

Setting the scope to "provided" will force all junit users to include/declare an explicit hamcrest dependency.

True. But from my understanding, the junit-dep-Artifact was just
created so that you could explicitly use your own hamcrest jar and
version. For everything else there is a junit-Artifact. Maybe I don't
understand the use-case of junit-dep?

At the moment it is/was possible to use all hamcrest 1.1 matchers without explicitly including hamcrest as test or compile dependency. (maven will automaticall include the transitive dependency to hamcrest).

Why should one use junit-dep-Artifact then?

The problem is that hamcrest-all does not declare that it includes hamcrest-core.

This is also true. I'll contact the hamcrest team.

[stefanbirkner]

The standard junit jar has junit and hamcrest classes, whereas the junit-dep has only junit classes. Therefore the junit-dep is the "correct" maven style junit artifact. See bug #332.

[dsaff]

I'm not well-versed in maven. Has this problem been resolved? Thanks.

[alexeev]

Has this problem been resolved? Thanks.

Yes, I think so. A small summary before we close this issue:

1. The junit:junit-Module is not a conform maven-style artifact. Maven users should always work with the junit:junit-dep artifact instead. See issue 4.9 and 4.10 "junit" artifacts in Maven Central have hamcrest as dependency defined while in "junit" artifact the hamcrest classes are already included #332.

2. The org.hamcrest:hamcrest-all Module is not a conform maven-style artifact. Maven users should work with the new org.hamcrest:hamcrest-library or org.hamcrest:hamcrest-integration instead. See issue 12 in Hamcrest project.

[martinburger]

Shouldn't junit:junit-dep leave out hamcrest? If so, why does junit:junit-dep pull org.hamcrest:hamcrest-core? See http://code.google.com/p/hamcrest/issues/detail?id=166

[Stephan202]

junit:junit-dep does not include (ship with) org.hamcrest:hamcrest-core, it merely declares it a dependency. This is necessary for two reasons:

1. So that the code can be compiled using Maven.
2. In order to ensure that the relevant JAR will be on the classpath at runtime.

Note that this is not a problem, as pointed in the Hamcrest ticket. To reiterate, there are two ways around it: reorder the dependencies and/or explicitly exclude the dependency. Note that the latter still requires one to provide some form of replacement.

[martinburger]

Sorry, of course junit-dep does not ship with hamcrest class files, this is the whole point of that artifact, isn't it?

However, reordering did not help in my case - I am using the Maven Eclipse plugin. Perhaps the observed behavior s related to http://jira.codehaus.org/browse/MECLIPSE-705.

[Stephan202]

Hi Martin,

I had a closer look. It seems that Maven, when confronted with two versions of the same artifact, selects the one with the shortest path to the root. At least, that's how I interpret the following:

Situation 1.

<dependencies>
    <dependency>
        <groupId>org.hamcrest</groupId>
        <artifactId>hamcrest-integration</artifactId>
        <version>1.3.RC2</version>
    </dependency>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit-dep</artifactId>
        <version>4.10</version>
    </dependency>
</dependencies>

[INFO] [dependency:tree {execution: default-cli}]
[INFO] com.fredhopper.tests:junit-helpers:jar:4.7.4-SNAPSHOT
[INFO] +- org.hamcrest:hamcrest-integration:jar:1.3.RC2:compile
[INFO] |  \- org.hamcrest:hamcrest-library:jar:1.3.RC2:compile
[INFO] \- junit:junit-dep:jar:4.10:compile
[INFO]    \- org.hamcrest:hamcrest-core:jar:1.1:compile

Situation 2.

<dependencies>
    <dependency>
        <groupId>org.hamcrest</groupId>
        <artifactId>hamcrest-integration</artifactId>
        <version>1.3.RC2</version>
    </dependency>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit-dep</artifactId>
        <version>4.10</version>
        <exclusions>
            <exclusion>
                <groupId>org.hamcrest</groupId>
                <artifactId>hamcrest-core</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
</dependencies>

[INFO] [dependency:tree {execution: default-cli}]
[INFO] com.fredhopper.tests:junit-helpers:jar:4.7.4-SNAPSHOT
[INFO] +- org.hamcrest:hamcrest-integration:jar:1.3.RC2:compile
[INFO] |  \- org.hamcrest:hamcrest-library:jar:1.3.RC2:compile
[INFO] |     \- org.hamcrest:hamcrest-core:jar:1.3.RC2:compile
[INFO] \- junit:junit-dep:jar:4.10:compile

So I don't think the Maven Eclipse plugin is to blame here.

[martinburger]

Thanks for the hint, you are right. Actually, Maven uses a "nearest-wins strategy", more info about this strategy is available at Resolving conflicts using the dependency tree and Introduction to the Dependency Mechanism.

[marcphilipp]

IMHO the "provided" dependency scope would not be a valid solution because Maven would then not include hamcrest-core unless added as a dependency explicitly. I agree that this is the current use case of junit:junit-dep. However, there shouldn't be two different Maven artifacts for junit (see issue #332). I'm working on relocating junit:junit-dep to junit:junit at the moment.

Summing up, right now the correct way to use JUnit with a Hamcrest version > 1.1 is the following (as pointed out by @Stephan202 above):

<dependencies>
    <dependency>
        <groupId>org.hamcrest</groupId>
        <artifactId>hamcrest-integration</artifactId>
        <version>1.3.RC2</version>
    </dependency>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit-dep</artifactId>
        <version>4.10</version>
        <exclusions>
            <exclusion>
                <groupId>org.hamcrest</groupId>
                <artifactId>hamcrest-core</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
</dependencies>

Of course, this is a little clunky, but you can specify it in the <dependencyManagement> element in your parent POM (see http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html for details).