hamcrest-core and hamcrest-library are split packages

[shs96c]

It's great that these hamcrest jars (at version 1.3, which is what junit 4.12 depends on) declare an automatic module name so that they can be used with the JPMS, but there's a problem --- they create a "split package" since they both try and export classes in org.hamcrest This causes any java 9 modular build that includes both libraries to fail.

This can be fixed by making sure that all the classes in any package are in the same jar, so either by combining all the hamcrest jars, or by being careful with how the release artifacts are constructed.

[tumbarumba]

Thanks for raising this issue, @shs96c. i'm not a heavy user of Java 9, so I'm not sure: is this still a problem with Hamcrest 2.1?

Hamcrest 2.1 was released as 3 jars: hamcrest-2.1.jar (now contains all the code), hamcrest-core-2.1.jar and hamcrest-library-2.1.jar (both empty shims to allow transitive depenencies to find hamcrest-2.1.jar). All 3 jars specify 'Automatic-Module-Name': 'org.hamcrest' in the manifest. I was under the impression that this would Just Work™ with Java 9 modules.

In nearly all cases, Hamcrest 2.1 can be a drop in replacement for Hamcrest 1.3 (though there are some quirks in upgrading: http://hamcrest.org/JavaHamcrest/distributables#upgrading-from-hamcrest-1x)

[shs96c]

I don't think that'll work. The JPMS uses the module name to look up the jar to use, so if multiple jars share the same name there's some distinctly undefined behaviour. Having the core and library jars be empty should be fine, however.

I've bumped my hamcrest to 2.1, dropped the core and library deps, and (after losing @Factory and fixing up code to pretend it never happened) everything seems happier.

Still, the same module name everywhere is going to cause chaos.

[sf105]

Frankly, we’re so strapped for effort that we’ll take whatever contributions we can. The hope was to do a serious rethink with Java closures, but that never happened. S

…

On 20 Aug 2019, at 15:01, Simon Stewart ***@***.***> wrote: I don't think that'll work. The JPMS uses the module name to look up the jar to use, so if multiple jars share the same name there's some distinctly undefined behaviour. Having the core and library jars be empty should be fine, however. I've bumped my hamcrest to 2.1, dropped the core and library deps, and (after losing @factory and fixing up code to pretend it never happened) everything seems happier. Still, the same module name everywhere is going to cause chaos. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#269?email_source=notifications&email_token=AABCNWNGI5TLAXPTL5H4ACDQFPTLDA5CNFSM4IM472BKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4WGNJY#issuecomment-523003559>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABCNWPUVGEG257EA5JZ4IDQFPTLDANCNFSM4IM472BA>.

[tumbarumba]

If we modified the jars so that they had different values in Automatic-Module-Name, such as org.hamcrest, org.hamcrest.core and org.hamcrest.library, would that solve the issue? Would that cause other problems?

I should sit down and create a code sample to test this out.

[shs96c]

That should work, as the jars are just empty.

…

Sent from my iPhone

On 20 Aug 2019, at 22:21, Joe Schmetzer ***@***.***> wrote: If we modified the jars so that they had different values in Automatic-Module-Name, such as org.hamcrest, org.hamcrest.core and org.hamcrest.library, would that solve the issue? Would that cause other problems? I should sit down and create a code sample to test this out. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[tumbarumba]

I was able to reproduce this problem at https://github.com/tumbarumba/hamcrest-test-harness, and tested out the fix in PR #270, which Worked for Me™. Closing this issue on that basis.