Welcome to the third part in the series working with the vRealize Build Tools. At this stage you should have a fully working CI infrastructure and have all of your vRO code exported using packages and stored in Git repositories. In this post, I will show you how to manage dependencies across your packages and how you can use the Maven plugins to automatically update packages, so that they are using the latest dependency versions.
I will also show you how to manage versioning for development (Snapshots) and production (release) code. Once we have our versioning in place, I will detail how to prepare the releases and finally push the artifacts to the Artifactory repositories, which can be picked up by a release pipeline (something I will cover in much more detail in a later post).
I also want to point out that I had to update my previous post to include the git scm connections in your pom.xml files, as this is required for this post, so make sure to go back and check that out.
Understanding Snapshot vs Release Versions
The first thing to understand is the ‘-SNAPSHOT‘ string that is suffixed to package versions. You will have noticed that all of the package versions you created in my previous post, were version ‘1.0.0-SNAPSHOT’. This suffix basically tells Maven that the code inside this package is in a development stage and not suitable for production release. The Maven release plugins understand this and will prevent the dependency handler from including these as valid dependencies for your packages, as this could result in unstable code (thought, they can be defined manually).
If you are following these posts, then currently, all your packages will be at version 1.0.0-SNAPSHOT. Don’t worry, we will change this later, but for now, accept this as-as.
In my previous post I provided an example of 3 packages that I have created. I also created a table that detailed the ‘groupId‘ and ‘artifactId‘ for these packages. I am going to extend this table to list their dependencies on other packages. I have kept this simple, in that no dependencies exist outside of these 3 packages.
A dependency exists when one package is calling code from another package (typically with a System.getModule()). When dependencies are mapped, their artifacts and required versions are released as part of the release process.
I have added the ‘Dependency‘ column, which lists the projects/artifacts that this package depends on. All of my packages depend on ‘logger‘, whereas ‘nsx‘ also depends on ‘rest‘.
We now need to add some XML to the projects ‘pom.xml‘ file, that is located at the root of the project folder. These are ‘<dependencies>‘ tags that are used to define a set of ‘<dependency>‘ tags for the project. You should insert these tags immediately after the ‘<packaging>‘ tags but before the ‘<scm>‘ tags.
We also want to omit ‘-SNAPSHOT‘ from the version, since we’ll be pushing actual releases.
Below is an example of what the dependency XML insert looks like for the ‘rest‘ package:
Once you have completed defining your dependencies, save the ‘pom.xml‘ file and make sure to commit the changes to git.
Repeat this process for all of your projects.
Prepare & Release Packages
Maven provides a number of lifecycle phases and goals that can be used to prepare and perform the releases. We will also need to push the release artifacts to the Artifactory repositories, as this will be queried for dependencies, when releasing a package that has any defined.
You should first be focusing on all the core projects that make up most of your dependencies. Also, start with the projects that have dependencies in the lowest order, i.e. the ‘logger‘ project has no dependencies, so that will be released first, ‘rest‘ depends on ‘logger‘, so that will be released next, etc.
For all the release tasks, we’re going to specify the ‘release‘ plugin followed by the goal. We will use the following goals: