One more thing you might notice for the resource change is that you might not start the root resource to traverse the entire resource tree to find the active editor's build error.
The main resource change which has been implemented in the EclipseSensor starts from the root resource because the status of the file saving is not neccessary to happen in one file so that it traverses the entire resource tree. However, in the C/C++ and Java build error case, you might just want to care the active file's build error. If this is the case, you can define the resource, that accepts the ResourceDelta, as the resource (IFile) of the active file. Then in the visite(IResourceDelta) method, you can return false to avoid taversing resource children. This will save Eclipse resource a lot. Cheers, Takuya On Sat, 04 Sep 2004 07:57:26 -1000 Philip Johnson <[EMAIL PROTECTED]> wrote: > > 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 > ================================ Takuya Yamashita E-mail: [EMAIL PROTECTED] ================================
