New project structure for OpenFastTrace

We are happy to announce the latest release 2.3.5 of OpenFastTrace.

In this release we split the source code into sub-modules for api, importers, exporters etc. This has some advantages:

  • The dependencies of plugins are now enforced by the compiler. It is not possible that e.g. the specobject exporter depends on the specobject importer.
  • Developers who want to extend OFT with custom importers or exporters only need add a dependency for the stable API module without all the other internal code.
  • A stable API simplifies internal refactoring of the code because third party plugins only depend on the API module. All other modules are internal and can be changed without breaking third party plugins.

I also should mention some caveats. Building the project now takes around 3 minutes, deployment to JCenter even 9 minutes.

Currently the API module contains some plugin specific classes for configuration. We plan to clean this up in one of the next releases.

To make it easier for users and third party developers we also maintain a changelog with all the important changes in each release. The changelog follows the structure of Keep a changelog.

Of course we also released version 0.6.2 of the gradle plugin which uses the new OpenFastTrace 2.3.5. The gradle plugin now also contains a changelog.

Please upgrade to the new versions and share your experience.

Happy Tracing!

Time recording tool

To keep track of my working time I wrote a small time recording tool called White Rabbit. You can find it at


  • Simple text user interface
  • Records begin, end and interruption of your working day
  • Data storage in human readable json files, one file per month
  • Manual interruptions: press i to start and stop interruptions
  • Supports weekend, public holiday, vacation, flex time and sickness (see json example)
  • Reporting of total overtime: press r
  • Automatic update in the background (press u to update manually): just keep it running and it will record your working time
    • Start of work is detected via
      • Program start
      • Computer resumes from sleep in the morning
    • End of work is detected via
      • Program shutdown
      • Computer sleeps for the rest of the day
  • Interruptions added when computer sleeps for more than 2 minutes
  • Assumptions:
    • Working time of 8h Monday to Friday
    • Mandatory break of 45 minutes after 6 hours of working

Architectural descisions

The architecture separates business logic (sub-project logic) from the user interface (textui). This allows you to add additional user interfaces e.g. using JavaFX or Swing.

We use JSON for storage because this enables the user to manually make changes (e.g. add a sick day).  So we can keep the user interface as simple as possible.

Example data file

    "year": 2019,
    "month": "MARCH",
    "days": [
            "date": "2019-03-01",
            "begin": "08:00:00",
            "end": "17:00:00",
            "comment": "First working day (type WORK is optional)"
            "date": "2019-03-04",
            "type": "VACATION",
            "comment": "Vacation day, no change to working time"
            "date": "2019-03-05",
            "type": "FLEX_TIME",
            "comment": "Flex time, deducts 8h from your time"
            "date": "2019-03-06",
            "type": "HOLIDAY",
            "comment": "A public holiday, not working"
            "date": "2019-03-07",
            "type": "SICK",
            "comment": "Sick day, no change to working time"
            "date": "2019-03-08",
            "begin": "08:00:00",
            "end": "18:30:00",
            "interruption": "PT1H20M",
            "comment": "1h 20min of interruption"
            "date": "2019-03-09",
            "type": "WEEKEND",
            "comment": "Saturday and Sunday automatically detected, no need to add them here."

Example report

2019-03-01 Fri WORK      08:00 - 17:00 break: 00:45, working time: 08:15, overtime: 00:15, Acc. overtime: 00:15, First working day (type WORK is optional)
2019-03-04 Mon VACATION                break: 00:00, working time: 00:00, overtime: 00:00, Acc. overtime: 00:15, Vacation day, no change to working time
2019-03-05 Tue FLEX_TIME               break: 00:00, working time: 00:00, overtime: -08:00, Acc. overtime: -07:45, Flex time, deducts 8h from your time
2019-03-06 Wed HOLIDAY                 break: 00:00, working time: 00:00, overtime: 00:00, Acc. overtime: -07:45, A public holiday, not working
2019-03-07 Thu SICK                    break: 00:00, working time: 00:00, overtime: 00:00, Acc. overtime: -07:45, Sick day, no change to working time
2019-03-08 Fri WORK      08:00 - 18:30 break: 00:45, interr.: 01:20, working time: 08:25, overtime: 00:25, Acc. overtime: -07:20, 1h 20min of interruption
2019-03-09 Sat WEEKEND                 break: 00:00, working time: 00:00, overtime: 00:00, Acc. overtime: -07:20, Saturday and Sunday automatically detected, no need to add them here.
Total overtime: PT-7H-20M

Maven plugin for OFT created

Today we started a new project for creating a Maven plugin for OpenFastTrace. This will allow you to trace requirements not only with the command line and Gradle but also with Maven!

The project is still in its early stage but you can already trace requirements with the default configuration and a first integration test is working. See Pull Request #1 for the current sources. Reviews are welcome!



Gradle plugin upgraded to OpenFastTrace 2.1.0

After releasing OpenFastTrace 2.1.0 it was high time to release the corresponding Gradle plugin in version 0.5.0. This is a drop-in update, just update the version number and benefit from the features and bugfixes of OFT 2.1.0.

During the release process we also fixed the sonar analysis and some sonar warnings.

We also used the opportunity to document (and test) two features that where already implemented but not described:

OpenFastTrace Gradle plugin 0.4.0 released

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 😉

To see how you can integrate the OFT Gradle plugin into your project have a look at the example projects.

Publishing to Maven Central

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:


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.

The easiest way to publish to Maven Central is synchronization via bintray. The setup process is not trivial, so I want to share my experience.

  1. Apply for a repository for your organisation (in our case: org.itsallcode)
  2. Optionally generate a gpg key without password and upload it to bintray. As an alternative you can also use bintray’s key.
  3. Configure your bintray maven repository to automatically sign uploaded files
  4. Make sure your project conforms to Maven Central’s quality requirements:
    1. Your pom.xml must contain information about the project license and developers (elements <licenses> and <developers>)
    2. Publish the source code by adding this to your pom.xml:
    3. Publish javadoc by adding this to pom.xml:
  5. Now you can publish your artifacts to JCenter as usual via mvn deploy. Don’t forget to increment your version number in pom.xml.
  6. The last step is to synchronize the artifacts by clicking the “Sync” button in the “Maven Central” tab in bintray. If everything was OK after some time you should see the message “Successfully synced and closed repo”.

Then it will take some time (in my case around 40 minutes) until your packages are shown in Maven Central and you can search for it. And then it will take up to two hours until you can find them at