Re: [I] [MWAR-66] No control over war overlay order [maven-war-plugin]
jira-importer commented on issue #232: URL: https://github.com/apache/maven-war-plugin/issues/232#issuecomment-2967854500 **[Martin Zeltner](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=swisswheel)** commented What's the current state of this issue? Is it already solved and checked-in in SVN? From my point of view this issue is a blocker. I've found a mailing list thread that explains the problem in detail too (see http://mail-archives.apache.org/mod_mbox/maven-users/200608.mbox/%[email protected]%3e). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
Re: [I] [MWAR-66] No control over war overlay order [maven-war-plugin]
jira-importer commented on issue #232: URL: https://github.com/apache/maven-war-plugin/issues/232#issuecomment-2967854512 **[Stephane Nicoll](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=snicoll)** commented War overlay can be controlled . Staging site available: http://people.apache.org/~snicoll/maven-stage-repo/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
Re: [I] [MWAR-66] No control over war overlay order [maven-war-plugin]
jira-importer commented on issue #232: URL: https://github.com/apache/maven-war-plugin/issues/232#issuecomment-2967854502 **[Martin Zeltner](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=swisswheel)** commented Same issue. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
Re: [I] [MWAR-66] No control over war overlay order [maven-war-plugin]
jira-importer commented on issue #232: URL: https://github.com/apache/maven-war-plugin/issues/232#issuecomment-2967854505 **[Brian E. Fox (imported)](https://issues.apache.org/jira/secure/[email protected])** commented I think that the configuration for layering order should also provide the ability to define where to layer to current project because I think the current method of building the project and then placing wars on top is backward. I had to solve this problem back in early M2 days before war had overlay support. I create wars that are intended to be repackaged by excluding all jars and some various other files I don't want included (we create 2 wars, one that can be run standalone for unit testing and one that is deployed). In the war that does the repackaging, I use the dependency plugin to unpack the first war into the target folder where the war plugin does the inplace processing. This broke because between beta2 and 2.0.1, code was added to check the file timestamp. If the timestamp in the project is older than the one being unpacked, then it isn't used, even though we intend it to. There is no way to make this work perfectly just by checking timestamps. If we have setup like this: WAR A WAR B Where WAR B extends WAR A. They expect that if they change and build WAR A and then build WAR B, those changes are viewed immediately. If you mess with the timestamp comparison, this wouldn't be possible. The only way to make this work in all cases, is to unpack the dependencies in a defined order, and then stack the current project on top and ignore timestamps. This guarantees a set order of inheritence where the last to be stacked wins. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
Re: [I] [MWAR-66] No control over war overlay order [maven-war-plugin]
jira-importer commented on issue #232: URL: https://github.com/apache/maven-war-plugin/issues/232#issuecomment-2967854496 **[Brian E. Fox (imported)](https://issues.apache.org/jira/secure/[email protected])** commented There are additional problems with the way the overlaying is done. Example: War A is a template project. Lets say I have foo.html that is a default file. War B depends on War A but I want to override foo.html. War C depends on War B but I want to yet again override foo.html Because the war of the current project is assembled and then the overlays copied on top, the plugin needs logic to not overwrite files that already exist in the target folder. Then if we layer it such that C is built first and then B is overlaid and A last and we never overwrite a file that exists, we end up with what we intended. However, lets say we are in snapshot mode and developer working on B needs to see the results of his efforts in C. Because we've said that we can never overwrite the files that exist to get proper layering, this means that any files in B won't be recopied again to the target because they already exist. It means they need to do a clean build everytime. I had built a overlaying model before war support that worked opposite. I expand each dependent war into the target folder BEFORE the current project's war gets assembled. So in my example above, I expand A, then B overwriting all of A and then C get's assembled on top getting the last word. By always overwriting the files each time, if B changed, those files immediately take effect without a clean build. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
