Comments (8)
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.
from javahamcrest.
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.
from javahamcrest.
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
.
from javahamcrest.
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.
from javahamcrest.
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
from javahamcrest.
We will work to decouple JUnit and Hamcrest. See #92
from javahamcrest.
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.
from javahamcrest.
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.
from javahamcrest.
Related Issues (20)
- assertThat(this.object, hasProperty("booleanName")) fails to match boolean types and renames the property HOT 1
- The matcher contains() is misleading HOT 2
- FR: Matching maps with various type HOT 2
- oss-fuzz integration
- Participitation in Hacktoberfest? HOT 1
- HasProperty Matcher doesn't work with Java Records HOT 4
- assertThat(Int::class.java, typeCompatibleWith(Number::class.java)) in kotlin always fails
- hamcrest matching on actual empty list fails with nosuchmethoderror HOT 1
- Test output Alignment
- record version fails the hasProperty HOT 2
- has property fails with non public class.. not sure if this correct as per java standards of property
- Double "close-to" matcher that uses the ULP.
- GraalVM Native Image support HOT 4
- Inquiry about Project Activity and Future Plans HOT 15
- Compatibility in java versions HOT 2
- Upgrade build to JDK 1.8 bytecode HOT 1
- Upgrade to latest Gradle HOT 1
- Publish to Maven Central using GitHub Actions HOT 7
- Hamcrest v3.1
- Hamcrest v4.0
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from javahamcrest.