Return-Path: X-Original-To: apmail-commons-dev-archive@www.apache.org Delivered-To: apmail-commons-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8B13C76E0 for ; Sun, 4 Sep 2011 11:46:24 +0000 (UTC) Received: (qmail 74840 invoked by uid 500); 4 Sep 2011 11:46:23 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 74235 invoked by uid 500); 4 Sep 2011 11:46:19 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 74212 invoked by uid 99); 4 Sep 2011 11:46:17 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 04 Sep 2011 11:46:17 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of sebbaz@gmail.com designates 209.85.212.43 as permitted sender) Received: from [209.85.212.43] (HELO mail-vw0-f43.google.com) (209.85.212.43) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 04 Sep 2011 11:46:09 +0000 Received: by vws10 with SMTP id 10so4410909vws.30 for ; Sun, 04 Sep 2011 04:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=U9kDrdOa7z2x0/WnmVB8hkHpUSD7i3SZts0Fau+mDXA=; b=p9GTDiv9FU26hwEbUf26pLT7EFMvF2MnoWrQJF1xDMKnx21ZTkYDs0wBQa/GRS96XR fvsOWODJ2I6s8E1ram1MRVZ/04QYPP5OmX6WLsvAmtvdAyEO+pzmFUh4Mnt5SDsnzJub dx1w9uMLbhVdCbFIbjYklqv3AZt1pGmHWVWjc= MIME-Version: 1.0 Received: by 10.220.195.193 with SMTP id ed1mr111550vcb.116.1315136748234; Sun, 04 Sep 2011 04:45:48 -0700 (PDT) Received: by 10.220.85.207 with HTTP; Sun, 4 Sep 2011 04:45:48 -0700 (PDT) In-Reply-To: <4E635FF7.2050709@free.fr> References: <4E62954B.6090005@gmail.com> <4E62AF01.2030608@gmail.com> <4E62D472.3000000@gmail.com> <4E62E1EF.4080401@gmail.com> <4E634AB5.9090301@free.fr> <4E635FF7.2050709@free.fr> Date: Sun, 4 Sep 2011 12:45:48 +0100 Message-ID: Subject: Re: [ALL] parent plugin updates [was: svn commit: r1164565 - /commons/proper/commons-parent/trunk/pom.xml] From: sebb To: Commons Developers List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On 4 September 2011 12:24, Luc Maisonobe wrote: > Le 04/09/2011 12:59, sebb a =E9crit : >> >> On 4 September 2011 11:23, sebb =A0wrote: >>> >>> On 4 September 2011 10:53, Luc Maisonobe =A0wrot= e: >>>> >>>> Le 04/09/2011 04:57, Phil Steitz a =E9crit : >>>>> >>>>> Same problem under Linux for parent 21. >>>> >>>> Isn't it related to a problem that arose some weeks ago about the >>>> resource >>>> not being copied from source tree to classpath ? I think it appeared >>>> first >>>> in Gump and someone updated the configuration to match what maven did >>>> automatically. Perhaps these new plugins do not behave like the previo= us >>>> one >>>> with respect to copying data files for tests ? >>> >>> Yes, I think that may be it. >>> >>> Just run another test using "mvn clean" first, and that now causes the >>> error on Windows too. >>> Sorry, I thought I had done that previously. >>> >>> I propose to update the test case to replace the NPE with a more >>> useful message if possible. >>> >>> And I'll have a look at which plugin is causing the problem. >> >> Problem solved. >> >> It was not a plugin version issue. The problem was caused by the >> change in parent from 20->21 which added the following: >> >> =A0 =A0 >> =A0 =A0 >> =A0 =A0 =A0 >> =A0 =A0 =A0 =A0 ${basedir} >> =A0 =A0 =A0 =A0 META-INF >> =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 =A0 =A0 NOTICE.txt >> =A0 =A0 =A0 =A0 =A0 LICENSE.txt >> =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 >> =A0 =A0 >> >> This replaced the default testResources definition in the super-Pom, whi= ch >> is: >> >> =A0 =A0 >> =A0 =A0 =A0 >> =A0 =A0 =A0 =A0 src/test/resources >> =A0 =A0 =A0 >> =A0 =A0 >> >> The parent POM also redefines: >> >> =A0 =A0 >> =A0 =A0 =A0 >> =A0 =A0 =A0 =A0 ${basedir} >> =A0 =A0 =A0 =A0 META-INF >> =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 =A0 =A0 NOTICE.txt >> =A0 =A0 =A0 =A0 =A0 LICENSE.txt >> =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 >> =A0 =A0 >> >> This has been there since version 3. This replaces: >> >> =A0 =A0 >> =A0 =A0 =A0 >> =A0 =A0 =A0 =A0 src/main/resources >> =A0 =A0 =A0 >> =A0 =A0 >> >> which is presumably why the MATH pom has to define its own >> entry to include the localisation directory. >> >> I think we have two ways forward here: >> 1) ensure that the parent resources and testResources entries include >> the default provided by the super-pom >> 2) find a different way to include the N&L files which does not >> require overriding the super-pom > > I'm not sure this is related, but in another project with a similar layou= t, > we add some problems getting the resources on an Android system. I though= t > putting a few thing in META-INF was safe and maven compliant, so I put th= e > localization files there. However, android seems to put only its own stuf= f > in META-INF, so reusing this location is perhaps bad. Maven assumes resources are under: src/main/resources It just copies any files/folders under there to classes/ and does not care what the names are. > Should we take this opportunity to move some resources in another folder = ? > Android seems to use an "assets" folder, would it be maven compliant ? If it is under src/main/resources, Maven does not care. > Should we use something more specific to our components ? Probably better to leave META-INF directory for the files that truly belong there, such as MANIFEST.MF and service provider property files. We can drop the entire customisation in the Math pom once it uses version 22. Meanwhile, we could just change the localisation part to the standard: src/main/resources which would work even if the resources are moved from META-INF > Luc > >> >> The second approach would be safer, as it would not rely on knowing >> what the super-pom does, but the first is trivial to do, so I'll start >> with that. >> >>>> I'm sorry, I have no time yet to test this. >> >> But well done for providing the essential hint! >> >>>> Luc >>>> >>>>> >>>>> Phil >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >>>>> For additional commands, e-mail: dev-help@commons.apache.org >>>>> >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >>>> For additional commands, e-mail: dev-help@commons.apache.org >>>> >>>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >> For additional commands, e-mail: dev-help@commons.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org > For additional commands, e-mail: dev-help@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org For additional commands, e-mail: dev-help@commons.apache.org