Managing and Building version-controlled Maven Repos using Git, Gradle and Nexus Server
I currently work in a VERY OLD code base that uses a thirdparty directory as a version-controlled “library” directory, dated from the era before Maven. Some colleagues decided it was time to adopt Maven for building new components and that was exciting… However, you can imagine having a build system composed of “dino” ANT scripts to manage really old stuff, and then the introduction of Maven pom.xml.
I personally chose to use Gradle for the projects that I had started and integrated it well to publish generated jars to the “thirdparty” directory…
Gradle for Maven Dependencies
The most updated version of this script is shown below. Note that this approach differs from the one in the stackoverflow in that this version DOES NOT generate the Maven Metadata files (pom.xml, *sha…), but simply copies the generated versioned jars into the “thirdparty” directory (scm cached dir).
Then, I used Gradle’s dependencies mechanism to use the same thirdparty directory as a dependency…
This week I received a surprising email from a developer complaining about not being able to build one of the components. The problem was simply because the Maven repository server was COMPLETELY REBUILT and all the dependencies were wiped-out. As a result, developers maintaining different projects needed to upload the projects again. That triggered something the question where the Maven artifacts should be stored. As the old approach of using the “thirdparty” directory might become a hybrid approach in a future, I thought I could use GIT to store the versions of the maven versions on a version-controlled directory of my projects after I stumbled upon the following blog
I agree with the pros/cons about that approach, and that happens to be a very similar situation I faced today. In this way, I decided to create something similar using BitBucket private’s GIT project to simulate my same environment.
Reusable Gradle Properties
First the initial maven configuration is managed by the following:
This gives me the following capabilities:
- Using the property “-Prelease” as a switch to not use the -SNAPSHOT prefix in the generated jars.
- Lots of properties saved in the project, making it easier to create scripts that depending on those properties from other build scripts.
- Could also provide an option to generate jars to the “thidparty” directory WITHOUT the Maven’s Metadata files.
For instance, given a project “Maceio Finance” on a project repository on BitBucket, I have created the following build.gradle file to build, generate the jars, declare dependencies to the local scm repository, and able to upload new versions to that.
The simplicity of Gradle uploadArchives
Running the task “uploadArtifacts” with the different switches result in the same expected behavior as described by the blog on http://cemerick.com/2010/08/24/hosting-maven-repos-on-github/, as shown in the output below.
The generated directories with the Maven Metadata files is shown below:
Now, if you just want the same Jars to a given version-controlled directory WITHOUT the Metadata file, you can use a task to “installThirdparty” described above.
Finally, the other support needed is a Maven server. We use the open-source Nexus server. Here’s the example of uploading the same contents from the configuration. Note that it uses the previous definitions of the properties from mavenProperties.gradle.
Gotta love gradle properties
Just as a reference, the output of the command “gradle properties” is a good reference to see ALL the projects variables at runtime. Here’s the output of that command. Take a look at the property “projectMvn” just as a reference.