Release Version 2.1 On Maven

[ankurpathak]

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.

[tumbarumba]

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?

[sf105]

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.

[tumbarumba]

Thanks @sf105. The test frame integration classes do not appear to be checked into this github repository. Do you have them somewhere else?

[tumbarumba]

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.

[tumbarumba]

@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?

[ankurpathak]

@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.

[tumbarumba]

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.

[sf105]

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.

[tumbarumba]

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?

[tumbarumba]

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.

[tumbarumba]

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?