From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: [PATCH] Add junit. Date: Fri, 22 Apr 2016 23:03:24 +0200 Message-ID: <877ffpz78j.fsf@mdc-berlin.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:52387) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atiEl-0005ZW-RC for guix-devel@gnu.org; Fri, 22 Apr 2016 17:03:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1atiEh-000325-Qr for guix-devel@gnu.org; Fri, 22 Apr 2016 17:03:39 -0400 Received: from sinope.bbbm.mdc-berlin.de ([141.80.25.23]:36556) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atiEh-00031r-Ey for guix-devel@gnu.org; Fri, 22 Apr 2016 17:03:35 -0400 In-Reply-To: List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Eric Bavier Cc: guix-devel@gnu.org Eric Bavier writes: > On 2016-04-22 09:16, Ricardo Wurmus wrote: >> Hi Guix, >>=20 >> here=E2=80=99s a first batch of patches for Java libraries. Many Java= packages >> depend on JUnit, so that=E2=80=99s where I started. =E2=80=9Chamcrest= -core=E2=80=9D is just a >> small part of the whole hamcrest library, but it=E2=80=99s enough to b= uild >> JUnit. > [...] >> + (add-before 'configure 'patch-build.xml >> + (lambda _ >> + (substitute* "build.xml" >> + (("unit-test, ") "") >> + (("\\$\\{build.timestamp\\}") "guix")) > > Is using "guix" here as a timestamp safe? Will nothing read the=20 > manifest and expect an actualy timestamp? (I've become unfamiliar with= =20 > most of java-land lately). hamcrest-core is the only package I=E2=80=99ve encountered so far that ad= ds a timestamp to the manifest. Anything can be put inside manifests, so I don=E2=80=99t think it matters much. We could replace the timestamp with= the commit date of the package expression, just so that we have an actual date (and one that isn=E2=80=99t 30+ years in the past). >> + ;; Java's "getMethods()" returns methods in an unpredictable= =20 >> order. >> + ;; To make the output of the generated code deterministic we= =20 >> must >> + ;; sort the array of methods. >> + (add-after 'unpack 'make-method-order-deterministic > > Should we patch our java package instead? Perhaps that can be saved as= =20 > a future exercise. The official documentation states that the order of methods returned is undefined. I wouldn=E2=80=99t like to force sorting on all users of the reflection API. In this case it=E2=80=99s important as the method names = are written to a file in whatever order they are returned. In general the order is of no importance. >> + (snippet >> + '(begin >> + ;; Delete bundled jar archives. >> + (delete-file-recursively "lib") >> + #t)))) > > Is this very common in java packages? I=E2=80=99d say it=E2=80=99s somewhat more common than in packages writte= n in other languages, but I wouldn=E2=80=99t yet feel comfortable doing this by defa= ult for all Java packages. > Otherwise LGTM. Thanks for the review! ~~ Ricardo