maven-issues mailing list archives

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

    [ 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

        

Mime
View raw message