How do we attach the Project information in the build?
That depends. In the Ant Build sensor, there is an attribute called "ProjectID" that is used to provide the Project name. For details:
<http://hackystat.ics.hawaii.edu/hackystat/docbook/apas03.html>
I guess I really don't understand what a Project is and how you intend it to be used.
A Project represents: - A set of users - A time interval during which the Project is active and data should be associated with it. - A set of workspaces which specify the set of files to be associated with this project.
Most sensors associate a file with each sensor data record. That enables the Project to be inferred from the sensor data. When we originally defined the Build SDT, we didn't see an obvious file to associate, so we decided instead that the user would have to specify the unique ID of the Project explicitly.
Upon reflection, perhaps that was not the correct decision. We could, for example, send the fully qualified path to the build file (i.e. build.xml or Makefile) and use that to infer the Project.
For more details on Projects, see:
<http://hackystat.ics.hawaii.edu/hackystat/docbook/ch03s05.html>
I've been using the same ant script for multiple projects, phase 1, phase 2, etc. Do I have to change the build script each time I change the project?
Currently, yes.
What if I'm working on two projects that are sub parts of the whole and run the whole build script to make sure things are still working?
One of the other things that is coming out of the current discussion on Build is that the "ProjectID" field should perhaps be "ProjectIDs". In other words, it should support a list of Projects, not a single Project.
What is the project for that build failure? And how is Hackystat supposed to figure it out?
If you specify two projects to be associated with a build invocation, and there's a failure, then I suspect there's no way in general for Hackystat (or any other Turing Machine) to reliably figure out which Project is responsible for the failure. (Otherwise it's likely one could solve the Halting Problem).
So, of course, there's limits to what Hackystat can do here in general, as well as limits to what the current Build mechanism can do here in particular.
I've always been uncomfortable with the fact that the ProjectID has to be specified explicitly---as you bring up, it means the ProjectID value now has to be maintained in the build.xml file. It would be much better, for example, to be able to supply a fully qualified file that can be used to associate the build with one or more Projects. Then, for example, in the case of your Phase 1, Phase 2 sequence, the time interval associated with the two phases can be used to figure out which build data goes with which Project without having to make any changes to the build.xml.
As long as we're radically revising the Build SDT, let's open up this question for general discussion:
Should we change the "ProjectID" field in the Build SDT to a "BuildFile" field, and use the workspace associated with that fully qualified file name to determine the Project?
Does anyone see any problems with that change?
Cheers, Philip
