I think the sensors should accommodate our need instead of the other way
around. There are several options:
(1) Change the build sensor so that you can specify a fake path. But
this only sounds like a temporary solution.
(2) Change your workspace root to "c:\svn", and define your project
containing one single workspace "simpleProject". Some analysis accepts
file pattern parameter, use it to specify the module you want to run
analysis on. But this approach is not entirely compatible with how
workspaces should work as we envisioned.
(3) Philip had once mentioned he was thinking about redesign project
definition mechanism. This seems to be a promising long term solution. I
guess we need to set up a web page to accumulate the requirements for
such redesign.
Cheers,
Cedric
Aaron Kagawa wrote:
Hey Guys,
I came across two interesting little problems with build data.
Problem 1: sending build data from the root
First, let me explain the situation. Imagine a software project that
contains modules, much like Hackystat's modules (ie, hackyCore_Kernel,
hackySdt_Issue, etc). Now imagine that the software project is built
from the root directory instead of the hackyCore_Build. The reason
for this is that the ant build file is relatively simple and there
seems to be no reason why we should have a separate module just for
the build files in the project. So, we have something that looks like
c:\svn\simpleProject\build.xml
c:\svn\simpleProject\fooModule\build.xml
c:\svn\simpleProject\fooModule\src\...
c:\svn\simpleProject\barModule\build.xml
c:\svn\simpleProject\barModule\src\...
Currently, the way to configure this project in Hackystat is to select
"c:\svn\simpleProject" as a workspace root and add "fooModule" and
"barModule" as top level workspaces in a Hackystat project. This works
fine. Sensor data like FileMetric, UnitTest, Activity, Coverage, etc
all seem to work fine with this setup.
However, the Build data is the only exception, because one would
execute the build with this command.
c:\svn\simpleProject>ant build
Sending Build data that looks like
#> Build [add, result=Success, target=build, tool=Ant,
path=c:\svn\simpleProject, pMap=.....]
You should see the problem by now.... c:\svn\simpleProject is a
Workspace Root. It is not associated with the simpleProject Hackystat
project, because it isn't a top level workspace.
What should I do to solve that problem? Should I create a
c:\svn\simpleProject\buildModule\build.xml just because Hackystat
requires it to associate my Build data with the simpleProject? I
think I wouldn't be comfortable making a change to simpleProject's
module organization just because Hackystat requires it.
One idea that I had was that maybe the Ant Build sensor can take a
buildPath argument.
<hacky-build
verbose="true"
debug="false"
monitorCheckstyle
="true"
monitorCompilation
="true"
monitorJUnit
="true"
buildPath="ant-build" />
This argument would change the build entry to look something like
#> Build [add, result=Success, target=build, tool=Ant,
path=c:\svn\simpleProject\ant-build, pMap=.....]
By doing this, I can associate the ant-build directory with the
simpleProject by making it a top level workspace. Do you guys have
any other solutions? Comments?
Problem 2: builds in a module
Currently, our build process allows the developer to build a single
module. The build process also takes care of the dependencies
associated with that build. For example, a developer could just build
fooModule by executing
c:\svn\simpleProject\fooModule>ant build
Since, the build sensor is installed and fooModule is a top level
workspace I see data for that build in the Daily Project Details
analysis. However, what I don't know is what module the developer
built. In my example project a build from
c:\svn\simpleProject>ant build
c:\svn\simpleProject\fooModule>ant build
c:\svn\simpleProject\barModule>ant build
signify to met that the developer is working on certain portions of
the system and I would want to which portions of the system is being
built.
So, to solve this problem maybe we could change the axes to Build
Invocations (Successful/Fail) by User and Top-Level Workspace.
thanks, Aaron
