Wanderer777

CodingSpectator detects compilation problems before a refactoring is about to be performed/undone/redone and after a refactoring failed (see `RefactoringProblemsListener#historyNotification(OperationHistoryEvent)`). CodingSpectator correctly computes the set of affected compilation units before a...

@reprogrammer: It depends on your expectations of what should be logged to `refactoring-problems.log` file. If CodingSpectator should record compilation problems before a refactoring, then this is a bug in the...

@reprogrammer: I am not sure that CodingTracker should capture `description` and `comment` attributes. First of all, it would not help with the existing data. Also, it is not needed for...

@reprogrammer: You can use method `edu.illinois.codingtracker.operations.refactorings.NewStartedRefactoringOperation.getArguments()` to get a map of arguments of a particular refactoring, among which you would be able to find the description of the refactoring, if...

@reprogrammer: CodingTracker captures `project`, `id`, `flags`, and `arguments`. I thought that `description` might make part of arguments. Since it does not, it is not recorded by CodingTracker (as well as...

@reprogrammer: This is a low priority issue, mostly a memo. The current version of CodingTracker collects sufficient information. Later, if we need to analyze code changes specific to conflict editors...

### Eclipse fails to rename a method in a Java project that transitively depends on the project that declares this method. If each of the following three classes is in...

CodingTracker uses class `Properties` to keep track of the known files. This class is thread-safe only starting with Java 1.6. So, we either keep Java 1.6, or if we lower...

I think that a more precise measure of the duration would be to get the timestamps of the first and the last operations recorded by CodingTracker.