You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Stephane Nicoll (JIRA)" <ji...@codehaus.org> on 2007/03/16 21:21:34 UTC
[jira] Commented: (MWAR-78) War overlay can overwrite files in
dependant war artifact
[ http://jira.codehaus.org/browse/MWAR-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90289 ]
Stephane Nicoll commented on MWAR-78:
-------------------------------------
I am not sure that overriding should occur because of a timestamp. This will result in highly unpredictable builds. Instead, we should provide an order for the overlay mechansim so that users could specify in which order to overlay should happen.
I will close this one as won't fix. Please comment if you have any comments/remarks.
> 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