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.
- Tip to deal with this limitation.
- Project Used in Examples.
- Where You Can Find Me.
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 artifactId of 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.
Maven Dependency:
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.
Tip
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 artifactId.
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:
JavaPermutationTools - A Java library for computation on permutations and sequences
The JavaPermutationTools (JPT) library includes a variety of permutation distance metrics as well as distance metrics on sequences (i.e., Strings, arrays, and other ordered data types).
jpt.cicirello.org
And here is it's GitHub repository:
cicirello
/
JavaPermutationTools
A Java library for computation on permutations and sequences
JavaPermutationTools (JPT): A Java library for computation on permutations and sequences
Copyright (C) 2018-2022 Vincent A. Cicirello.
Website: https://jpt.cicirello.org/
API documentation: https://jpt.cicirello.org/api
| Publications About the Library |  |
|---|---|
| Packages and Releases |
 
|
| Build Status |
  
|
| JaCoCo Test Coverage |
 
|
| Security |
 
|
| DOI |  |
| License |  |
| Support |
  
|
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 .
Overview
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).
Java 17+
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:
Vincent A. Cicirello - Professor of Computer Science
Vincent A. Cicirello - Professor of Computer Science at Stockton University - is a researcher in artificial intelligence, evolutionary computation, swarm intelligence, and computational intelligence, with a Ph.D. in Robotics from Carnegie Mellon University. He is an ACM Senior Member, IEEE Senior Member, AAAI Life Member, EAI Distinguished Member, and SIAM Member.
cicirello.org
Follow me here on DEV:
Follow me on GitHub:
Vincent A Cicirello
| Sites where you can find me or my work | |
|---|---|
| Web and social media |
  
|
| Software development |
   
|
| Publications |
      
|
If you want to generate the equivalent to the above for your own GitHub profile, check out the cicirello/user-statistician GitHub Action.
 |
 |
|---|---|
 |
Top comments (1)
I only gave an example in the post that illustrates the
artifactIdas repository name limitation. Here is another of my libraries, where this isn't an issue, since the repository name matches theartifactIdI was already using for Maven Central (other than casing which doesn't matter). In this case, the dependency is specified exactly the same whether importing from Maven Central or from JitPack.A Java library of Customizable, Hybridizable, Iterative, Parallel, Stochastic, and Self-Adaptive Local Search Algorithms
Chips-n-Salsa - A Java library of customizable, hybridizable, iterative, parallel, stochastic, and self-adaptive local search algorithms
Copyright (C) 2002-2022 Vincent A. Cicirello.
Website: chips-n-salsa.cicirello.org/
API documentation: chips-n-salsa.cicirello.org/api/
How to Cite
If you use this library in your research, please cite the following paper:
Overview
Chips-n-Salsa is a Java library of customizable, hybridizable, iterative, parallel, stochastic, and self-adaptive local search algorithms. The library includes implementations of several stochastic local search algorithms, including simulated annealing, hill climbers, as well as constructive search algorithms such as stochastic sampling. Chips-n-Salsa now also includes genetic algorithms as well as evolutionary algorithms more generally. The library very extensively supports simulated…