Build separate jars for core, library, and all. #228
Conversation
This is done by converting to a multi-project gradle build, with subprojects for `hamcrest-core.jar` and `hamcrest-library.jar`. The root project is responsible for combining all the individual jars into `hamcrest-all.jar`, as well as configuring the publishing.
|
I thought we were just going to have one big jar and drop the smaller ones? Basically, everything that just depends on the JVM ad there’s not much point in distinguishing between core and library. |
|
Ah, I misunderstood the conversation last Tuesday, where we were discussing keeping APIs the same as 1.3 (it was in a pub and quite loud!), as well as your comments on Issue #224, where you were keeping hamcrest-integration as a separate jar (it has dependencies outside the jdk). For some reason I had told myself you meant that all the jar packages should stay the same. I can change this, though I think we still need the multi-project aspect. If I bring the integration code back from Google Code, we can keep that as a separate jar, and merge core and library into a single jar, as you had before this specific change. How does that sound? |
This is done by converting to a multi-project gradle build, with subprojects for
hamcrest-coreandhamcrest-library. The root project is responsible for combining all the individual jars intohamcrest-all.jar, as well as configuring the publishing.Note that this changes the version from '2.0.0.0' to '1.4-SNAPSHOT'