One possible improvement is to move this stuff into its own file: antsensor.build.xml,
and import that file in build.xml.
This leads to two cases:
(1) someone checks out Hackystat from SVN (who is presumably a developer-level person).
This person would have to install the ant sensor (using the normal hackyInstaller method)
in order to do a build. (They could specify the sensor as "not enabled" if they don't
want to collect data). No need to include <classpath> etc.
(2) someone downloads a pre-built distribution (who is presumably a
user/administrator-level person). When building such a distribution, we would substitute
a basically 'empty' antsensor.build.xml file for the regular one. This would result in no
references to the ant sensor, and thus no need to install the sensor in order to build
and run the distribution.
How does this sound?
Cheers,
Philip
--On Wednesday, November 09, 2005 1:18 AM -1000 "(Cedric) Qin ZHANG" <[EMAIL PROTECTED]>
wrote:
The change as suggested by Philip is to put the following element top level
(i.e.
outside any target)
<taskdef name="hacky-build"
classname="org.hackystat.sensor.ant.BuildSensorInstallationAntTask" >
<classpath>
<pathelement location="${basedir}/sensor.ant.jar"/>
</classpath>
</taskdef>
<hacky-build .../>
1. It means we need to put both "sensor.ant.jar" and "sensorshell.jar" in
hackyCore_Build.
2. After removing the old "installAntSensor" and made the changes above, I
encountered
weird ant behavior: the ant sensor is loaded twice, and two instances of the
sensor
works at the same time.
If I get rid of "classpath" in "taskdef" (which implies putting
"sensor.ant.jar" in
ant lib), then everything is normal.
In the ant sensor code, I have code that specifically checks whether the user
is trying
to install the ant sensor more than once (recall the sensor is implemented as
an Ant
listener), and prevents subsequent installation of the sensor. The above weird
behavior
seems to suggest that ANT has somehow created two contexts. I am not sure
whether it's
a ANT bug, but I'll try to do some googling tomorrow.
3. The changes to the build script are NOT committed.
Cheers,
Cedric
dency target is not right:
The build sensor is loaded when you use freshStart, quickStart,
all.junit, all.compile,
etc. But when I am developing software, most of the time, I only care
my own module and
use ant command like "ant hackyApp_BuildAnalysis.junit" or "ant
hackyApp_BuildAnalysis.checkstyle". In those cases, the build sensor
will not be
loaded, because those taskes are not dependent on "checkProperties".
I went over our entire build script, it seems there is no target
which all other
targets depend on.
Hmm. The only solution I can see right now is to do the taskdef and
invocation of the build sensor at top-level, outside of any target.
That should solve your problem, but it introduces another: the
requirement that the build sensor be made available in all
distributions of Hackystat. I suppose that isn't the end of the
world. Try this approach out and see if it seems reasonable.
(Probably want to use the "classpath" attribute in the taskdef so that
the user doesn't need to add the sensor to ant/lib.)
