[
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
