Keeping your codebase healthy

Maintaining a project in a healthy state should have a higher priority in light of recent events. There are a handful of techniques and measures that can be applied to keep the codebase neat and tidy. If your project is built with Gradle then the following list may come in handy when taking matters in to your own hands: ossindex versions license jdeps jacoco checkstyle pmd findbugs/spotbugs codenarc sonarqube Each plugin takes care of an specific dimension and together they can strengthen your codebase. Let’s begin with the ossindex plugin. This plugin scans project dependencies and checks if there are Read More


Happy 9th Birthday Griffon!

Today marks the 9th anniversary of Danno’s announcement of Griffon 0.0. It’s been quite the ride since then, and lots of fun if I may say so. As Danno noted, Griffon began life as a fork of the Grails codebase at the time. He literally copied the Grails source, removed everything that was related to HTTP and Servlets and added Swing on top. This allowed Griffon to bootstrap itself very quickly and begin its own journey. The feedback we’ve got was very positive and we happily continued adding more features, letting Griffon to have it’s own identity. Plugin support was Read More


Open Source Tools: Reports – Coverage

Measuring code coverage is a good way to figure out if a project has a healthy codebase or not. There is no magic number for coverage, as with many things it software the right answer depends on the context; this being said some projects strive for the perfect 100% and will relentlessly pursue that goal, no matter what. There are a handful of projects in the Java space that can calculate the coveted number: Cobertura, JaCoCo, and OpenClover. Of the three I’d say JaCoCo is the one I use most for the following reasons: JaCoCo delivers better branch coverage statistics Read More


Open Source Tools: Licensing

A key aspect for a FLOSS project to be successful is to choose the correct licensing scheme. There are tons of license you can choose from, a good starting point would OSI’s Licenses & Standards page. Take some time to review some of them, as each one defines duties and benefits that you as an author, your contributors, and the users of your code have access to. When in doubt please contact someone that’s knowledgeable in the subject, for example you can reach out to the OSI directly, or ask at the mailing list/forum of a popular project which may Read More


Open Source Tools: Build – GitHub

On the last two posts of this series (JitPack, Travis & AppVeyor) I mentioned in passing another online service that is very popular and widely used: GitHub. The fact that I failed to mention this service before the introduction of the previous two goes to show how prevalent it is; you simply take it for granted because it’s there! There are of course other code hosting solutions in the wild, I started 11 years ago with SourceForge (with CSV no less, oh my!), such as BitBucket and GitLab however most of the online services we’ll continue to see on this Read More


Open Source Tools: Build – Travis & AppVeyor

Open Source projects have higher chances for success if their build instructions are clear and easily reproducible by anyone. It’s a very good idea to include a file that contains environment setup and clear build instructions to be followed. Even better would be to additionally configure a remote build mechanism that publicizes build status and results. This build mechanism can be used to Build and publish released binaries. Publish code coverage results and other quality gates. Build branches on demand, validating external contributions before merging (based on pull requests from GitHub for example). There are several options out there that Read More


Open Source Tools: Build – JitPack

Up until know we’ve discussed how to build projects using a couple of tools. Regardless of which one you pick you may need to deal with dependencies. The Java platform does not provide a specification for defining dependencies and their metadata and how to consume them, however the whole ecosystem has agreed on using JAR files as the binary packages and Apache Maven’s POM format as metadata. Often times you add a bit of configuration to your build file stating two things: the dependency coordinates used to locate the JAR file. the repository from where the metadata and the JAR Read More


Open Source Tools: Build – SDKMAN!

In the past two entries we’ve seen how to get started with Apache Maven and Gradle. You may have noticed that getting any of these tools installed on your system requires the following steps: Download a binary distribution (usually packaged as a ZIP file) from the official download page. Unzip the distribution anywhere on your system. Configure environment variables. Get ready to go! You must perform these steps every single time a new version comes out if you want to keep your toolbox up to date. There’s bound to be a better way to execute these repetitive tasks. This is Read More


Open Source Tools: Build – Gradle

Gradle is a JVM based build tool whose aim is to let developers create binaries from sources. It has grown in popularity in recent years due to is flexibility, one of the reasons why the Android ecosystem switched from Apache Ant to Gradle, turning every single Android developer out there into a Gradle user. Gradle has its origin way back in late 2007 as a response to Maven’s inability to deliver a flexible lifecycle. At the time Gradle’s aim was to deliver a richer model on which any kind of project could be built; this allowed Gradle to support non-JVM Read More


Open Source Tools: Build – Maven

Java projects need a way to produce binaries from sources. There are many tools out there that can achieve this goal, Apache Maven has been so far the most popular choice, chances are you have encountered in one way or another. Maven as we know it today is the result of a couple of iterations, starting with Maven 1 where the build was one step removed from its predecessor tool: Apache Ant. Maven 1 gave you a lot of freedom to define how a particular build should behave but forced developers to use XML in a programmatic way. This lead Read More


ˆ Back To Top