Publish as a single JAR

[npryce]

Publish to Maven Central as a single JAR file. Do not publish separate hamcrest-api and hamcrest-library JARs.

This will make things easier for client projects and simplify the build.

[josephw]

To avoid conflicting versions of Hamcrest in Maven builds, would you consider continuing to publish hamcrest-core and hamcrest-library artifacts, perhaps empty jars that just exist to depend on the new, unified hamcrest artifact?

I work on a lot of builds that depend on org.hamcrest:hamcrest-core:1.3 both directly and as a transitive dependency of junit:junit. If I upgrade Hamcrest, Maven will ensure that I'm only using a single org.hamcrest:hamcrest-core artifact.

If the new artifact is called something else (org.hamcrest:hamcrest:7.0?) then it will be very common to have builds that include both the old org.hamcrest:hamcrest-core:1.3 and the new org.hamcrest:hamcrest:7.0, unless I specifically exclude the transitive hamcrest-core. This was problematic when junit switched to, and back from, a junit-dep artifact.

[npryce]

If you upgrade to Hamcrest 7, won't you have to add exclusions to JUnit etc? It's a major version bump, so will Maven automatically override dependencies on 1.3 with 7.0? I'd expect a version mismatch between 1.3 and 7.0 to break the build.

[josephw]

will Maven automatically override dependencies on 1.3 with 7.0?

Yes. Maven uses artifactId and groupId (Introduction to the Dependency Mechanism - Transitive Dependencies - "Dependency mediation").

I'd expect a version mismatch between 1.3 and 7.0 to break the build.

I'm assuming that any API used directly by JUnit will be preserved. In that case, my concern is that I can cleanly upgrade projects to 7.0 to without having to exclude every transitive reference to hamcrest-core and hamcrest-library.

[npryce]

Tricky. We can ship empty JARs, but will it actually help? The next release will not be backward compatible (it's a major version bump), so JUnit may just stop working if linked against a Hamcrest version that is not guaranteed to be backwardly compatible.

[erizzo]

What would happen if JUnit specified a version range in its Hamcrest dependency, a range that limited it to less than 2.0 for example, [1.3,2.0.0) ? I don't know what Maven would do if you specified a direct dependency on Hamcrest 2.x and JUnit had such a dependency.
Seems that, whatever Maven does, npryce is correct that at runtime things would blow up since JUnit was written and compiled against an old version that is not compatible with Hamcrest 2.x

[npryce]

We will work to decouple JUnit and Hamcrest. See #92

[josephw]

since JUnit was written and compiled against an old version that is not compatible with Hamcrest 2.x

Ah; I was assuming that you wouldn't be breaking compatibility with JUnit. Hamcrest/JUnit is a fairly popular combination (it's the only way I've seen Hamcrest used) so that may slow uptake of any future Hamcrest releases; I'll keep an eye on #92.

[npryce]

You will be able to use future releases of Hamcrest with JUnit, as long as you use a compatible version of hamcrest-junit and don't use JUnit methods that rely on Hamcrest's types. Since hamcrest-junit will duplicate all functionality in JUnit that relies on Hamcrest, nobody will lose any functionality, but there will be a bit of work to change a project's import statements to bind to hamcrest-junit instead of JUnit.