Savant Build

Dependency Management

At its core, Savant is a dependency management tool. The build system is built on top of this dependency management. If you aren’t familiar with dependency management, the simple explanation is that any libraries or frameworks your project uses are its dependencies. Those libraries and frameworks might also have dependencies of their own. This collection of dependencies forms what is called a dependency graph. Savant is really good at managing dependency graphs and downloading and caching your project’s dependencies.


At different stages of your project’s build and run process, it might need different dependencies. For example, at compile time it might need Apache Commons Collections version 3.1. On the other hand, at test time it might require TestNG version 4.8.7. Therefore, dependencies are broken up into groups, one for each stage of the project build and run process.

Semantic Versioning

Savant’s dependency management system implements Semantic Versioning. Semantic Versioning is a specification that determines how projects must maintain binary compatibility. If you haven’t read the Semantic Versioning specification, it is probably a good idea to start there.

Savant does deviate from the Semantic Versioning specification in one major way. Savant uses a version marker for integration builds. The marker is -{integration}. This marker is automatically handled by Savant. Although, if you have a dependency on a project that is an integration build, you’ll need to add the marker to the dependency declaration.


Savant also requires that all projects define the license(s) they are using. This is a vital piece of data for many organizations to track and maintain and therefore all artifacts must be publish with license information. Savant handles this process automatically by requiring that all projects declare their license(s) in the Savant build file.