[jira] Closed: (MWAR-78) War overlay can overwrite files in dependant war artifact

["Stephane Nicoll (JIRA)" <ji...@codehaus.org>]

     [ http://jira.codehaus.org/browse/MWAR-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stephane Nicoll closed MWAR-78.
-------------------------------

       Resolution: Fixed
    Fix Version/s: 2.1-alpha-1

First-win strategy + ownership of the file so copy is always deterministic (does not change if an overlay gets updated for some reason).

Staging site available: http://people.apache.org/~snicoll/maven-stage-repo/

> 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
>            Assignee: Stephane Nicoll
>             Fix For: 2.1-alpha-1
>
>         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