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.

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.

With every new project there will be a discussion whether requirement IDs should have a unique name or simply a numbering scheme.