--On Friday, December 9, 2005 4:29 PM +0700 thang nguyen wrote:
Dear Philip Johnson,
Now I try to write own sensor data type but I have some problem. See
below for more detail:
There was 1 error:
testSdt(org.hackystat.stdext.DTS.sdt.TestDTS)org.hackystat.kernel.sdt.Sen
sorDataTypeException : Unknown SDT: DTS (new sensor data type called DTS)
at
org.hackystat.kernel.sensordata.SensorDataEntryFactory.getEntry(SensorDat
aEntryFactory.java :171)
at org.hackystat.stdext.DTS.sdt.TestDTS.testSdt(TestDTS.java:46 )
Hi Thang,
Wow, I'm impressed with your motivation! Unfortunately, you are a little
bit ahead of our developer documentation on the kind of thing you are
trying to do. I hope to have this documentation written within the next
three months, which will provide a step-by-step guide to this kind of
enhancement, but for now you will have to just struggle along.
Here's an overview of the steps you need to follow:
1. From your error trace, I can see that you are using Version 6 of
Hackystat. Integration of new SDTs is _much_ simpler in Version 7 (in
fact, that was a major design goal of Version 7). So, the first thing to do
is to download the _sources_ of Version 7 from Subversion. See the
Administrator documentation or the http://www.hackystat.org home page for
instructions on how to do that.
2. Make sure you can build and run Hackystat from your source distribution.
Remember to run AutoConfig to generate the modules.build.xml file and a
sample.hackystat.build.properties file (which you will rename to
hackystat.build.properties.) You can comment out a lot of the modules in
hackystat.build.properties. For your current purposes, I suggest you
comment out all of the hackySensor* and hackyApp* modules, which will leave
just the hackyCore and hackySdt subsystems. That will make the build run
reasonably quickly.
3. Once you have your own local configuration of Hackystat V7 running from
sources, the next step is to create a new hackystat module directory
containing your new SDT definition in the same directory as the other
hackystat public modules. Given your error trace, you will probably want
to call this module/directory hackySdt_Dts. What I suggest you do is look
at the current SDT modules, find one that is close to what you need, and
use it as a template for creating your hackySdt_Dts module.
4. Once you have your hackySdt_Dts module ready for testing, you should run
AutoConfig again. What that will do is "discover" your new module
directory, and rewrite the modules.build.xml file to include references to
it for (potential) use in the build. It will also generate a new
sample.hackystat.build.properties file that includes a line like:
hackySdt_Dts.available=true
You will need to include that line in your hackystat.build.properties file
so that the build system knows to include your new module when actually
doing a build.
5. Now you can actually attempt to build your configuration, using one of
the standard build commands like 'ant -q freshStart all.junit'. Indeed, by
this point, you might want to comment out all of the hackySdt* modules
_except_ your hackySdt_Dts module from the hackystat.build.properties file,
so that you don't waste time during your test builds on any SDT modules but
yours.
The hard part, of course, is Step 3. If you can find an existing public
Hackystat SDT module that is quite close to what you need, and if you can
carefully go through every file in that module and make sure you update
references to the old SDT to your new SDT, then you should be OK. What I
will do in the developer documentation is explain _why_ things are designed
the way they are, so that developers like you can understand how to do more
than simply cut-and-paste.
Good luck!
Cheers,
Philip
