Le 04/09/2011 12:59, sebb a écrit :
On 4 September 2011 11:23, sebb<seb...@gmail.com>  wrote:
On 4 September 2011 10:53, Luc Maisonobe<luc.maison...@free.fr>  wrote:
Le 04/09/2011 04:57, Phil Steitz a écrit :

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 previous 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:

     <!-- ensure test jars also get NOTICE&  LICENSE files -->
     <testResources>
       <testResource>
         <directory>${basedir}</directory>
         <targetPath>META-INF</targetPath>
         <includes>
           <include>NOTICE.txt</include>
           <include>LICENSE.txt</include>
         </includes>
       </testResource>
     </testResources>

This replaced the default testResources definition in the super-Pom, which is:

     <testResources>
       <testResource>
         <directory>src/test/resources</directory>
       </testResource>
     </testResources>

The parent POM also redefines<resources>:

     <resources>
       <resource>
         <directory>${basedir}</directory>
         <targetPath>META-INF</targetPath>
         <includes>
           <include>NOTICE.txt</include>
           <include>LICENSE.txt</include>
         </includes>
       </resource>
     </resources>

This has been there since version 3. This replaces:

     <resources>
       <resource>
         <directory>src/main/resources</directory>
       </resource>
     </resources>

which is presumably why the MATH pom has to define its own<resources>
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 layout, we add some problems getting the resources on an Android system. I thought putting a few thing in META-INF was safe and maven compliant, so I put the localization files there. However, android seems to put only its own stuff in META-INF, so reusing this location is perhaps bad.

Should we take this opportunity to move some resources in another folder ? Android seems to use an "assets" folder, would it be maven compliant ? Should we use something more specific to our components ?

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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to