Release Version 2.1 On Maven #224
Comments
|
I think this is a great idea. It's been far too long since releases. I plan to try and do this myself over the next couple of weeks. @hamcrest/hamcrest-java-devs: looking at the shiny new Hamcrest Distributables page, there are 5 jars mentioned. I can see the code for |
|
I tried to collapse everything into one jar. We don't need the generator any more as we've stopped doing the code generation for the Matchers class. There's still a decision about whether to have separate jars for the test framework integrations as they're outside the JDK. Might make life easier for dealing with junit 4/5 and other test frameworks. |
|
Thanks @sf105. The test frame integration classes do not appear to be checked into this github repository. Do you have them somewhere else? |
|
I found the java files on the old Google Code repo: https://code.google.com/archive/p/hamcrest/source/default/source I'll see if I can import them into GitHub this weekend. |
|
@hamcrest/hamcrest-java-devs: I've just landed #228, which is preparing the Gradle build for reproducing the various jars as per the 1.3 release. Included in this change: I've set the version to Are there any objections to calling the next version |
|
@tumbarumb Using 1.4 for new version will create same confusion which to use 1.3.x.x or 2.x.x.x. So lets |
|
it's worth talking about exactly what artefacts we want to publish in the next release. I've just created a new pull request (#229) to bring back
One question I have is whether we should keep the existing 4 artefacts (core, library, integration and all), or remove core and library, replaced by When (or if) we do remove |
|
I'd like to collapse all the artefacts. It turns out there's really no point to the division, it's just confusing and complicated. There should be exactly one jar for all the matchers with no dependencies outside the JVM (except junit for testing it). The confusion with java-hamcrest is that was a failed attempt at major new version. I recommend that we do minor version changes into |
|
I really like the idea of having an artefact called I'm not sure about Thoughts? |
|
I've tweaked PR #229 with a new proposal: 2 artifacts: |
|
I've been making a bit of progress on the release, but there are still some things to do:
I have created a request on OSSRH to allow me to publish the artifact (https://issues.sonatype.org/browse/OSSRH-44320). @sf105, can you please comment on that JIRA to authorise that change? What have I missed. Anything else important? |
|
I've just closed issue #183, as I think the new release should resolve all the concerns raised there. As a summary, here's what I'm thinking about at the moment for the next release:
|
|
sounds good, any ETA for the release ? |
|
Very Soon Now™ I'm actually wondering if we should publish a release candidate (RC1) build first. Give people a chance to kick the tyres. |
|
Yes. That's a good idea. |
|
@sf105, @npryce or @scarytom : could one of you please take a leisurely stroll along to https://issues.sonatype.org/browse/OSSRH-44320 and put a comment along the lines of "tumbarumba has permission to publish to org.hamcrest" (similar to what happened at https://issues.sonatype.org/browse/MVNCENTRAL-554). If I can get permissions in time, I'll try and put a new RC build out this weekend. |
|
Done!
…On Fri, 23 Nov 2018 at 18:16, Joe Schmetzer ***@***.***> wrote:
@sf105 <https://github.com/sf105> or @npryce <https://github.com/npryce>
: could one of you please take a leisurely stroll along to
https://issues.sonatype.org/browse/OSSRH-44320 and put a comment along
the lines of "tumbarumba has permission to publish to org.hamcrest"
(similar to what happened at
https://issues.sonatype.org/browse/MVNCENTRAL-554).
If I can get permissions in time, I'll try and put a new RC build out this
weekend.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#224 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AADbm2JVxWHvo_2sIaDXPccjk5f0sHQLks5uyDuBgaJpZM4YNxB2>
.
|
|
Thanks Nat! I've just pushed out hamcrest-2.1-rc1.jar. I doesn't look like Maven Central has synced it yet. I'll send out a note to the mailing lists when it comes through. |
|
So... first experience report of using 2.1-rc1... I tried it on my project at work. It's an Apache Flink pipeline, with the tests using (among other things) JUnit 4.12, Mockito, Spock, and Flink Spector. What I found was that in this particular example, the hamcrest-core-1.3.jar was still pulled in as a dependency through a lot of different transitive paths. It turns out that a lot of stuff depends transitively on JUnit 4.12 (which transitively depends upon hamcrest-core), Mockito depends directly on hamcrest-core. I ended up having to do a lot of tweaks to my Gradle dependencies to get it to work. For example, my old test dependencies looked like this: dependencies {
testCompile 'io.flinkspector:flinkspector-datastream_2.11:0.8.4',
'junit:junit:4.12',
'org.hamcrest:hamcrest-library:1.3',
'org.mockito:mockito-core:1.10.19',
'org.spockframework:spock-core:1.1-groovy-2.4'
}After upgrading Hamcrest, and adding in the excludes to avoid adding hamcrest-core-1.3.jar to the classpath, I had to do this: dependencies {
testcompile 'org.hamcrest:hamcrest:2.1-rc1'
testCompile('io.flinkspector:flinkspector-datastream_2.11:0.8.4') {
exclude group: 'org.hamcrest'
}
testCompile('junit:junit:4.12') {
exclude group: 'org.hamcrest'
}
testCompile('org.mockito:mockito-core:1.10.19') {
exclude group: 'org.hamcrest'
}
testCompile('org.spockframework:spock-core:1.1-groovy-2.4') {
exclude group: 'org.hamcrest'
}
}Needless to say, I think is is probably very error prone, and don't think this looks very nice. I hate to think what it would look like in Maven. I wonder if there's a more seamless way to allow someone to upgrade Hamcrest, and allow other third-party libraries to automatically get the new version, too. The problem at the moment is that I've given the 2.1-rc1 library a different name, so it doesn't actually get involved in version conflict resolution with the 1.3 jars. One possible solution that comes to mind: we publish new poms for What do people think? |
|
So I take it the Hamcrest people aren't coordinating with the JUnit people? If JUnit depends on a Hamcrest library, and Hamcrest tries to refactor the packaging completely independently from what the JUnit people do, it will just be a mess. Here is an idea, though: Maven will take the latest version of any transitive dependency declared in the POM. Currently I just want a newer version of That way I can switch from using |
|
Thanks @garretwilson. The JUnit 4 team chose to pick up hamcrest-core as a dependency, and talked about using For the Java Hamcrest 2.1 release, I'm proposing we completely remove However, the intent was to make a clear statement that the packaging had changed, and giving it a different name was a way to make this explicit. Looking back at the 2.1-rc1 release again, where there is no configurations.all {
exclude group: 'org.hamcrest', module: 'hamcrest-core'
exclude group: 'org.hamcrest', module: 'hamcrest-library'
}That way, I don't have to butcher all the other dependency declarations. I don't have any handy Maven pom based projects to try, though I'm curious to hear about other peoples' experiences. What about other build tools? Is it very hard to make the change? |
|
interesting ideas. Could we upgrade |
|
It would be easy enough to create a pom-only artefact for Unless someone is aware of any major problems with this approach, I can try this in an rc2 release in the next couple of days. |
Yes, I agree this is a great approach in theory. The existing JUnit dependency on The ideal solution in that case is to contact the JUnit people and have them release one more version of JUnit 4 with a dependency on your new Hamcrest-with-a-different-name. Any chance of that happening? With @sf105 's idea, it seems you would doing both: issuing a new Hamcrest naming convention, and releasing drop-in "aliases" that would override JUnit's transitive dependencies. I suppose that would work, but if a "clear statement" is what you want… wouldn't this just cause confusion for those who haven't read this thread—more confusion than just making If the Hamcrest response is that "we can document all this on some page", history indicates that this isn't likely to happen (see #183). And after all, wouldn't be easier to document the new contents of Lastly, aren't most people likely to use Hamcrest with JUnit, in which case they'll need to use the "alias" My purpose here is not to argue; rather I'm just trying to lay out all the options and their consequences so you can make an informed decision. |
|
Thanks @garretwilson, I appreciate you helping us clarify the various points of view. Let me try to summarise the various positions, as I understand them right now. What have I missed? Are there other options? Option 1
We create a new jar called Option 1 Implications
Option 2
We merge all the code from Option 2 Implications
|
That was news to me, and I've been using Maven a very long time. Then again it makes sense, because they are both transitive dependencies at the same level, but I don't think I've seen this specific situation. I'm not sure I would want to rely on the order of declaration, though; that sounds a little brittle. I personally might stick to just declaring But it's an interesting consideration; thanks for pointing this out. |
|
Can I suggest the following:
- Adding the standard maven and gradle dependency instructions?
- Explain the upgrade cases:
-- hamcrest-all -> hamcrest?
-- hamcrest-library and hamcrest-core -> hamcrest?
Other than that my upgrades revealed to me how far the 2015 release of
hamcrest was behind master. Upgrading from 1.3 the following have simply
been deleted without deprecation. This is mean as it doesn't explain to the
casual user how to upgrade.
- IsCollectionContaining -> IsIterableContaining
- IsArrayContainingInOrder removed -> ArrayMatching
Other breaking API changes with generics
- IsA changed parameter type capture, suggest moving to "any"
On 29 Nov 2018 18:36, "Joe Schmetzer" <[email protected]> wrote:
I've just release version 2.1-rc3 to resolve the problem with maven
transitive dependency resolution.
I'd be interested in hearing feedback from folks who have tried this in
Gradle, Maven, or any other dependency management tool out there.
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
<#224 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAQK0N2p_SlInjtWLJR_bi-FEj8g_S-tks5u0CkQgaJpZM4YNxB2>
.
|
|
Thanks @olibye. I've made a start at a pull request to describe some of the concerns (#PR #237). I don't think it's quite ready yet, but the distributables page can be previewed at https://tumbarumba.github.io/JavaHamcrest/distributables Regarding the breaking changes, I didn't realise there were those ones until you mentioned them (though it should have been obvious in retrospect). This release was supposed to be more like a 1.4 release (increment minor version with no breaking changes). I only chose 2.1 because 2.0.0.0 had been accidentally released a few years back, and I thought we needed a clear statement that the version we're releasing now is newer. For I'm not sure what you mean by |
|
I mean Matchers.isA and Is.isA.
It used to be <T> Matcher<T> isA(Class<T> type)
It's now <T> Matcher<T> isA(Class<?> type)
Eclipse is over fussy about this but it can be easily changed to
Matchers.any(Class<T> type)
…On Mon, 3 Dec 2018 at 23:05, Joe Schmetzer ***@***.***> wrote:
Thanks @olibye <https://github.com/olibye>. I've made a start at a pull
request to describe some of the concerns (#PR #237
<#237>). I don't think it's
quite ready yet, but the distributables page can be previewed at
https://tumbarumba.github.io/JavaHamcrest/distributables
Regarding the breaking changes, I didn't realise there were those ones
until you mentioned them (though it should have been obvious in
retrospect). This release was supposed to be more like a 1.4 release
(increment minor version with no breaking changes). I only chose 2.1
because 2.0.0.0 had been accidentally released a few years back, and I
thought we needed a clear statement that the version we're releasing now is
newer.
For IsCollectionContaining and IsArrayContainingInOrder, it should be
possible to re-create the original classes, but deprecate them in favour of
the new classes. We can remove them if we get around to a 3.0 release.
I'm not sure what you mean by IsA. Which class is that?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#224 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAQK0C08R2u4w78Hm9F_8R1NmvLAonP3ks5u1a4lgaJpZM4YNxB2>
.
|
|
From what I remember, the trouble is that it's not always the case that the type being checked is the same as the type of the matcher. And, AFAIR, Intellj is fussy in the opposite direction. I lost years of my life to Java's half-baked generics. |
|
Interesting discussion! I'm certainly glad that Hamcrest is still alive. 🙂 Have you considered publishing a pom-only artifact that uses relocation instead of publishing empty jars? |
|
Ooh, I didn't know about relocation! Thanks, @marcphilipp! I think that's exactly what we were looking for. I tried to RTFM, but didn't quite hit upon the right search terms. I might try a few experiments, and see if it's worth releasing another rc. |
|
So, I played around with using the pom relocation feature. I couldn't get it to work. Here's what I tried... I created this <project>
<modelVersion>4.0.0</modelVersion>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-core</artifactId>
<version>2.1-SNAPSHOT</version>
<packaging>pom</packaging>
<name>Hamcrest Core</name>
<distributionManagement>
<relocation>
<artifactId>hamcrest</artifactId>
</relocation>
</distributionManagement>
</project>Then, in a different project, I tried adding a dependency on <project>
<modelVersion>4.0.0</modelVersion>
<groupId>org.hamcrest.example</groupId>
<artifactId>junit-hamcrest</artifactId>
<version>1.0</version>
<packaging>jar</packaging>
<name>JUnit 4 with Hamcrest</name>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
<dependency>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-core</artifactId>
<version>2.1-SNAPSHOT</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>When maven resolves the dependencies, this is what happened: My interpretation of this is that Maven processes artifact relocation before it looks at artifact version conflict resolution. This means that Maven never considers that a newer version of the My current conclusion is that we still have to publish the empty jars for Is there something I missed? Perhaps an alternative way to configure this? Maybe we should just get everyone up upgrade to JUnit 5 😃 |
|
I've created a new pull request to restore the classes that were renamed or deleted as identified by @olibye (PR #238). I didn't do anything to address the problem with Eclipse and |
Thanks for trying! It seems this feature is not very helpful given how Maven's dependency resolution works after all. |
|
Just tested using 2.1-rc4, only 1 issue. I was using |
|
Ah, that's because we decided to stop generating the |
tumbarumba
changed the title
|
Well, it's been 6 days, with no further reported issues. I'll update the docs to clarify the point about |
|
Share and enjoy! Version 2.1 has been released!
|
|
Thanks for everyone's work on this. I'll test things out. By coincidence the next lesson I'm teaching in my course is over unit testing, so I'll update the material to include Hamcrest 2.1. I'm a little confused with the new public instructions. You make a point of saying to use <dependencies>
<dependency>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest</artifactId>
<version>2.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-library</artifactId>
<version>2.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
</dependencies>That will work, but it 1) introduces an unnecessary Remember that the problem we're trying to get around is the old <dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-core</artifactId>
<version>2.1</version>
<scope>test</scope>
</dependency>
</dependencies>Now we don't have an extra Of course it will work either way, but in my opinion the way it is explained in the docs now could be more confusing to users and has the potential to cause more perplexing problems. But anyway, the important thing is that it's working. You can explain how you want on the site, and I'll explain it the way I prefer in my course. Thanks again for the new release, and happy holidays. |
|
Hi @garretwilson, thanks for highlighting that. At the time I wrote that, I was thinking about other projects or libraries that had a dependency on I don't suppose you'd like to submit a pull request to improve things? |
I'm so sorry, but I'm snowed under with work at is it. I hope my testing and feedback on this ticket has helped, however. In fact over the holiday I read up on JUnit 5, and it turns out that our projects should really be using JUnit 5 anyway. I would recommend stressing in the documentation that anyone considering using Hamcrest with JUnit 4 should really just invest a couple of hours' research and upgrade to JUnit 5 instead. So I spent half the day today completely rewriting my lesson on unit tests (which I'll be teaching live to students tomorrow) to cover JUnit 5 and Hamcrest 2.1. It has extensive notes on using Hamcrest 2.1 (and even Hamcrest 1.3) with JUnit 4 as well. There's a big chance I can make the lesson public at some point this year. In the meantime, I've placed a pretty complete summary on our JIRA ticket for adding JUnit 5 support to the GlobalMentor parent POM, which you may find useful as a quick overview and reference. Happy New Year, by the way! |
hamcrest as of 2.x ships what was previously in hamcrest-core and hamcrest-library in a single jar at artifact coordinate org.hamcrest:hamcrest So as of 2.x you only need to depend on the org.hamcrest:hamcrest. Since JUnit 4 depends on hamcrest-core we need to follow these steps http://hamcrest.org/JavaHamcrest/distributables#upgrading-from-hamcrest-1x hamcrest/JavaHamcrest#224 (comment) to make sure also hamcrest-core is updated. The dependency on hamcrest-core can be removed once JUnit 4 support is dropped.
hamcrest as of 2.x ships what was previously in hamcrest-core and hamcrest-library in a single jar at artifact coordinate org.hamcrest:hamcrest So as of 2.x you only need to depend on the org.hamcrest:hamcrest. Since JUnit 4 depends on hamcrest-core we need to follow these steps http://hamcrest.org/JavaHamcrest/distributables#upgrading-from-hamcrest-1x hamcrest/JavaHamcrest#224 (comment) to make sure also hamcrest-core is updated. The dependency on hamcrest-core can be removed once JUnit 4 support is dropped.
hamcrest as of 2.x ships what was previously in hamcrest-core and hamcrest-library in a single jar at artifact coordinate org.hamcrest:hamcrest So as of 2.x you only need to depend on the org.hamcrest:hamcrest. Since JUnit 4 depends on hamcrest-core we need to follow these steps http://hamcrest.org/JavaHamcrest/distributables#upgrading-from-hamcrest-1x hamcrest/JavaHamcrest#224 (comment) to make sure also hamcrest-core is updated. The dependency on hamcrest-core can be removed once JUnit 4 support is dropped.
…erence. Hamcrest core reference was a workaround for vintage support. See hamcrest/JavaHamcrest#224 .
I can see the last artificat of Hamcrest released on maven central was back in 2015.
But the latest master has many updates which are not availabe on that maven build.
For example empty matcher for Map. So please release the binaries for latest master
on maven central. So we can consume it in our projects. Also the latest master and
binaries on maven central should be in sync.
The text was updated successfully, but these errors were encountered: