[gentoo-java] New Hamcrest ebuilds

["Daniel Solano Gómez" <gentoo-java@sattvik.com>]

Hello,

I am working on some new ebuilds to update the dev-java/hamcrest package
to version 1.2.  As I do this, I'd like to squash bugs 197354 and
205489.   As I work on this, I have a few questions and I would like to
get input from you.

With regards to bug 205489, I am considering breaking the build into:
  dev-java/hamcrest-generator
  dev-java/hamcrest-core       (already in portage)
  dev-java/hamcrest-library
  dev-java/hamcrest-integration

Unfortunately, breaking up the ebuild creates a few problems:

1. Unit testing:  Hamcrest uses itself for conducting its unit tests.
As a result, even though it may be possible to segregate the unit tests
for each component so that each ebuild only runs the relevant tests,
there would be a circular dependency problem.  For example, to run the
tests for hamcrest-generator requires hamcrest-library, but to build
hamcrest-library you need hamcrest-generator.

2. Examples: The examples could be packaged as a separate package.
However, since hamcrest-examples would depend on the other packages, it
would make it difficult for them to be included by someone who is
relying on the examples USE flag.

I am considering resolving the above issues by creating a
dev-java/hamcrest package.  This package would have the following
properties:

1. It would depend on hamcrest-generator, hamcrest-core,
hamcrest-library, and hamcrest-integration.

2. It would respond to the test and examples USE flags.  In the case of
test, it would run the full test suite for all of the packages.  In the
case of examples, it would build and install hamcrest-examples.jar.
Finally, if neither flag is set, then the ebuild would do nothing.

Does this seem like a good idea?  

If so, would it also make sense for it to use the doc USE flag?
Unfortunately, the various modules all insert classes into the
org.hamcrest package.  As a result, having the disjoint APIs in
different locations isn't entirely user-friendly.  Would it be a good
idea for dev-java/hamcrest to create the API documentation either in
addition to or instead of the various hamcrest-* ebuilds?


Lastly, the upgrade from version 1.1 to 1.2 seemed to have changed the
interface, so JUnit will not build against 1.2.  So I am guessing that
the new builds will have to be slotted and the JUnit build will need to
be updated to reflect this, correct?

I appreciate any input on the above items.  With your feedback, I hope
to post my ebuilds to the Gentoo bugzilla within the next week.

Sincerely,

Daniel Solano Gómez