Bug 455865 - Deployment dir contains same named file from target/classes instead of target/m2e-wtp/web-resources/WEB-INF/classes (or target/test-classes)
Summary: Deployment dir contains same named file from target/classes instead of target...
Status: NEW
Alias: None
Product: M2E-WTP
Classification: Technology
Component: Core (show other bugs)
Version: 1.1.0   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-20 14:21 EST by Jeff Jensen CLA
Modified: 2014-12-22 09:03 EST (History)
3 users (show)

See Also:


Attachments
sample app modules to use with the issue (2.40 KB, application/x-7z-compressed)
2014-12-20 14:21 EST, Jeff Jensen CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Jensen CLA 2014-12-20 14:21:32 EST
Created attachment 249570 [details]
sample app modules to use with the issue

In the attached sample, application.properties exists in both src/main/resources and src/test/resources.
When m2e-wtp places application.properties in module-a/target/m2e-wtp/web-resources/WEB-INF/classes, it is the one from src/test/resources (target/test-classes), as expected per the configuration.

However, when deploying to Tomcat within Eclipse, the deployment dir, e.g.:
...\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps\spikes-m2e-wtp-module-a\WEB-INF\classes
contains the file from src/main/resources (target/classes), not src/test/resources (target/test-classes) even though module-a/target/m2e-wtp/web-resources/WEB-INF/classes has the src/test/resources one.

I expected it to use the one from module-a/target/m2e-wtp/web-resources/WEB-INF/classes.

Is it behaving as designed or should it contain the one from module-a/target/m2e-wtp/web-resources/WEB-INF/classes?
Comment 1 Fred Bricon CLA 2014-12-22 09:03:31 EST
Unfortunately, this is a behavior in WTP we have no control over for now. All deployed classpath resources will win over resources defined in virtual folders in .component.

As for workarounds, if your the deployed resources are just plain text files (xml, properties), you're probably better using actual maven filtering on them. So a dev profile would inject dev settings in these files from src/main/resources and they would end up being deployed. No need for adding test dir as webResources.