[
http://jira.codehaus.org/browse/MWAR-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90293
]
Brian Reilly commented on MWAR-78:
--
I think either my report was misunderstood or I'm misunderstanding the
response. This problem isn't about choosing which file to take from multiple
war overlays. It's about whether to use a file from a war overlay or from the
project depending on that war.
I agree that overrides should not depend on a timestamp. The problem that I
reported was the result of code that does use timestamp checks. The patch that
I attached removes the timestamp check for the case that I ran into.
I should note that there are other uses of copyFileIfModified() in that file
that I did not review to see if they should also be changed. Also, I haven't
checked to see if the code has changed since I reported the bug.
In general, the code seemed backwards to me. It was copying the current
project's files and then trying to choose the right files to copy from the
dependency (which is where the timestamp check seemed to come in, though even
that doesn't quite make sense). A safer way to do it would be to copy the
files from the dependency and then copy the current project's files on top,
replacing anything that existed in the dependency.
War overlay can overwrite files in dependant war artifact
-
Key: MWAR-78
URL: http://jira.codehaus.org/browse/MWAR-78
Project: Maven 2.x War Plugin
Issue Type: Bug
Affects Versions: 2.0.1
Reporter: Brian Reilly
Assigned To: Stephane Nicoll
Attachments: maven-war-plugin-2.0.1-overlay-bug.diff
Suppose there is a war artifact A that is depended on by war artifact B. If
they contain files with the same name in src/main/webapp and the timestamp in
A is more recent than the timestamp in B, the file from A will be used. I
don't know if it's officially stated in the docs, but I think the intention
is that files in B should always win regardless of timestamp.
I've attached a diff (based on the maven-war-plugin-2.0.1 tag) that adds a
test case to WarExplodedMojoTest.java to demonstrate the problem.
The cause seems to be the use of copyFileIfModified in
AbstractWarMojo.copyDependentWarContents(). I'm not sure why this should be
done (except in the case of trying to avoid triggering a hot redeploy, which
doesn't apply to all files).
The diff also includes changes to AbstractWarMojo.java that fix the test
failures. I've created a copyFile method that is a clone of
copyFileIfModified without the timestamp check. That method is then used in
copyDependentWarContents instead. Additionally, I pulled in the !new File(
warSourceDirectory, files[j] ).exists() check from trunk. Lastly, I had to
change copyResources(File, File) to use copyFile as well in order to get the
tests to pass.
There may be other places where copyFileIfModified could be replaced with
copyFile, but I haven't done an extensive audit of every place where
copyFileIfModified is being used.
I also modified the last condition of testExplodedWarMergeWarUpdated because
it seemed incorrect to me and the fix that I made necessitated it. The test
was explicitly making sure that the version of org/sample/company/test.jsp
from simple-updated.war remained even after changing the dependency back to
simple.war. Put another way, the result of the last test would be different
depending on whether or not `mvn clean` is run after each dependency change.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
