Project: JDT
Bug 305172 [common navigator] Project Explorer not fully updating with jar classpath container changes.
Reported: 2010-03-09 10:51:09 | Status: verified fixed

I found this problem while attempting to fix what appeared to a problem with the Web App Libraries classpath container defined in WTP. This container automatically automatically adds all jars residing in the project's WEB-INF/lib folder. There is also listening code which reacts to when jars are added or removed from this folder so the container is reset any time a user changes these jars. The problem I was digging into was if one of the existing jars was replaced (exact same name, but different contents), the container did not seem to update. Initially, I enhanced the listening code to catch the jar replace scenario and ensure the container was replaced (i.e calling JavaCore.setClasspathContainer with a new instance of the container), this did not fix the classpath problems. I observed the following when replacing jars handled by this container regardless of whether the container updated (i.e. I observed exactly the same behavior with and without my fixes). My testcase was to have two jars named "stuff.jar" one contained the class test.A, the other contained test.B. My Web App contained two classes, called NeedsA and NeedsB which each extended their respective classes in stuff.jar (so only one of these can actually compile at a time). Then, I simply dropped one of the stuff.jars in the WEB-INF/lib folder, and then replaced it with the other. First, the underlying JDT compile model seems to be correct. E.g. the markers view shows the correct errors or lack thereof and the package explorer's class label decorators also show those errors or lack thereof. Second, the editor's markers are stale and stay that way. Third, the contents of the classpath container's jar in the PackageExplorer when the container is expanded and the jar is expanded is also stale and stays that way. Unfortunately, there does not seem to be any workaround for the user, aside from removing and readding the container or closing and reopening the project to bring all aspects of the JDT model back in sync. JDT should treat jars added by containers exactly the same as jars added directly to the classpath (I performed the same sort of test of replacing stuff.jar when it was added directly to the classpath, and that always seemed to work). This is a major problem because an adopter built on top of WTP using this container has some tooling which generates/updates jars that reside in the WEB-INF/lib folder.

Files changed in fix:
org.eclipse.jdt.ui/ui/org/eclipse/jdt/ui/actions/RefreshAction.java