Is the file filtering function currently an option on the server-side on the Analysis page? I did not see such filtering, but I might have overlooked. If it is not currently there, I guess it means I will need to get into that part of the development at some point, right?
File filtering is an integral part of our Telemetry package. If the kinds of analyses you need are telemetry-based, then you should be in good shape.
I looked at the detectBuildProblem method a little more carefully now, and I noticed one problem. It is written in such a way that it skips non-java files. It gets the file that is open in the active editor, checks its extension, and returns if it is not java. This works perfectly, if the java file is active and is saved which yields to auto build. However, if you disable auto build, and do a Build Project on a Java Project when there is a non-java file opened in the active editor then the function returns without getting the build errors even though the project is built. Finding this out made me think that checking active file extension may not be the most robust way to decide which action to chose. Once a better way is found, it is just a matter of one line of code to change in this method to collect CDT build errors.
markers = fileEditorInput.getFile().findMarkers( IJavaModelMarker.JAVA_MODEL_PROBLEM_MARKER, true, IResource.DEPTH_INFINITE);
should be changed with
markers = fileEditorInput.getFile().findMarkers( ICModelMarker.C_MODEL_PROBLEM_MARKER, true, IResource.DEPTH_INFINITE);
Can you check what the 'open project' type is, and attach a listener to 'build project on a Java project', so that you can figure out which of these you need?
For the *ElementChangedAdapter, I already wrote the CElementChangedAdapter that would replace JavaElementChangedAdapter. I think both of these listeners may be added to the sensor since they are listeners in different nature. The workbench should call the proper one. I added CoreModel.getDefault().addElementChangedListener(new CElementChangedAdapter(this)) and the proper listener has responded to changes.
Seems reasonable to me. Takuya?
This explains the existence of the sensor.properties and why it is not a good idea to make it tool specific. Now that I think of it again, I should have targeted the Eclipse Sensor customization instead of sensor.properties file. Why cannot a specific sensor (Eclipse Sensor, in my case) have preferences which could further customize the sensor just for collecting data about the inherently language specific functions? These preferences would not in any way affect the sensor.properties file nor would they affect the common "point of contact" for every sensor. If the user is working on a Java project she might configure the sensor so that it deals only with Java build errors or Java element changes. This way, it would also be very easy to switch between *DTs for language specific functions. Apart from that, the sensor would continue to collect activity data regardless of the *DT. Just another idea:-)
A Preferences page for Eclipse-sensor specific customizations is more reasonable at first glance. The problem again, looking downstream, is what forms of customization are truly Eclipse-specific? You see, part of what Hackystat is intended to provide is an environment where developers are not dictated by the metrics tool regarding what tools they use. If one developer wants to use Eclipse, but another wants to use Emacs, that should be OK. Someone like me actually uses both editors on a daily basis.
Because of this situation, there is a kind of constant requirements pressure to put things into sensor.properties, and to ensure that a capability that exists in one editor also exists in other editors. In reality, that doesn't always occur; things like Buffer Transitions started in Emacs, was added to Eclipse as well, but has never gotten to JBuilder, for example.
At the end of the day, I still think this all points to the need to have a better client-side GUI interface to sensor.properties.
Cheers, Philip
