- This topic has 3 replies, 2 voices, and was last updated 18 years, 10 months ago by
.
-
Posts
-
Hi there,
We have a situation where where are modifying some of the jsps in a vendors application. I would like the following structure so that I can easily bring in updated versions of the vendors app without affecting my mods../webroot_vendor
/webroot_mymodsThe deployment should merge both folders into Tomcat. I know I can use “smart deployment” with an extra java project to merge classes and there seems to be lots of ways to merge jar files. I can’t find anyway to ordinary files such as htm/jsp etc though?
Regards,
Damon.Damon,
There is no support at this time for merging webroots, the reason is because there is no well defined way to handle conflicts (web.xml files, /lib entries, /classes entries, etc.). We are looking at adding support in the future, but there is no workaround for you right now for this.I would point out that if you simply want to mash the contents of the two webroots together, why can’t you just keep them both in the same webroot and when you get updates from the vendor, just drop it in overwriting the changes? That seems to be what you would have gotten by letting MyEclipse mash them together into the deployment directory anyway.
The reason I don’t want to combine everything in one root is I want a clear way to see what mods I have made. The simple way to handle conflicts in the two roots situation is by having a copying order. First I would copy the vendor root. Then I would copy my root. My mods would overwrite the vendor mods.
For now I will just use ant for deployment on this project.
Regards,
Damon.The simple way to handle conflicts in the two roots situation is by having a copying order. First I would copy the vendor root. Then I would copy my root. My mods would overwrite the vendor mods.
I would point out, the 10 times or so we have had this feature requested, every single user has requested different “rules” for handling conflicts. Copy order is one, file-by-file confirmation is on, timestamp resolution is one, etc. And none of them agreed that having any of the other ways as default was proper for their setting. Regardless we do see the value in this feature in general and will implement a good solution soon enough.
