maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephane Nicoll (JIRA)" <>
Subject [jira] Closed: (MWAR-78) War overlay can overwrite files in dependant war artifact
Date Fri, 16 Mar 2007 20:21:34 GMT


Stephane Nicoll closed MWAR-78.

    Resolution: Won't Fix

> War overlay can overwrite files in dependant war artifact
> ---------------------------------------------------------
>                 Key: MWAR-78
>                 URL:
>             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 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 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:
For more information on JIRA, see:


View raw message