--On Tuesday, November 8, 2005 10:31 AM +0100 Sebastian Jekutsch
<[EMAIL PROTECTED]> wrote:
Dear Philip,
I suggest to make the path field optional. Lots of events do not
naturally involve a file like running the project, or invoking ant, etc.
This is a key point: we _can't_ make the "path" field optional! Or, at
least we can't without making some other arrangement for associating a
workspace with sensor data.
One of the fundamental requirements for Hackystat is that it should allow
developers to switch between different tasks (i.e. Hackystat "projects").
The way we figure out what specific task(s) a developer is working on at
any given time is by associating a workspace (file path) with each piece of
sensor data.
We have experimented before with sensors where you simply specify the
project ID directly. This can work, but it is quite brittle (the user can
define new projects or delete old ones at the server, and typically does
not remember to update the sensor to reflect the new project name(s). Also,
what about the old data...) We eventually ended the experiment and moved
back to specifying a file path.
So, rather than make the path field optional, one has to instead think
about how, for a particular type of sensor data, one can find a reasonable
path to associate with it which will "identify" this sensor data for use in
project definition. Sometimes this takes a little creativity, and
sometimes it becomes a show-stopper.
Here's an approach that just occurred to me: what if it was possible for
sensor data to "borrow" a file path from "neighboring" sensor data that
occurred close in time to this sensor data? That way, if you are doing a
collection of activities, some of which are easy to provide a file path
for, and some of which aren't, the analysis mechanism could infer a
workspace for sensor data that wasn't sent with it.
This doesn't make the file path optional, from my point of view, what is
does instead is provide a way to obtain a default value for the file path
in some circumstances.
Regarding "Method Creation": Are you sure that an ElementChangedEvent's
IJavaElementDelta doesn't provide an getKind() == IJavaElementDelta.ADDED
and getElement().getElementType() == IJavaElement.METHOD? This may only
work via programmatically added methods (e.g. from Eclipse's refactoring
actions) not by typing in a new method, though.
Hongbing?
Cheers,
Philip
