Chirp! A Low Cost Function Generator

The first hurdle I ran into while moving to a continuous integration tool (i.e. Travis), was migrating my build process from using the Eclipse IDE to a command line build tool. There are several options out there for this, but I decided on gradle for this project's build tool.

What is gradle? It is a flexible general purpose build tool, like make, maven, or ant. Being an embedded c programmer, I was very familiar with make but wanted to learn more about some of the newer build tools out there, which is mainly why I chose gradle.

One of the nice things over make is that gradle already has a build plugin for java. For those of you new to gradle, I would recommend checking out the gradle plugin for java.

Modify Default Gradle Folders

I wanted to change the gradle the default directory from src/main/java and /src/main/resources to src/ and lib/ for its source folder and resources folder respectively.

sourceSets {
	main.java.srcDir 'src/'
	main.resources.srcDir 'lib/'
}

Append Version Number to Binary

Next, I wanted to append the version number to the executable JAR file so I could quickly and easily identify the version of code I was running. Gradle has the ability to pass in parameters to the script with the -P option. If the parameter prodVersion is specified, then this version is applied to the suffix of the JAR file. If no value is passed in, then -Developer-Build is appended.

allprojects {
   if (project.hasProperty('prodVersion')) {
     project.version = project.prodVersion
   } else {
     project.version = 'Developer-Build'
   }
}

Include Libraries In JAR File

The default gradle JAR task was insufficient for creating the executable JAR file since nrserialjava.jar needs to be included in the JAR file. After doing some searching, I found that this could be accomplished with this code:

task fatJar(type: Jar) {
	manifest {
		attributes 'Main-Class': 'controller.Application'
    }

	baseName = project.name
	from { configurations.compile.collect { it.isDirectory() ? it : zipTree(it) } }
	with jar
}

Extend Gradle JAR Task

When Travis does a deploy, it calls gradle assemble, which in turn calls gradle jar. Instead of trying to figure out how to have Travis call gradle fatJar I figured an easier solution was to extend the jar task with fatJar. This was done by adding the following code to build.gradle:

jar.finalizedBy(fatJar) 

Now, anytime jar is called, fatJar will always be called.

Opening Project with Eclipse

I prefer Eclipse for my IDE but would prefer not maintaining Eclipse project settings file and a gradle build file. Gradle will automatically generate an Eclipse .project and .classpath with the command:

gradlew eclipse

For the full build.gradle file, please check out the ChirpUI project on GitHub.

What I found is that there are a variety of different licenses out there, and selecting one depends on the author's preference for the project. One of the goals of Chirp is to make the hardware, software, and firmware freely available for others to learn and grow the project.

A great resource for this was www.opensource.org, especially their FAQ page. In addition, this page was helpful in narrowing down the license that we wanted to use for Chirp.

Ultimately, we wanted to use Copyleft and decided on the GPLv3 because we wanted to make sure that derivative work is made available under the same terms.

Implementing the license was straight forward, we added a copyright and boilerplate heading to every source file and attached a copy of the GPLv3 license in a file named `COPYING`.

This title is in honor of the great Analog Engineer, Bob Pease, who helped me learn that as an engineer, you're never done learning...

Continuous integration is a beautiful thing! A practice only new to me as of about a year ago, continuous integration (CI) allows for code to be built as soon as it's checked into your Version Control System (VCS).

So why is this important? Imagine, before continuous integration, broken code (i.e. code that does not compile) would be checked into VCS and no one would know about it until another developer would check the code out and attempt to build. Only then would the second developer realize there was an issue, and have to scramble to either fix the issue or find the developer responsible.

Even a good developer who verifies their code compiles at their desk still forgets to add a file to version control every now and then!

How does it work? At the simplest level, a continuous integration software application watches your version control system, checks out the code after a push, and compiles. That's it. Pretty simple, right?

It doesn't just stop there, almost anything as part of your build process can be added to your CI server: static analysis, unit testing, functional testing, publishing artifacts (e.g. binaries)...

What stuff is out there? TeamCity, Jenkins, Hudson, Travis, Bamboo to name a few.

Our code for Chirp GUI is out on GitHub, and I'm looking at using integrating Travis as our continuous integration tool.

The Chirp GUI application was previously using RXTXcomm JAR from rxtx.qbang.org and the Windows 64-bit DLLs from Mfizz for its serial communications.

Everything worked pretty good until I started investigating making the application a single standalone JAR (Java Archive) file. Eclipse is able to create a standalone executable JAR and does this for you in a few easy clicks in Eclipse (Right click > Export > Runnable JAR file). However, it presents some real challenges if we wanted to automatically create a runnable JAR file on code check-in.

A JAR file is effectively a Java ZIP file and can be setup to run as a stand alone executable, much like how a stand alone EXE file can be made to not require any additional files.

While it is possible to create an executable JAR file that contains other JAR files, the DLL files required by rxtxcomm needed to be extracted out of the runnable JAR file in order to be used. This complicated things a bit and I found that this is one of the solutions that the nrjavaserial library provided.