On 4 September 2011 12:24, Luc Maisonobe <luc.maison...@free.fr> wrote:
> 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.
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 <resources> customisation in the Math pom once
it uses version 22.
Meanwhile, we could just change the localisation part to the standard:
<resource>
<directory>src/main/resources</directory>
</resource>
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-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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
