Today we released version 0.4.0 of the OpenFastTrace Gradle plugin. This is the first version that can be considered production ready. It was successfully integrated into a real life commercial project using the following features:

• Software architecture design (Swad) imported as a dependency from a maven repository
• Software detailed design (Swdd) written in MarkDown
• Coverage tags in code (long format) for item types src, utest and stest
• Filter requirements from Swad, Swdd and Code using a artifact type filter
• Filter Swad requirements relevant for the project using a tag filter
• Generate a tracing report in text format containing failure details
• Additionally, to the report we export the requirements in Specobject format that can be delivered to integration for creating an overall tracing report

Only minor adaptions were required and OFT works in parallel to the proprietary tracing tool. It is just must faster! 😉

Starting today we will provide a growing set of Eclipse templates to help speed-up writing OpenFastTrace specifications using the Eclipse IDE. Using these templates also has the nice side-effect of reducing the chance for errors when writing specifications.

Find the templates here: https://github.com/itsallcode/openfasttrace-eclipse-templates

We already publish openfasttrace to JCenter, see openfasttrace distribution. Using libraries from JCenter in a Gradle build only requires adding repositories { jcenter() } to your build.gradle.

You can do the same with maven by adding the following to your pom.xml:

<repositories>
  <repository>
    <id>central</id>
    <name>bintray</name>
    <url>http://jcenter.bintray.com</url>
  </repository>
</repositories>

But we want to make it even easier for maven users by publishing our artifacts to the Maven Central repository which maven uses by default.

Today Christoph and me released version 1.1.0 of OpenFastTrace. The most notable feature addition is that you now can opt to keep specification items without tags when configuring the tag filter.

Log message test coverage for the java.util.logging.Logger depends on the log level by default. As an optimization the lambda functions that constitute log messages are only executed if the configured log level is higher or equal the log message level.

In effect this means that for optimum test coverage you would have to set the log level to FINEST for your unit tests. But that will spam your console or log files.