Savant Build Tool: License Management

Brian Pontarelli
  • By Brian Pontarelli
  • Technology
  • November 11, 2014

Magnify Glass on LicensesIn our first blog post, we briefly touched on the concept of licenses in Savant. Project licenses are a concept that is often overlooked in software development, but is extremely important. The legal nature of software licenses, both open and closed, can impact how a library, tool or product is used and deployed.

Most build tools allow projects to define their license, but it is often a free form text field in the project definition file. This causes a number of problems. First, these are impossible to parse reliably. Second, it is usually optional. This means that with most build tools it is impossible to correctly determine what licenses your software is currently using. Any lawyers reading this are probably starting to sweat and shift uncomfortably in their chairs.

Savant is built and maintained by Inversoft. Inversoft has a number of products that are commercially licensed. All of our products are on-premise and therefore downloaded by our customers and installed on their servers. This means that we need to be extremely meticulous about our use of open source licenses. If we were to use a library that was licensed under the GPL, it could have drastic ramifications on our products.

Continue reading

Tags:
Savant

Savant Build Tool: Version Compatibility

Brian Pontarelli

Inversoft Savant Version Compatibility
Image by Manu Cornet

Version compatibility is a core concept in Savant. Even before Semantic Versioning was first published, Savant was built on the concept of major, minor, patch compatibility. This concept was formalized into the Semantic Versioning specification. This specification is quickly becoming the industry standard for versioning software.

The quick overview of Semantic Versioning goes like this. Versions are broken up into 4 parts:

Diagram

Compatibility between versions is determined as follows:

Major versions are not compatible. That means that 1.0.0 and 2.0.0 are not compatible.

Continue reading

Tags:
Savant

Savant Build Tool: Dependency Management

Brian Pontarelli

When we first started writing Savant, we realized that the first requirement was a dependency management system. This is necessary for nearly every feature in a good build tool. We wanted Savant plugins to be resolved as dependencies and to be loaded into separate classloaders along with their dependencies. We also knew that the Java compiler plugin would need the project’s dependencies for the compiler classpath and the TestNG plugin would need the dependencies to run the tests.

Savant Dependency Management BlocksFor years we had been using a strict versioning system that broke versions into 4 different groups:

  • Major
  • Minor
  • Patch
  • Pre-release

This versioning is expressed as <major>.<minor>.<patch>-<pre-release>

We found that the Semantic Versioning (SemVer) specification was nearly identical to our versioning methodology. Rather than continue to use our own system, we fully embraced SemVer. The problem was that no other dependency management system implemented SemVer.

Continue reading

Tags:
Savant

Savant Build Tool: Dependencies & Build Targets

Brian Pontarelli

Savant Build Files: Define Dependencies & Build Targets

In this post we'll cover Savant build files and how to define your dependencies and build targets. First, let's set up a simple build file for a new project called HelloWorld. Here is how we define this project and its version:

project(group: "org.inversoft.savant.example", name: "HelloWorld", version: "1.0", licenses: ["ApacheV2_0"]) {
}

To define a project you need a group, name, version and a license. You can ignore the licenses definition for now, we'll cover that in a future post. The group name is usually a reverse DNS name (notice that the org is first not last) that identifies the owners of the project. The name is the project's formal name and the version is the project’s Semantic Version.

Next we can define the other libraries and frameworks that our project depends on. We place the dependencies inside the project definition and break them into groups. It looks like this:

project(group: "org.inversoft.savant.example", name: "HelloWorld", version: "1.0", licenses: ["ApacheV2_0"]) {
  dependencies {
    group(name: "compile") {
      dependency(id: "org.apache.commons:commons-collections:3.1")
    }
    group(name: "test-compile") {
      dependency(id: "org.testng:testng:6.8.7")
    }
  }
}

These dependency directives tell Savant that in order to compile our source code Savant needs to include Commons Collections version 3.1. Likewise, in order to compile our test source code, Savant will need to include TestNG version 6.8.7.

Continue reading

Tags:
Savant

Inversoft Announces the Launch of Savant

Brian Pontarelli

Savant Build ToolInversoft Launches Savant Build Tool

The Inversoft dev team is excited to announce the first preview release of the Savant build tool. Savant is written in Java and uses a Groovy DSL for the build files providing the power of the Groovy programming language for your builds.

We have been working to define the concepts of our ideal build tool for nearly a decade. By using a wide variety of other build tools including Ant, Maven, and Gradle, we have learned that dependency management, versioning and compatibility are some of the most complex problems in building software, and all of the existing build tools don’t solve these problems well. We realized that the build tool should be handling all of these concepts in the most complete way possible. To solve these problems, we adopted the Semantic Versioning standard and built Savant as a complete implementation of it.

 

Continue reading

Tags:
Savant