No, I don't think your analysis is correct. The problem is, how/where will hackyCore_Build.junit.hackystat.sensor actually be invoked?
Some more details: * We need to call the junit sensor each time junit data is generated by a particular module (to avoid resending old data). * We don't want each module to define their own junit sensor (or checkstyle sensor, etc.) task. Therefore, the junit sensor must run inside the <makeJUnit> macrodef. * We don't want to use antcall inside the <makeJunit> macrodef. * Therefore, we need to put a call to <hacky-junit> directly inside the <makeJunit> macrodef. * Therefore, we need to always have <hacky-junit> defined in both dist and dev versions. Does that clear things up? Cheers, Philip ----- Original Message ----- From: Hongbing Kou <[EMAIL PROTECTED]> Date: Sunday, November 27, 2005 12:12 pm Subject: Re: [HACKYSTAT-DEV-L] [JIRA] Created: (HACK-423) Use 'dev' and 'dist' versions of hackystat.sensor.build.xml to manage sensor installation requirements To: [email protected] > 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 > requirementsTo: [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 > > > > >
