[ 
https://jira.codehaus.org/browse/MRRESOURCES-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl-Heinz Marbaise updated MRRESOURCES-81:
-------------------------------------------

    Issue Type: Bug  (was: Improvement)

> Unexpected behaviour when bundled resource has the same name as another file 
> in src/main/resources
> --------------------------------------------------------------------------------------------------
>
>                 Key: MRRESOURCES-81
>                 URL: https://jira.codehaus.org/browse/MRRESOURCES-81
>             Project: Maven Remote Resources Plugin
>          Issue Type: Bug
>    Affects Versions: 1.5
>            Reporter: Falko Modler
>            Priority: Minor
>             Fix For: more-investigation
>
>         Attachments: MRRESOURCES-81.zip
>
>
> Scenario:
> Some project bundles a file named {{META-INF/beans.xml}}.
> Another project wants to use that file for its tests, so it sets 
> {{<attachToMain>false</attachToMain>}} and 
> {{<attachToTest>true</attachToTest>}}. Now let's assume that this project 
> also has a file named {{META-INF/beans.xml}} under {{src/main/resources}}.
> My assumption - especially when using {{<attachToMain>false</attachToMain>}} 
> - is that everything should be fine: the beans.xml from the bundle should not 
> be conflicting with the one from the main branch of the project that wants to 
> use the bundled file.
> But this is what happens instead: The file from {{src/main/resources}} ends 
> up in {{maven-shared-archive-resources}}, *not* the one from the bundle.
> The problem is caused by the way existing project resources are seemingly 
> preferred over the bundled resources from the user defined artifact (and are 
> even copied to the output directory). From a user perspective, this is not 
> what I want. See also 
> {{ProcessRemoteResourcesMojo.copyResourceIfExists(...)}}.
> A possible fix might be to introduce a new property like 
> {{preferProjectResources}} which can be set to {{false}} (which should be the 
> default value in my opinion, would break backwards compatibility though).



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

Reply via email to