Hi Aaron,

Extremely interesting.  I am thinking about this and will respond with some 
ideas soon.

Cheers,
Philip

----- Original Message -----
From: Aaron Kagawa <[EMAIL PROTECTED]>
Date: Friday, June 9, 2006 1:12 pm
Subject: [HACKYSTAT-DEV-L] Build data issues in a multi-module project
To: [email protected]

> 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
> 
> 
> 

Reply via email to