DEV Community

Vincent A. Cicirello
Vincent A. Cicirello

Posted on

On JitPack's use of git repository name as Maven artifactId

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 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>
Enter fullscreen mode Exit fullscreen mode

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>
Enter fullscreen mode Exit fullscreen mode

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).

favicon jpt.cicirello.org

And here is it's GitHub repository:

GitHub logo cicirello / JavaPermutationTools

A Java library for computation on permutations and sequences

JavaPermutationTools (JPT): A Java library for computation on permutations and sequences

JavaPermutationTools - 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 DOI
Packages and Releases Maven Central GitHub release (latest by date)
Build Status build docs CodeQL
JaCoCo Test Coverage coverage branch coverage
Security Snyk security score Snyk Known Vulnerabilities
DOI DOI
License GitHub
Support GitHub Sponsors Liberapay Ko-Fi

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.

favicon cicirello.org

Follow me here on DEV:

Follow me on GitHub:

GitHub logo cicirello / cicirello

My GitHub Profile

Vincent A Cicirello

Vincent A. Cicirello

Sites where you can find me or my work
Web and social media Personal Website LinkedIn DEV Profile
Software development Github Maven Central PyPI Docker Hub
Publications Google Scholar ORCID DBLP ACM Digital Library IEEE Xplore ResearchGate arXiv

My bibliometrics

My GitHub Activity

If you want to generate the equivalent to the above for your own GitHub profile, check out the cicirello/user-statistician GitHub Action.




Liberapay Ko-Fi
GitHub Sponsors

Top comments (1)

Collapse
 
cicirello profile image
Vincent A. Cicirello

I only gave an example in the post that illustrates the artifactId as repository name limitation. Here is another of my libraries, where this isn't an issue, since the repository name matches the artifactId I 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.

GitHub logo cicirello / Chips-n-Salsa

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

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/

Publications About the Library DOI
Packages and Releases Maven Central GitHub release (latest by date) JitPack
Build Status build docs CodeQL
JaCoCo Test Coverage coverage branches coverage
Security Snyk security score Snyk Known Vulnerabilities
DOI DOI
License GitHub
Support GitHub Sponsors Liberapay Ko-Fi

How to Cite

If you use this library in your research, please cite the following paper:

Cicirello, V. A., (2020). Chips-n-Salsa: A Java Library of Customizable, Hybridizable, Iterative, Parallel, Stochastic, and Self-Adaptive Local Search Algorithms. Journal of Open Source Software, 5(52), 2448, doi.org/10.21105/joss.02448 .

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…