Setting up your own detector for evaluation in MUBench is simple:
- Implement a MUBench Runner for your detector.
- Place an executable JAR with your runner at
detectors/<mydetector>/latest/<mydetector>.jar
. - Add detector version and CLI version information to
/detectors/<mydetector>/releases.yml
. - Run benchmarking experiments using
<mydetector>
as the detector id.
If you have a detector set up for running on MUBench, please contact Sven Amann to publish it with the benchmark. Feel free to do so as well, if you have questions or require assistance.
To run your detector in MUBench experiments, you need to configure a MUBench Runner that invokes your detector and reports its findings to the MUBench Pipeline.
We provide infrastructure for implementing runners in the Maven dependency de.tu-darmstadt.stg:mubench.cli
via our repository
http://www.st.informatik.tu-darmstadt.de/artifacts/mubench/mvn/
Check the MUBench CLI documentation for details on how to implement runners and other utilities available through this dependency.
Once you configured the runner, you need to bundle it together with your detector into an executable Jar. This Jar must have the runner as its entry point.
See the configuration of the maven-assembly-plugin
in the pom.xml
file for an example of how we do this for our DemoDetector
.
Each detector has a releases.yml
file that provides version information.
The most-simple version of such a file, which suffices to run a detector locally, might look as follows:
- cli_version: 0.0.13
md5: foo
- The
cli_version
names the version of themubench.cli
dependency used to implement the respective MUBench Runner. - The
md5
might be any string. When running experiments, the MUBench Pipeline uses this string only to determine whether the detector changed (by checking whether themd5
changed) and to invalidate existing results accordingly. Only when the detector is integrated into the MUBench detector repository, such that the MUBench Pipeline can download it automatically, themd5
needs to be changed to the actual hash of the Jar file, for download verification.
It is possible to manage multiple versions of a detector via the releases.yml
file.
The file might then look as follows:
- cli_version: 0.0.10
md5: 2470067fac02ee118b7d49287246e20a
- cli_version: 0.0.8
md5: 9e5252816faecf552464f0a6abde714f
tag: my-tag
- The
cli_version
names the version of themubench.cli
dependency used to implement the respective MUBench Runner. - The
md5
is the hash of the respective Jar file. - The
tag
is an identifier for the detector version (case insensitive). You may specify this identifier when running experiments, using the--tag
option. If the--tag
option is not specified, the MUBench Pipeline runs the top-most detector version listed in thereleases.yml
file. If this detector version has notag
,latest
is used as the default. In any case, the MUBench Pipeline expects the respective Jar file atdetectors/<mydetector>/<tag>/<mydetector>.jar
.
To debug a MUBench Runner it is more convenient to run it directly from an IDE, instead of bundling an executable Jar to run it in MUBench after every change. To do this, proceed as follows:
- Run
./mubench run <E> <mydetector> --only <P>
, where<E>
is the experiment you want to debug andP
is the project or project version you want to debug with, e.g.,aclang
. - Abort this run, as soon as the detector was started.
- Open the newest log file in
./logs
and look for a line saying something likeExecuting 'java -jar <mydetector>.jar ...'
. - Copy the command-line parameters of this Java invocation (the
...
above). - Invoke your runner's
main()
method with these parameters from your IDE.