From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1MsmoU-0004pG-9o for garchives@archives.gentoo.org; Wed, 30 Sep 2009 00:12:58 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A9F70E079D; Wed, 30 Sep 2009 00:12:57 +0000 (UTC) Received: from sarasvati.sattvik.com (sarasvati.sattvik.com [64.22.125.197]) by pigeon.gentoo.org (Postfix) with ESMTP id 964B7E079D for ; Wed, 30 Sep 2009 00:12:57 +0000 (UTC) Date: Tue, 29 Sep 2009 19:12:55 -0500 From: Daniel Solano =?iso-8859-1?Q?G=F3mez?= To: gentoo-java@lists.gentoo.org Subject: [gentoo-java] New Hamcrest ebuilds Message-ID: <20090930001251.GE19528@vulcan.guest.intuitivelyobvious.net> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-java@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-PGP-Key: http://www.intuitivelyobvious.net/dan-pubkey.asc Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 0f53c9ca-b3be-4c9d-adf5-6d0f5a65fad8 X-Archives-Hash: 34cfe75bb65a47f07b109a4fea775ea5 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? =20 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=F3mez