This next installment of the series “JitPack Tips and Tricks” again deals with JitPack, but will be much shorter than the prior two. Among other things, in the prior two posts of this series, we saw that JitPack is a different type of Maven repository in that it builds your artifacts on JitPack servers on-demand the first time anyone imports a particular version into their project, and it does so from the source code from the GitHub (or Bitbucket or other git host) repository. Although you can configure the conventional reverse domain as the
groupId, as seen in my previous post, which also explained how to make JitPack build ahead-of-time, by default JitPack defines the
groupId based on the git host and user on that git host (e.g.,
com.github.USER). JitPack then uses the name of the git repository as the
artifactId, regardless of what is specified in your
pom.xml (it renames whatever jar files the build produces).
Table of Contents:
Why This is a Limitation
JitPack uses the name of the git repository as the
artifactId. Didn’t you just say that? Yes. I repeated it because I see this as a potential limitation, mainly to someone like me who already has libraries with artifacts published elsewhere (e.g., I publish all of my libraries on Maven Central), but I’ve begun using JitPack as well for its ability to build snapshots from specific commits, branches, pull-requests, etc. See first post in the series for more on this, including configuring JitPack for recent JDK versions.
So why is this a limitation? Well, for some of my libraries, the
artifactId I’m already using for other repositories such as Maven Central is identical to the GitHub repository name. In other cases, the only difference is in casing. The
artifactId is conventionally written in all lowercase (a convention I follow), but the corresponding GitHub repository name is written in mixed-case for some of my libraries. This is no big deal because casing doesn’t matter when referencing a GitHub repository name. It is just a visual element when browsing GitHub.
However, an issue arises in a couple other cases, where I have an existing library with many releases of artifacts published with an
artifactId to Maven Central that is different than the GitHub repository name. Renaming the GitHub repository would break existing links to it. Switching to a different
artifactId on Maven Central to match the repository name would cause confusion, since older versions would have one
artifactId and newer versions a different one.
Due to this limitation, I have a few libraries that I have not yet configured for JitPack builds. One of these is JavaPermutationTools, with a GitHub repository name of
JavaPermutationTools but Maven
jpt. Actually, this specific library also uses the Java Platform Module System (JPMS), and provides a JPMS module named
org.cicirello.jpt, which happens to match the combination of my reverse domain
groupId and the
artifactId, although there is no actual requirement to do so. I do have my reverse domain configured for use on JitPack, so the
groupId will be consistent across all Maven repositories where I make my library available. But, having an
artifactId that differs bothers me. If I were to configure JitPack builds (necessary in this case because this library requires JDK 17 and JitPack by default builds with JDK 8), then importing would look different if done from Maven Central vs JitPack.
Importing from Maven Central currently involves specifying the dependency with:
<dependency> <groupId>org.cicirello</groupId> <artifactId>jpt</artifactId> <version>4.1.0</version> </dependency>
Hypothetical JitPack Import:
But from JitPack, it would necessarily be (since I won’t rename repository):
<dependency> <groupId>org.cicirello</groupId> <artifactId>JavaPermutationTools</artifactId> <version>4.1.0</version> </dependency>
The potential for confusion is too high here since the dependency definitions appear to be different artifacts, when in fact they contain the same Java module, and the same set of Java packages.
If you are just beginning a Java (or Kotlin or other JVM language) library, and if there is a chance that you might want to release artifacts to multiple Maven repositories, including JitPack, then name your git repository the same as you intend your
artifactId to be. In fact, even if you don’t plan on deliberately supporting JitPack, since it is possible to import artifacts built on-demand from JitPack whether the library’s maintainers (e.g., you) intend for this or not (provided JitPack’s default build works for your library), then it might be a good idea anyway to match your repository name to your chosen
Project Used in Examples
The examples are based on JavaPermutationTools, which is a Java library that is focused on all types of computation related to permutations as well as sequences. It includes, among other things, an extensive collection of distance metrics for calculating the distance between two permutations, as well as string distance metrics for calculating the distance between pairs of strings or other sequential structures, such as arrays. I may write future DEV posts about the library. Check out JPT if you have the chance.
JPT has a website:
And here is it’s GitHub repository:
A Java library for computation on permutations and sequences
Copyright (C) 2018-2022 Vincent A. Cicirello.
API documentation: https://jpt.cicirello.org/api
How to Cite
If you use this library in your research, please cite the following paper:
Cicirello, Vincent A (2018). JavaPermutationTools: A Java Library of Permutation Distance Metrics. Journal of Open Source Software, 3(31), 950. https://doi.org/10.21105/joss.00950 .
The JavaPermutationTools (JPT) library provides Java classes and interfaces, etc that
enable representing and generating permutations and sequences, as well as performing
computation on permutations and sequences. It includes implementations of a variety
of permutation distance metrics as well as distance metrics on sequences (i.e., Strings
arrays, and other ordered data types).
We currently support Java 17+. See the following table for mapping between library version
and minimum supported Java…
Where You Can Find Me
On the Web:
Follow me here on DEV:
Follow me on GitHub:
If you want to generate the equivalent to the above for your own GitHub profile,
check out the cicirello/user-statistician