OK, let's clarify that there are at least three different scenarios here:
(1) Keep sensor.*.jar files under CVS control. This is what we do currently in hackystat.
The benefit of this approach is that users get the sensor.*.jar files automatically when
downloading from CVS. The cost is the need for someone to makes sure the CVS versions of
the sensor.*.jar files are up to date. The biggest problem with approach appears when
managing multiple projects, each of which use hackystat and require sensors, in that the
sensor.*.jar files from the various lib/ directories can clobber each other with
different versions.
(2) Don't put sensor.*.jar files under CVS control; provide an ant task to get the most
recent versions from the Hackystat server. This is what I have switched to doing in my
classes precisely because of the "multiple project problem" noted above. Here's what
updateAntLib (from StackyHack) looks like when you do it this way:
<target name="updateAntLib" description="Copies jar files implementing Ant extensions
to the ant.home/lib directory. ">
<!-- Obtain most recent versions of Hackystat sensors from the public server.
-->
<condition property="hackystat.server.available">
<http url="${hackystat.server}"/>
</condition>
<fail unless="hackystat.server.available"
message="The Hackystat server is not available at:
${hackystat.server}"/>
<echo message="Contacted ${hackystat.server}"/>
<get src="${hackystat.server}/download/sensorshell.jar"
dest="${ant.home}/lib/sensorshell.jar" verbose="on" usetimestamp="on"/>
<get src="${hackystat.server}/download/sensor.build.jar"
dest="${ant.home}/lib/sensor.build.jar" verbose="on"
usetimestamp="on"/>
<get src="${hackystat.server}/download/sensor.locc.jar"
dest="${ant.home}/lib/sensor.locc.jar" verbose="on" usetimestamp="on"/>
<get src="${hackystat.server}/download/sensor.jblanket.jar"
dest="${ant.home}/lib/sensor.jblanket.jar" verbose="on"
usetimestamp="on"/>
<get src="${hackystat.server}/download/sensor.junit.jar"
dest="${ant.home}/lib/sensor.junit.jar" verbose="on"
usetimestamp="on"/>
<get src="${hackystat.server}/download/sensor.dependencyfinder.jar"
dest="${ant.home}/lib/sensor.dependencyfinder.jar" verbose="on"
usetimestamp="on"/>
<!-- Copy remaining files from lib/ant and lib/jar directories. -->
<copy todir="${ant.home}/lib" preservelastmodified="true">
<fileset dir="${basedir}/lib/ant" includes="*.jar" />
</copy>
<copy todir="${ant.home}/lib" preservelastmodified="true">
<fileset dir="${basedir}/lib/jar" includes="junit.jar" />
</copy>
</target>
What's nice about this task is that w.r.t Hackystat sensors, it will have the same effect
regardless of what project's build.xml file you put it in; there is no possibility of
'clobbering' a sensor.*.jar file with an older sensor.*.jar file due to an outdated
version existing in the lib folder of a project. The cost of this approach is that once
you run updateAntLib, you do need to make sure your invocations of the sensors in your
build.xml file are compatible with the most recent version of the system. In my
experience, this is the less painful problem than the one in which you have different
projects that are mutually incompatible because they depend upon different versions of
the same sensor.*.jar file.
My proposal is that instead of using the Ant <get> task, we will substitute calls to
hackyInstaller (either via a <java> task or a custom Ant task). This change will
provide a more robust downloading/installation mechanism than the current <get> task.
(3) Another approach would be to make updateAntLib a dependent task of <init>, meaning
that updateAntLib is called every time you do a build and new sensors are thus
automatically downloaded and installed as soon as they become available. I think this is
the approach that Aaron is worried about in his email, and I agree that this is probably
not the best way to go; it's probably better to have developers maintain control over
when they decide to do the upgrade of their local sensor installation.
Every solution creates a new problem, and in this case the new problem is how to maintain
the hackyInstaller.jar file! We could either include it in the lib/ folder under CVS
control, or else download it from the server....
Cheers,
Philip
--On Thursday, August 04, 2005 8:27 AM -1000 Aaron Kagawa <[EMAIL PROTECTED]>
wrote:
Hey Guys,
Ok... I've been feeling a little uneasy about relying on HackyInstaller for all
updating of our Build sensors (ie. LOCC, JUnit, etc). Here is why.
Currently, we store these sensors in the hackyBuild module under version
control. Now
that we are probably going to move these sensors out of version control and
just use
HackyInstaller to manage these sensors we might run into problems.
A significant change in an Ant based sensor also could mean that the tool (ie,
LOCC,
JBlanket) has been significantly changed. Therefore, users that just update the
JBlanket sensor without updating JBlanket will be totally confused when their
sensor no
longer works. Not to mention, that all of a sudden their build.xml code could
be
invalid.
In my CLEW build process (which is very similar the Hackystat build process), I
was
responsible for ensuring that everyone had the right Ant based sensors, Ant
tools (ie
LOCC, JBlanket), and the right build.xml code. However, if I change CLEW's
build
process to use HackyInstaller, then that control is now out of my hands.
Again, here
is an example. A while back when the Ant Build Sensor was in development the
necessary
build.xml code was changing quite frequently. Luckily, since we had a "working"
version of the build sensor in CVS we didn't need to worry about the changes
till we
decided to uniformly upgrade to the new Build sensor. Now, imagine if we were
using
HackyInstaller. Once a couple of my developers upgraded the build sensor
causing a
broken build, I'd probably have to change the build.xml on the spot (which is
debatable
on whether that is a good or bad thing).
Anyway, I'm just saying that as a Manager of a project using Hackystat sensors
it seems
easier to manage the sensors while they are under version control than under
HackyInstaller control. When these sensors are under CVS, I can be fairly
certain that
everyone is using the same sensors, which might not be the most current ones,
but at
least I know we should have the same ones. On the other hand, if we rely on the
HackyInstaller GUI interface to update these sensors we probably would have a
large
range of different versions amongst our developers.
Then again, this might not be a problem if sensors our sensors don't change
very much.
thanks, aaron
