[
https://jira.codehaus.org/browse/MRRESOURCES-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise updated MRRESOURCES-81:
-------------------------------------------
Issue Type: Improvement (was: Bug)
> 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: Improvement
> Affects Versions: 1.5
> Reporter: Falko Modler
> Priority: Critical
> 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)
