Greetings, hackers,
Recall that there were two problems identified with SensorShell in Version 6:
(1) sensorshell.jar redundantly includes all of the classes in sensor.*.jar; this means
that users could inadvertantly "install" sensors they didn't mean to install by
installing sensorshell.jar. We decided that we wanted to get rid of the duplicate
classes from sensorshell.jar.
(2) sensorshell.jar includes other libraries. At least one external site (thoughtworks)
had library conflicts and needed to unjar/rejar sensorshell to resolve them.
It turns out that solving problem (1) is trivially easy with the version 7 package
structure--we just exclude org.hackystat.sensor.* when creating sensorshell.jar! Indeed,
we can go one step further and exclude org.hackystat.app.* to get rid of the application
level code as well! (To be honest, I will actually implement this with
includes="org/hackystat/core/**, org/hackystat/sdt/**" so that if we decide to add more
subsystems, we won't start including them by mistake in sensorshell.)
Now, this has an implication for the current porting of the sensor module code: be sure
that you don't copy any third party libraries that your sensor might need into the
install.sensorshell.dir directory.
Resolving problem (2) might be more complex. While some sensors (such as those based
upon Ant) might be fine with a "decomposed" version of sensorshell.jar (since all you
have to do is alter the hackyInstaller definition to download the other libraries into
ant/lib), some other sensors might find it inconvenient to have to deal with a half dozen
jar files instead of just a single sensorshell.jar.
One way out of this would be to have sensorshell.jar continue to have all of the
libraries included in it, but also create a sensorshell.nolibraries.jar that does not
contain the libraries. Each sensor definition could decide whether it wants to install
the libraries separately or bundled. Does this seem reasonable?
Cheers,
Philip
