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

Reuse CodingTracker for storing data while a submission is in progress #149

Closed reprogrammer closed 13 years ago

reprogrammer commented 13 years ago

CodingSpectator submits the watched directory while Eclipse is starting up. And, subversion reverts any changes made to the watched directory while it's being committed. Therefore, CodingSpectator writes data into the watched directory only after the startup event of Eclipse is finished. So far, CodingSpectator stores two kinds of data into the watched directory:

  1. refactorings
  2. usage data collector

Refactorings are performed after the Eclipse has started up. So, there's no way that a refactoring event overlaps with the submission of the watched directory unless the user initiates the submission manually. Because of the low likelihood of a refactoring event to overlap with the submission, we've ingored the potential problem here. We copy the UDC data into the watched directory while Eclipse is being started up. But, the UDC data doesn't have to be transferred instantly. So, we can delay the transfer of the UDC data until the submission is finished (See issue #55).

CodingSpectator is going to capture the events reported to the error log of Eclipse (See issue #143). The error log notifies its listeners whenever it receives a new event. CodingSpectator is going to add a listener to the error log that would store the new event in the watched directory. The events of the error log might arrive while Eclipse is being started up. So, writing to the watched directory might overlap with submitting the watched direcoty. Besides, we cannot block the listener of the error log and thus the error log for a possibly long period. Therefore, CodingSpectator cannot block the error log and wait until the submission is over.

CodingTracker had a similar problem when trying to write data into the watched directory while the submission is in progress. I think the solution that CodingTracker finally implemented is the following: if a submission is in progress and some data has to be saved, it writes the data into a temporary file that is not added to the repository until the submission completes. And, when the submission is done, it copies the data back into the watched directory (issue #84).

Since CodingTracker has already implemented a solution for overlapping the storage of data and submission of the watched directory, it would be great if CodingTracker could make this functionality available to CodingSpectator. Right now, issues #140 and issue #140 demand this functionality.

Wanderer777 commented 13 years ago

We are going to extract the CodingTracker logger to a separate plugin such that it could be used both by CodingTracker and CodingSpectator.

reprogrammer commented 13 years ago

Resolved in 6f2b13f3125a79d990f432c6cdd76b1cfb1864ac.

reprogrammer commented 13 years ago

"edu.illinois.codingspectator.codingtracker.operations" depends on "org.eclipse.jdt.ui.tests". And, "org.eclipse.jdt.ui.tests" depends on "org.eclipse.test.performance" and "org.eclipse.text.tests". So, I added "org.eclipse.jdt.ui.tests", "org.eclipse.test.performance" and "org.eclipse.text.tests" to "edu.illinois.codingspectator.feature/feature.xml" (See 83d9dba7b95a98115eba44c227cf0364600c9fc7 and 8f5f7d3f1c27c65bb1e32a50b57761966b754d98).

reprogrammer commented 13 years ago

@Wanderer777,

I've added three plugins "org.eclipse.jdt.ui.tests", "org.eclipse.test.performance" and "org.eclipse.text.tests" to satisfy the new dependencies of CodingTracker. Could you confirm that these plugins are required by CodingTracker. Also, I think including these three plugins is a pretty heavy-weight solution. It looks like you only need a few classes of "org.eclipse.jdt.ui.tests". Is it possible for you to extract those few classes into a separate plugin? If this separate plugin turns out to be small, we'll include that into the CodingSpectator feature instead of the three huge plugins.

vazexqi commented 13 years ago

Just FYI. These three plugins "org.eclipse.jdt.ui.tests", "org.eclipse.test.performance" and "org.eclipse.text.tests" are used internally for CodingSpectator when we run the tests. But they are not included in the distribution for CodingSpectator.

reprogrammer commented 13 years ago

@vezexqi,

You're right. But, I've included the three plugins in the new distribution of CodingSpectator because of the new dependencies of CodingTracker.

vazexqi commented 13 years ago

Did you modify the .gitignore files to include them? I just noticed that in the current .gitignore file that those three are ignored.

Wanderer777 commented 13 years ago

Right, plugin "edu.illinois.codingspectator.codingtracker.operations" depends on plugin "org.eclipse.jdt.ui.tests", which depends on plugins "org.eclipse.test.performance" and "org.eclipse.text.tests". Some time ago I looked at this dependency, and I found that it involves many classes, therefore I decided not to extract them into a separate plugin. I will double check.

reprogrammer commented 13 years ago

@vazexqi,

Since we haven't modified any of the plugins "org.eclipse.jdt.ui.tests", "org.eclipse.test.performance" and "org.eclipse.text.tests", we don't need to add them to the github repository. Therefore, it's fine to keep them in .gitignore.

Wanderer777 commented 13 years ago

It appears that only a couple of classes needed to be extracted in a separate plugin (all others are from dependencies on the other plugins). I extracted these classes in a separate plugin "edu.illinois.codingsectator.codingtracker.eclipse" (feel free to rename it, if needed) and got rid of the dependency on the three plugins mentioned above. Please update feature.xml accordingly.

The above is addressed in 360156c1d83d1f81088efd365ac3b25475a21c6f