Dimitris Andreadis wrote:
Jason Greene wrote:
The whole problem is the past approach doesnt work AT ALL. How do you trigger a redeploy of an exploded directory in a servlet 3.0 application that has no web.xml? So no matter what we do it will be different.
You obviously need to base the decision on the fact that something changed (file added/removed/edited). The smarter way would require somekind of knowledge per deployment type about where to look for changes. The dumb way would blindly assume the unit needs redeployment if anything changed (and in the case that Brian pointed out that you copy everything over, you know what's changed on every pass).
The latter approach was attempted in 5 and we had to rollback to 4 behavior because of the number of complaints issues around spurious errors it would cause. The former approach requires some kind of identifier, but we can't use deployment descriptors, since they might not be there. We can't use class files because they aren't required either (they might be in WEB-INF/lib). We also can't use the directory for the problems you mentioned earlier. So using a special deploy file is pretty much the only option, and IMO that's more intuitive than touching the TLD, since it's at least consistent across deployments.