Please, forgive the following rant. Eclipse is a great tool. I love it, with its myriad plugins all working like they should… unless you are on or near the bleeding edge of Eclipse releases. My day job consists of writing Web-based applications in Java, and we were tired of the cost and excruciatingly slow performance of WSAD 5.1.2, so a couple colleagues and I decided to start using Eclipse with the WTP plugin. So, currently, we are using Eclipse 3.1M4, with WTP 1.0M2, VSS Plugin 1.6.0 M2-comp, and all of th necessary Eclipse Project plugins to make those work (SDO, EMF, etc). I alos have a bunch of other plugins that I use, but those are the base.
For the most part, everything is great: Eclipse 3.1M4 is lightning fast, and the WTP plugin has made huge strides in relatively short time. The problems we are experiencing are due mainly to the VSS Plugin. VSS plugin is a Team Repository plugin to support Microsoft’s Visual Source Safe product. Why we use this I am not exactly sure, but it is not a bad tool. However, the plugin is has not been updated since Eclipse 3.1M2. And, of course, the Eclipse team is still refactoring the product to make it even better than it currently is. So, the framework moves forward. The plugin doesn’t. Things break.
The specific problem we were experiencing occurrs when viewing a file, and then typing something in the window. This triggers an event in Eclipse to tell the Team Repository plug-in that the file has changed. The plugin in turn asks the user if they want to check the file out. If the user clicks yes, then a white page with “Exception Running Validator Code” on it.
This is the way I usually check code out, so it became very annoying very quickly. So, I went to sourceforge and downloaded the code to see if I could modify it myself. Now, I am not familiar with CVS, nor am I familiar with the internals of Eclipse, so I had my hands full very quickly. I followed the directions on the VSS plugin site to download the code using the CVS Checkouot project wizard, which worked well. I was not prepared for the 31 Errors to pop up inside Eclipse. My first reaction was “Oh, Shit!” - I was not really in the mood to hunt down 30+ errors at that moment. I wanted to make the fix necessary to get my problem resolved and move on. Fortunately, the Eclipse log file (/eclipse/workspace/.metadata/.log) had a stack trace in it, so I was able to quickly find the exact line of code that had the problem. As I said, I am not familiar with the internal workings of Eclipse, so I was pretty much lost on what needed to be done.
Here was the original code:
final IRunnableWithProgress operation = new WorkspaceSyncModifyOperation(file) {
/**
* @see org.vssplugin.core.WorkspaceSyncModifyOperation#exec(org.eclipse.core.runtime.IProgressMonitor)
*/
protected void exec(IProgressMonitor monitor)
throws TeamException, CoreException, InvocationTargetException, InterruptedException {
/* Comment. This is currently not possible to do, since the current refactoring implementation
* requires that no files can be changed after starting the operation and the callback to
* this hook is only done a but to late.
* Made a fix for the problem above.. Don’t know if this is legal to do.
*/
long stamp = ((File) file).getResourceInfo(false, false).getModificationStamp();
IResource[] resources = new IResource[] { file };
IPreferenceStore store = VSSPlugin.getInstance().getPreferenceStore();
Comments comments = null;
if (store.getBoolean(VSSPlugin.USE_CHECKOUT_COMMENTS)) {
comments =
ActionUtils.getComments(
VSSPlugin.getInstance().getShell(),
resources,
null,
false);
}
_provider.checkout(resources, comments, IResource.DEPTH_ZERO, new NullProgressMonitor());
((File) file).getResourceInfo(false, false).setModificationStamp(stamp);
}
};
The line:
((File) file).getResourceInfo(false, false).setModificationStamp(stamp);
was the problem. The setModificationStamp method was removed at some point between 3.1M2 and 3.1M4. I initially did not know what to do, so I went hunting for the closest thing I could find to setting the modification stamp. I settled on this line of code:
((File) file).setLocalTimeStamp(stamp);
Which did appear to solve the problem some of the time. We were seeing intermittent problems with that fix that I could not explain, so I went back to hunting for something else. Then I found, thanks to Eclipse’s amazing code completion algorithm, that on the ResourceInfo class, which used to have the setModificationStamp method now had an incrementModificationStamp method. So, I changed that line to:
((File) file).getResourceInfo(false, false).incrementModificationStamp();
We’ve been testing this for a couple of days now, and it appears to be working just fine.
In the midst of all this, I decided to contact the project manager of the VSS Plugin, Marcus Nylander, to offer my assistance, and to see if what I was doing made sense. You may have noticed the comment at the top of the method. That made it even less clear to me what I was doing, so I thought that getting in touch with him would be the best course of action. Marcus was quick to respond, first thanking me for offering to help, then pointing me to the right source code to look at (thankfully, no errors other than the one I was working on) and finally enlightening me a bit on what I was doing. He wasn’t sure if the code was needed at all anymore, so now I am in the middle of testing that approach. We’ll have to test it and see.
A coworker who is somewhat more familiar with Eclipse Internals that I am explained some of the concepts behind this fix. It made sense, but I am not sure I am able to explain it myself yet. If I keep helping on the VSS Plugin, I better learn this stuff.
