For help with installation, bugs reports or feature requests, please head over to our new forums.
Genuitec Community on GitHub
- This topic has 4 replies, 3 voices, and was last updated 14 years, 9 months ago by
.
-
Posts
-
I use maven’s overlay war utility to combine web projects. I also use MyEclipse to deploy to my local tomcat. I can overylay projects using ‘Custom Location’ and deploying multiple projects to the same directory but it doesn’t remember priority. Each time I restart eclipse, the projects overlay seems to be in a different order. I can work around this by Touching every file I want deployed. But it would be nicer if it worked with the dependency hierarchy. Any suggestions?
Thanks.
I don’t quite follow, is this a feature that Maven’s overlay utility handles? You mention “priority”, but off the top of my head I don’t know how this relates to our deployment tool so I’m assuming it’s from another tool.
The overlay tool handles web projects which depend on other web projects. For example I have a web-project called my-web-core which has some standard web pages such as login and it’s own web.xml. My other web project called my-web-operations depends on that. It has it’s own web.xml and it’s own web pages. Maven will take my-web-core and then extract my-web-operations on top of it. The final output is a project that has all of my-web-operations and any of my-web-core that doesn’t exist in my-web-operations.
In order to develop this, I use a Custom Location and deploy both of these projects to the same location. This has the option to add/replace. This works unless a resource exists in both projects. In that scenario, MyEclipse is not consistent in how resources are copied over so I find my self having to use the Unix touch command to update the date on files that I want copied over. So if I want the web.xml from my-web-operations to be deployed instead of the web.xml from my-web-core, I have to run touch against the web.xml file so that MyEclipse thinks it has changed and copies the new file to my Tomcat deployed directory.
Oh I see, thank you for the description of the situation.
This actually wasn’t a use-case we explicitly tested but I can certainly see the annoyance in needing to constantly re-touch a file for deployment reasons. I’ll file a PR to help control this or extend this functionality.
