I see your point and agree with you. If Philip likes to make it optional
I'll do it. By the way, the CSDL case study is not designed to study
sensor adoption issues, I will make sure all the current members have
their build sensor enabled one way or another. Cheers, -Cedric
Aaron Kagawa wrote:
Ok. Well, I wrote this Jira Issue thinking of our users (other
Hackystat Administrators, who have no reason to "sense" their
installations of Hackystat).
I can make the same change to the portion of build.xml related to the
build sensor. However, since I will be starting the build case study
really soon, I am hesitant to make it optional.
I don't know what you are doing in your case study, but if you are
using the developers' data as part of your case study, then I would
claim an ANT enforcement isn't the correct way to ensure the data is
correct. After all, the developer could disable the sensor. Instead
of assuming that all developers are sending data, an analysis should
identify developers with missing data. For example, if a developer
has UnitTests and Commit data code but has no Build data then
something is wrong. Or, if a developer has Commit data but no
UnitTest and/or Build then something is wrong.
Just my 2 cents...
thanks, aaron
At 09:09 PM 9/22/2005, Qin ZHANG (Cedric) wrote:
Thanks, Aaron, I did not notice there is a <available class=..> task
in ant. That will solve your problem. In fact, this is not related to
how the sensor is implemented. It's a matter of how the build script
is written.
I can make the same change to the portion of build.xml related to the
build sensor. However, since I will be starting the build case study
really soon, I am hesitant to make it optional.
Perhaps we can just add the tip to the documentation.
Cheers,
Cedric
Aaron Kagawa wrote:
How about something like this?
<!--
***********************************************************************
-->
<!-- LOCC requires locc.jar and sensor.locc.jar in
ant/lib. -->
<!--
***********************************************************************
-->
<target name="checkLoccAvailable"
description="Sets locc.available if the locc resource is found.">
<available property="locc.available"
classname="csdl.locc.tools.ant.LOCCTaskdef"/>
<!--
<available property="locc.sensor.available"
classname="org.hackystat.stdext.sensor.ant.locc.LoccSensor"/>
-->
</target>
<target name="locc" depends="checkLoccAvailable" if="locc.available"
thanks, aaron
At 06:02 PM 9/22/2005, you wrote:
Hi, Aaron and everybody else,
I remember someone has brought up this question before.
We cannot check whether build sensor is installed in
installBuildSensor task or some other custom ant task, because it
still requires that you have the implementation code availabe in
the java class path or ant library.
Does Ant come with a task that allows us check whether a
particualar class or jar file is available or not? If yes, then
it's simple to satisfy your feature request. But the problem is I
don't think ant has such a task.
Or does anybody else have any idea?
Cheers,
Cedric
-------- Original Message --------
Subject: [JIRA] Created: (HACK-351) check if build sensor is
installed
Date: Thu, 22 Sep 2005 16:55:33 -1000 (HST)
From: Aaron A. Kagawa (JIRA) <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
check if build sensor is installed
----------------------------------
Key: HACK-351
URL: http://hackydev.ics.hawaii.edu:8080/browse/HACK-351
Project: Hackystat
Type: Improvement
Reporter: Aaron A. Kagawa
Assigned to: Qin Zhang Priority: Minor
is there any reason why we can't check if the build sensor is
installed before calling the installBuildSensor target? I think it
would be a good thing for users to be able to build the system
without having to install all the sensors.
this will be important when we remove the sensor.*.jar files from
out hackyBuild/lib/ant directory and use hackyInstaller instead.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators:
http://hackydev.ics.hawaii.edu:8080/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
