Hi, Philip & Cedric,
I took a look at build.xml and antsensor.build.xml. I think junit sensor, locc
sensor ... are already handled well
by checking the availability before invoke the sensor. Below is the junit
sensor :
<!-- ***********************************************************************
-->
<condition property="junit.sensor.available">
<available classname="org.hackystat.sensor.junit.JUnitSensor"/>
</condition>
<target name="hackyCore_Build.junit.hackystat.sensor"
if="junit.sensor.available"
description="Sends the current JUnit report data to the server specified in
your sensor.properties file.">
<taskdef name="hacky-junit"
classname="org.hackystat.sensor.junit.JUnitSensor" />
<hacky-junit verbose="${hackystat.sensor.verbose}">
<fileset dir="${junit.report.dir}">
<include name="**/TEST-*.xml"/>
</fileset>
</hacky-junit>
</target>
We do not need to have a fake hacky-junit for distribution reason. However, the
build sensor is the problematic one. Unless we want to keep it as it is, there
is one way to solve it (as we did before):
In build.xml we can define the ``init" task to let other task depend on it.
Inside it we can put build sensor installation.
<!-- ***********************************************************************
-->
<condition property="build.sensor.available">
<available
classname="org.hackystat.sensor.ant.BuildSensorInstallationAntTask"/>
</condition>
<!-- Init and install build sensor. -->
<target name="init" if="build.sensor.available" description="Install build
sensor if available.">
<taskdef name="hacky-build"
classname="org.hackystat.sensor.ant.BuildSensorInstallationAntTask" />
<hacky-build verbose="${hackystat.sensor.verbose}" debug="false"
monitorCheckstyle="true" monitorCompilation="true"
monitorJUnit="true"
keyValuePairs="configuration=${hackystat.build.configuration},buildStartType=${hackystat.build.starttype}"
/>
</target>
Any problem with this solution?
Hongbing
----- Original Message -----
From: "Philip Johnson (JIRA)" <[EMAIL PROTECTED]>
Date: Sunday, November 27, 2005 7:16 am
Subject: [JIRA] Created: (HACK-423) Use 'dev' and 'dist' versions of
hackystat.sensor.build.xml to manage sensor installation requirements
To: [EMAIL PROTECTED]
> Use 'dev' and 'dist' versions of hackystat.sensor.build.xml to
> manage sensor installation requirements
> --------------------------------------------------------------------
> ----------------------------------
>
> Key: HACK-423
> URL: http://hackydev.ics.hawaii.edu:8080/browse/HACK-423
> Project: Hackystat
> Type: Improvement
> Reporter: Philip Johnson
> Assigned to: Hongbing Kou
> Fix For: 7.0
>
>
> So, here's the deal:
>
> We want to instrument the development process for Hackystat, i.e.
> we want to have hackystat sensors monitoring hackystat development
> itself.
> However, we don't want our external installers of the Hackystat
> server to have to install Hackystat sensors just so they can
> install a Hackystat server from a binary distribution.
>
> Finally, we don't want to use <antcall>, because it's slow and
> bogus.
>
> This is a problem. :-)
>
> Here's the best solution I have come up with so far.
>
> We already know that we have to have different versions of
> antsensor.build.xml file for the development environment (i.e. what
> you get when you download the sources from SVN) and the
> distribution environment (i.e. what you get when you unpack
> hackystat-<config>-<version>.zip). By having different versions
> of this file, it allows us to have a 'real' implementation of the
> Ant sensor when doing development (which requires developers to
> actually install the Ant sensor) and a 'fake' (no-op) version of
> the sensor in the distribution environment (which does nothing when
> called, and does not require people to install the Ant sensor in
> order to install a server).
>
> I propose that we generalize this approach to _all_ Hackystat
> sensors that we want to use in our Ant build system for Hackystat.
> Instead of an antsensor.build.xml file, we'll have a
> hackystat.sensor.build.xml file. This file will be imported in
> build.xml. The version of hackystat.sensor.build.xml in SVN will
> basically contain a set of taskdefs, such as
>
> <taskdef name="hacky-junit"
> classname="org.hackystat.sensor.junit.JUnitSensor" />
>
> People doing development in Hackystat will thus be required to
> install all of these sensors. (Hey, you're a Hackystat developer,
> you're supposed to _like_ installing sensors. :-) The rest of the
> build system files invoke the sensors in the normal way, such as:
>
> <hacky-junit verbose="${hackystat.sensor.verbose}">
> <fileset dir="${junit.report.dir}">
> <include name="**/TEST-*.xml"/>
> </fileset>
> </hacky-junit>
>
> Here's the tricky part. When creating the destribution zip file,
> we include a 'fake' version of hackystat.sensor.build.xml. This
> file doesn't contain the taskdefs for the sensors. Instead, it
> contains a set of macrodefs that 'simulate' the syntax of the
> actual sensor tasks, but don't do any actual work. For example:
>
> <macrodef name="hacky-junit">
> <attribute name="verbose" default=""/>
> <element name="fileset" optional="yes"/>
> <sequential>
> </sequential>
> </macrodef>
>
> Thus, the build system in a distribution can still invoke <hacky-
> junit> and Ant won't complain, but of course no sensor data will be
> collected.
> We can keep a file called 'dist.hackystat.sensor.build.xml' in the
> lib directory, and copy it over to hackystat.sensor.build.xml when
> making distributions. It should change very slowly, and so we can
> maintain it by hand.
>
> Comments?
>
> Cheers,
> Philip
>
>
> --
> 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
>
>
