search

vazexqi / CodingSpectator

Watches and analyzes code edits in the Eclipse IDE non-invasively
http://codingspectator.cs.illinois.edu
Other
20 stars 14 forks source link

Eclipse doesn't capture some refactorings #218

Closed reprogrammer closed 13 years ago

reprogrammer commented 13 years ago

We've found some discrepancies between the set of refactorings captured by CodingSpectator/CodingTracker and Eclipse. The data from CodingSpectator and CodingTracker are consistent. That is, they report that the user has performed and kept the same set of refactorings. A refactoring is performed and kept if the user has performed it and not undone it. In summary, it looks like Eclipse doesn't record some refactorings. We need to find out why Eclipse fails to capture some refactorings and make sure that the refactorings that CodingSpectator counts as being performed are really committed by the user.

reprogrammer commented 13 years ago

CodingSpectator records the refactorings before their changes are actually performed. And, Eclipse could have bugs in recording refactorings. These are the two possible sources of differences that I can think of for the difference between the data captured by CodingSpectator and Eclipse.

reprogrammer commented 13 years ago

@vazexqi, @Wanderer777: CodingSpectator might submit the refactoring descriptors captured by CodingSpectator and Eclipse in different commits. When the user performs a refactoring, CodingSpectator logs the refactoring inside the watched directory. When the user restarts Eclipse, CodingSpectator copies the refactorings captured by Eclipse into the watched directory. CodingSpectator might submit the data before or after the Eclipse refactorings are copied. Therefore, CodingSpectator might or might not submit the refactoring descriptors captured by Eclipse in the same commit that contains the refactoring descriptors captured by CodingSpectator.

This phenomenon explains the missing refactoring from Eclipse logs. The refactoring descriptor wasn't missed. CodingSpectator just submitted it in a separate commit after the commit containing the CodingSpectator logs. In summary, we shouldn't expect the data in a commit to be consistent. We have to remember that some data might be kept to be submitted in the next commit.

reprogrammer commented 13 years ago

I suggest to change CodingSpectator such that it uploads the eclipse refactorings immediately and not postpone it to the next commit. Postponing the current data to future commits is confusing. For example, CodingSpectator puts the data collected by each version of it in a separate directory. If the user updates CodingSpectator before the collected data is submitted, the data might get put under the wrong version directory. I'm not sure how this could exactly happen. But, I think that I've seen it happen recently. Anyways, I think it's safer not to postpone the submission of collected data as much as possible. In this case, we need to add a hook to edu.illinois.codingspectator.monitor.ui.submission.Submitter.submit() before performing the svn add operation. Then, we'll have to use this hook to copy the eclipse refactorings.