Up until know we've discussed how to build projects using a couple of tools. Regardless of which one you pick you may need to deal with dependencies. The Java platform does not provide a specification for defining dependencies and their metadata and how to consume them, however the whole ecosystem has agreed on using JAR files as the binary packages and Apache Maven's POM format as metadata. Often times you add a bit of configuration to your build file stating two things:
- the dependency coordinates used to locate the JAR file.
- the repository from where the metadata and the JAR can be downloaded.
In the case of Maven you always have two default repositories defined for your convenience:
- Maven Local, located on the computer on which the build takes place. This repository may be used to produce builds in offline mode.
- Maven Central, this is the canonical artifact repository from which many dependencies can be downloaded.
If you're using Gradle you may also have access to these repositories however you have to explicitly express the intention to use them, such as
plugins {
id 'java'
}
repositories {
mavenCentral()
mavenLocal()
}
The reason behind this difference is that Gradle can build non-Java projects where default settings that apply to the Java platform do not apply or map to the target non-Java platform. Once you have successfully configured repositories you may want to add some dependencies to your project. It's possible to search Maven Central directly, I'd also recommend to have a look at http://mvnrepository.com/ as it gives you more details and additional information per dependency.
Dependencies are either available locally to your system or remotely. These dependencies are usually considered to be in release form, even snapshots. But what if you need a specific release that may not yet be available but the source is publicly available? One could think it's a matter of grabbing the sources, building the binaries, and pushing them either to Maven Local or a another remote repository available on your organization. This can certainly work, but this workflow will get pretty tiresome if you have to continually do this; it would be better to offload the work another service, and that's precisely what JitPack does for you.
In simple terms you may think of JitPack as a remote repository where dependencies may be available on demand. The main gist is to configure JitPack as a repository in your build file, then define the coordinates that identify the dependency. The trick is that the coordinates point to a particular git commit and not the standard group-atifact-version (or GAV) as we're used to so far. Whenever the dependency is required for build and its status is queried by the build tool and it's not yet available from the local repository then JitPack kicks into action. It understands the coordinates of the dependency and figures out if it already has a copy with those particular settings. If it does then it serves the dependency right away, just like a regular artifact repository would do. If it does not then it clones and builds the repository, caching the build result as a dependency. Isn't that amazing? This means if more than one project point to the same Git commit then all of them will have the exact same binary. Because the coordinates point to very specific release it wouldn't matter if the project continues to add more code the dependency's binary will still be related to the same commit, thus giving you a rock-solid binary. Say goodbye to custom built snapshots. The catch is that the source must be hosted on GitHub.
Disclaimer: I'm in no way related to JitPack nor the company behind it. I merely provide information on this service based on its free version.
