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 |