Tomcat and Eclipse Zero Turnaround Deployment

I want to be able to deploy code changes to Tomcat (near instantly), while I'm developing in Eclipse.

So far, I have my output from Eclipse placing the built classes in the WEB-INF/classes folder of my web application.

I also have a reloadable context, with the web.xml as a watched resource. Any edit / save to this file does reload my web app, taking just over one second - much quicker than building a new war file and deploying it in full.

However, what I'd like to do is trigger the redeploy when I edit any source file. As the .class files are being modified in Tomcat, it seems I just need to monitor any changes in the WEB-INF/classes folder and it's children.

I've read that I can add additional watched resources in Tomcat's context.xml but this doesn't seem to be quite what I need - unless it's possible to specify a directory that will be watched (including recursively monitoring sub folders and files)?

<Context>
  <WatchedResource>WEB-INF/web.xml</WatchedResource>
  <WatchedResource>WEB-INF/someother.file</WatchedResource>
  <Manager pathname=""/>
</Context>

So essentially, my question is can I watch the entire classes folder (without including each WatchedResource explicitly) to trigger a redeploy in Tomcat?

If not, can I configure Eclipse to touch the web.xml file, whenever I save a source file in that project? I'm developing on a Windows system. :(

PS I'm not interested in the JRebel product. Any answer should be a free solution.

Update

According to the Tomcat documentation, the classes folder should be monitored by setting the context to reloadable:

Set to true if you want Catalina to monitor classes in /WEB-INF/classes/ and /WEB-INF/lib for changes, and automatically reload the web application if a change is detected.

Only changes to the web.xml seem to trigger a reload. Is this a bug or is my setup incorrect?

Also, I've read about setting the docBase attribute for a given context:

docB开发者_高级运维ase="webapps/someExample"

This appears to be close to what I need, as I could then republish in Eclipse quickly. My only problem is that I require several web apps / servlets to be running in Tomcat concurrently, on the same port etc.

For these cases I set the eclipse build output to WEB-INF/classes as you have done and create a context file with the docBase set to the webapp folder (parent of WEB-INF) in the project. This is manually placed in conf/Catalina/localhost (assuming default configs for some elements of server.xml). End result is tomcat ends up serving from the development directory. So, change a servlet or other class and it is updated to the classes folder. Save a jsp and it is immediately available.

If project structured like:

src
|-main
  |-webapp
    |-images
    |-js
    |-WEB-INF
      |-jsp
      |-classes

Then context would be like:

<?xml version="1.0" encoding="UTF-8"?>
<Context path="/path" reloadable="true" 
    docBase="<pathtoproject>/src/main/webapp" />

Maybe the Web Tools Project of Eclipse with auto-redeploy enabled will help you? Add a server, open properties and under Publishing you will see a radiobutton saying "Automatically publish when resources changes". This will result in a redeploy if classes changes otherwise just overwrites resources. You can install WTP via a built in update site (Eclipse only), so check out your software updates. It is free for most servers but it does not support certain Websphere features?

Try the Spring Loaded JVM agent I've described in the following answer: https://stackoverflow.com/a/37064672/1034436

While that has worked for my Spring web application, this should work with vanilla Eclipse + WTP + Tomcat + Dynamic Web Applications since Spring Loaded works on the JVM/classloading level.

You will still need to use the "Automatically publish when resources changes" as mentioned by @toomasr in his answer. However, you must also disable "Module auto reload by default" option as well. If you already added/published modules from Eclipse to Tomcat, then disable "Auto Reload" for each web module (via the Tomcat config page's Modules tab). That should prevent Tomcat from reloading the application when a single class file is updated, which I suspect is what all that reload/wait time is.