[HACKYSTAT-DEV-L:17] Re: CDT and hackyEclipse

[Turker Keskinpala]

Mike and Philip, thank you for your corrections on my ideas and suggestions. I now have a better understanding on the big picture. I failed to look at the hackyStat as a complete system, but rather limited myself to the eclipse plug-in. <>Some initial general thoughts: * As Mike notes, there's no a priori reason why the Activity sensor for hackyEclipse needs to know whether it's working in JDT or CDT or FortranDT or whatever. The server-side analysis functions such as Telemetry support a FileFilterPattern method that allows you to do analyses on all *.java files, or *.c files, or *.cc files, etc.  So, if what you are interested in is Active Time for C or C++ development, then I think the best strategy is to simply make the current approach work generally for any *DT, then use server-side functions to get C-specific analyses. I completely agree with that. If the sensor were to know about specific *DT, then we would not be taking full advantage of the Eclipse platform. I did not know about the FileFilterPattern method on the server-side. I think using the server side functions is currently the best approach as well. This means that, I do not need to do anything extra for collecting basic activity data on C/C++ files. 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? * However, there do appear to be some Java-specific stuff that's crept into the code. It seems like the code should be refactored to enable certain capabilities depending upon the *DT that is active. That way, we can have some functionality that's Java-specific, and other functionality that's C-specific. I would be interested in how you would propose to provide such toolkit-specific To my understanding, one Java specific part in the code is in the ResourceChangeAdapter where the Java build errors are detected (detectBuildProblem method). The other part is obviously the JavaElementChangedAdapter. 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); 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. > For this purpose, I added ECLIPSE_PROJECT_NATURE property to my sensor.properties file. This > would be either javanature, ccnature, or cnature. So, if the nature is ccnature, the sensor > only collects activity data on C++ files. I again agree with Mike that it would work better if we could avoid this property altogether, and send general events (such as statechange) whenever possible and decide whether it's C or Java on the server side. For things that really are language specific, then maybe use the active toolkit type to decide whether to enable the functionality or not.     This property will not be there anymore:-) > Also, I am wondering if it would be a good idea to contribute a PreferencePage to configure > the plug-in instead of a sensor.properties file. It could make it easier to configure the > sensor. Again, is there a specific reason why we need a sensor.properties file? Yes. One of the basic design goals of Hackystat is to collect metrics from a wide variety of different tools in the developer's environment using tool-specific sensors.  Every sensor, regardless of the language it is implemented in and the tool it is supporting, needs upon startup to get the answers to at least the following questions:  What is the URL of the hackystat server I should send this data to? What is the 12 character key of the user to be associated with this data?  Does this user want me to be enabled at the current time?  The sensor.properties file provides a single "point of contact" for the answers to these questions for every sensor.  Doing it this way allows a user, for example, to one line in the sensor.properties file and then have all of their sensors start sending data to a different server. 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:-) Thank you for the time you take to answer my questions, thank you for your interest in my effort. The 'installer" project sounds good and I think it is a necessity. If I can meet my project's deadlines and if I can find more spare time I would be interested in that as well. But it is too hard for me to say anything now:-). Cheers, Turker