Release Version 2.1 On Maven

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.

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 hamcrest-core.jar and hamcrest-library.jar, but I don't see any code for hamcrest-integration.jar or hamcrest-generator.jar (I understand hamcrest-all.jar is just the combination of all the other jars). Does anyone have any idea where this missing code might be? Is it still relevant?

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.

@sf105

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 1.4-SNAPSHOT.

Are there any objections to calling the next version 1.4? If so, what should the next version be?

@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
skip these 1 and 2. And start a new life for hamcrest with 3.x.x.x or 4.x.x.x and regular releases on maven. So their
wont be any confusion remains. Since human by their greedy nature have the tendncy to use latest and greatest one. And using 4.x.x.x skipping 3.x.x.x will mark new life for hamcrest project and will also match jdk style of rebrading from 1.x to x. In our case we can justify it as 1.4 as 4.x in our case and will
remove each confusion.

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 hamcrest-integration. As a result of this pull request, there will be 5 artifacts:

hamcrest-core
hamcrest-library (depends on hamcrest-core)
hamcrest-integration (depends on hamcrest-library, and hence also transitively depends upon hamcrest-core)
hamcrest-all (all the classes in in hamcrest-core, hamcrest-library and hamcrest-integration packaged into a single jar)
java-hamcrest (all the classes in hamcrest-core and hamcrest-library packaged into a single jar)

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 java-hamcrest. My personal preference: keep the existing jars, give people warning that some of them will disappear in a future version. What do other people think?

When (or if) we do remove hamcrest-core and hamcrest-library, we can change the dependency on hamcrest-integration to java-hamcrest. hamcrest-all essentially remains the same.

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 hamcrest-all and deprecate the other jars. That we deprecate java-hamcrest back to hamcrest-all. That, at the next major change, we deprecate hamcrest-all in favour of a hamcrest artefact.

I really like the idea of having an artefact called hamcrest (where we merge hamcrest-core and hamcrest-library). java-hamcrest didn't seem quite right to me.

I'm not sure about hamcrest-integration, though. I don't use it myself, so I'm not sure how popular it is. However, if we include it, it will add optional dependencies to jmock and easymock. Is it feasible to not release any new versions of it? Given that we already have a v2 artefact (a breaking change under semver), the break might be "no more integration". In that case, we can exclude the integration code from hamcrest-all, and it won't need to declare any other dependencies.

Thoughts?

I've tweaked PR #229 with a new proposal: 2 artifacts: hamcrest and hamcrest-integration. We only published hamcrest, though. More details on the PR.

@sf105

I've been making a bit of progress on the release, but there are still some things to do:

Fix the OSSRH publication (issue Fix OSSRH publication check #233)
Update the change log (issue Add changes for next release #232)
I think we should support Java 9 modules (issue Java 9 Quick Win Pre Modules #185 and/or 185 Java9 Automatic-Module-Name #186 ?)
Agree on the next version number to use. I've put in 2.1 for the moment, but I'm not sure we have consensus on that
Update docs in preparation for the next release, specifically:
- Hamcrest Distributables
- API Documentation (JavaDoc)
Write up a promotional blog post, article or something

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:

Although there is no incompatible API changes (as per semantic versioning), the aborted 2.0.0.0 release is confusing, and I think we need to do a minor version increment above that, so I'm proposing the next version be 2.1.
We are going to repackage the old jars hamcrest-core and hamcrest-library, and merge them into a single hamcrest jar in the next version (we don't think the distinction between the two libraries was useful)
I'm currently thinking that hamcrest-integration isn't well used, and I'm not planning to release a new version (the 1.3 versions will of course remain in Maven Central). I'm not planning to release a version of hamcrest-all, either (which was a combination of hamcrest-core, hamcrest-library and hamcrest-integration. Hamcrest becomes just a single jar called hamcrest, which is a much less confusing story to tell.

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.

So, I played around with using the pom relocation feature. I couldn't get it to work.

Thanks for trying! It seems this feature is not very helpful given how Maven's dependency resolution works after all.

@olibye

I've just released Hamcrest version 2.1-rc4. This release candidate has fixes the backwards compatibility issues identified by @olibye by restoring the missing classes and marking them as deprecated.

@olibye, does this release fix the issues for you?

Just tested using 2.1-rc4, only 1 issue.

I was using org.hamcrest.Factory in a custom matcher for some reason and it appears to no longer exists.

Ah, that's because we decided to stop generating the Matchers class in favour of updating it by hand. Unless you're generating your own, then you shouldn't need it.

Well, it's been 6 days, with no further reported issues. I'll update the docs to clarify the point about org.hamcrest.Factory. If there are no other concerns raised, I'm planning to release the final 2.1 version in the next few days.

Share and enjoy! Version 2.1 has been released!

View the docs at http://hamcrest.org/JavaHamcrest/
Update your dependencies as documented at http://hamcrest.org/JavaHamcrest/distributables
Tell your friends and/or loved ones!

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 hamcrest-library and to use it before junit:

<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 hamcrest-library JAR, and 2) makes the build brittle because the order of declarations suddenly becomes important. (Is everyone going to document this in their POMs? More likely, some new developer will come in to many projects, "tidy up" the order of dependencies, and then suddenly things will break and no one will no why.) Plus 3) I don't even know why the example declares hamcrest, as this will be brought in automatically if the dependencies are done correctly

Remember that the problem we're trying to get around is the old hamcrest-core that junit brings in. So it seems to me better just to declare hamcrest-core:

<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 hamcrest-library which no one needs, and the declaration order no longer matters.

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.

@garretwilson

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 hamcrest-library-1.3.jar (for example, any or the related projects could be affected). I was trying to give some advice that would cover any project (not just ones that depend on JUnit 4), but this doesn't come through in the docs.

I don't suppose you'd like to submit a pull request to improve things?

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!

TRUNK-5982 Adapt to new hamcrest packaging

JAVA-212: Removed JUnit 4 dependency management and Hamcrest core ref…

Navigation Menu

Repository navigation

Release Version 2.1 On Maven #224

38 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Release Version 2.1 On Maven #224

Description

Activity

tumbarumba commented on Nov 8, 2018

sf105 commented on Nov 9, 2018

tumbarumba commented on Nov 9, 2018

tumbarumba commented on Nov 9, 2018

tumbarumba commented on Nov 10, 2018

ankurpathak commented on Nov 10, 2018

tumbarumba commented on Nov 14, 2018

sf105 commented on Nov 14, 2018

tumbarumba commented on Nov 14, 2018

tumbarumba commented on Nov 15, 2018

tumbarumba commented on Nov 22, 2018

tumbarumba commented on Nov 23, 2018

geekybaiyi commented on Nov 23, 2018

tumbarumba commented on Nov 23, 2018

38 remaining items

marcphilipp commented on Dec 12, 2018

tumbarumba commented on Dec 13, 2018

nhojpatrick commented on Dec 13, 2018

sf105 commented on Dec 13, 2018

tumbarumba commented on Dec 19, 2018

tumbarumba commented on Dec 21, 2018

garretwilson commented on Dec 24, 2018

tumbarumba commented on Dec 26, 2018

garretwilson commented on Jan 2, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions