> 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?
Sounds good to me too.
> > 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);
This change seems only supporting C/C++ problem marker so that you still can
not support both C/C++ and Java. I guess you and we have to change the
resource chage structure in such a way that each langauge specific
resource change listener should be imeplemented apart from the main
resourche change adapter which has been already implemented in the
EclipseSensor. My propose is that:
[Java]
JavaResourceChangeAdapter implements IResourceChangeListener, IResourceDeltaVisitor {
...
public boolean visit(IResourceDelta delta) throws CoreException {
...
detectJavaBuildProblem();
...
}
}
[C/C++]
CResourceChangeAdapter implements IResourceChangeListener, IResourceDeltaVisitor {
public boolean visit(IResourceDelta delta) throws CoreException {
...
detectCBuildProblem();
...
}
}
After creating own language adapter, you can add them to
workspace.addResourceChangeListener(new CResourceChangeAdapter());
This would enable sensor to extend any language in the future which
would be supported in Eclipse.
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]
================================
