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!
Today we released version 0.6.0 of the Gradle plugin which includes OpenFastTrace 2.2.0 and supports HTML reports.
Today I want to thank the author of recoverjpg, Samuel Tardieu. This tool is proof that “do one thing, do it well” results in the most useful software.
A family member brought an SD card back from a vacation trip abroad and the filesystem broke when she plugged the card into her Mac. Needless to say that this is not the usual scenario, because many times before everything went well.
Having (partially) restored broken filesystems or at least files, I knew the drill. First rule: don’t attempt to restore on the volume that failed directly. So I created a 1:1 copy of the broken filesystem with the
dd command that comes with any Linux installation.
Attempts to restore the filesystem itself failed. The structure was so broken, that
fsck.vfat did not succeed. At that point I already pictured myself trying to repair parts with a hex editor. But then I found
recoverjpg and it looks for typical structures that look like a JPG file without caring about the filesystem itself too much. That did the trick.
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:
After two bugfix releases a new feature release. On November 19th Christoph create the Release for OpenFastTrace 2.1.0.
Feature-wise we are happy to announce an improved HTML report.
Sonar checks are now up and running again and the last JavaDoc errors have been rooted out.
We also fixed the deep coverage detection which was pointing upwards instead of downwards in the tracing chain. As a consequence we had to rework link loop detection, which acts a lot smarter now than before.
Enjoy this release, which is a huge step forward for OFT!
This release is a big step forward. One new feature, a few small fixes and a lot of code improvements that gives us a much cleaner and more uniform API, better test coverage and lower overall complexity.
But a new API also means we had to break backward compatibility to achieve something that the existing API would not allow since it had a separation of report and export mode: you can now reuse an import that already ran to create both reports and exports from it without redoing the import. This is a considerable speed-up (and we call the project OpenFastTrace for a reason. Runtime efficiency was and will always be one of our main design principles.
You can find examples of how to use the API in the user guide and in OFTs own code of course.
Thanks to Christoph for his patience during his review of the giant change set that the API rework caused!
Enjoy the new and improved API.
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.
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
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.
Release letters are useful. No doubt about that.
They are the go-to place for users who want to know what’s new in a software release.
Granted that information is already available in your projects ticket system but you can’t expect your users to dig through tickets just to be up-to-date.
So you duplicate information. Which is unsatisfying because it creates coupling:
- You copy information from the features and bug fixes from the tickets
- You add links to the ticket system
- You copy the version number
- and you should not forget to enter the right release date shortly before you release
In some of our commercial projects we had this process automated to a high degree. The only thing really missing was translating the tech talk from the tickets into short descriptions that are helpful for your users.
We need to reach that point.