Gentoo Archives: gentoo-java

From: "Daniel Solano Gómez" <gentoo-java@×××××××.com>
To: gentoo-java@l.g.o
Subject: [gentoo-java] New Hamcrest ebuilds
Date: Wed, 30 Sep 2009 00:12:58
Message-Id: 20090930001251.GE19528@vulcan.guest.intuitivelyobvious.net
1 Hello,
2
3 I am working on some new ebuilds to update the dev-java/hamcrest package
4 to version 1.2. As I do this, I'd like to squash bugs 197354 and
5 205489. As I work on this, I have a few questions and I would like to
6 get input from you.
7
8 With regards to bug 205489, I am considering breaking the build into:
9 dev-java/hamcrest-generator
10 dev-java/hamcrest-core (already in portage)
11 dev-java/hamcrest-library
12 dev-java/hamcrest-integration
13
14 Unfortunately, breaking up the ebuild creates a few problems:
15
16 1. Unit testing: Hamcrest uses itself for conducting its unit tests.
17 As a result, even though it may be possible to segregate the unit tests
18 for each component so that each ebuild only runs the relevant tests,
19 there would be a circular dependency problem. For example, to run the
20 tests for hamcrest-generator requires hamcrest-library, but to build
21 hamcrest-library you need hamcrest-generator.
22
23 2. Examples: The examples could be packaged as a separate package.
24 However, since hamcrest-examples would depend on the other packages, it
25 would make it difficult for them to be included by someone who is
26 relying on the examples USE flag.
27
28 I am considering resolving the above issues by creating a
29 dev-java/hamcrest package. This package would have the following
30 properties:
31
32 1. It would depend on hamcrest-generator, hamcrest-core,
33 hamcrest-library, and hamcrest-integration.
34
35 2. It would respond to the test and examples USE flags. In the case of
36 test, it would run the full test suite for all of the packages. In the
37 case of examples, it would build and install hamcrest-examples.jar.
38 Finally, if neither flag is set, then the ebuild would do nothing.
39
40 Does this seem like a good idea?
41
42 If so, would it also make sense for it to use the doc USE flag?
43 Unfortunately, the various modules all insert classes into the
44 org.hamcrest package. As a result, having the disjoint APIs in
45 different locations isn't entirely user-friendly. Would it be a good
46 idea for dev-java/hamcrest to create the API documentation either in
47 addition to or instead of the various hamcrest-* ebuilds?
48
49
50 Lastly, the upgrade from version 1.1 to 1.2 seemed to have changed the
51 interface, so JUnit will not build against 1.2. So I am guessing that
52 the new builds will have to be slotted and the JUnit build will need to
53 be updated to reflect this, correct?
54
55 I appreciate any input on the above items. With your feedback, I hope
56 to post my ebuilds to the Gentoo bugzilla within the next week.
57
58 Sincerely,
59
60 Daniel Solano Gómez