On JitPack's use of git repository name as Maven artifactId
Tags: java, tutorial, kotlin, github
Published: 2022-08-18 14:59:21

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](https://dev.to/cicirello/ahead-of-time-jitpack-builds-with-custom-groupid-via-github-actions-55cp), which also explained [how to make JitPack build ahead-of-time](https://dev.to/cicirello/ahead-of-time-jitpack-builds-with-custom-groupid-via-github-actions-55cp), 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](#why-this-is-a-limitation).
* [Tip](#tip) to deal with this limitation.
* [Project Used in Examples](#project-used-in-examples).
* [Where You Can Find Me](#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](https://search.maven.org/search?q=g:org.cicirello)), but I've begun using JitPack as well for its ability to build snapshots from specific commits, branches, pull-requests, etc. See [first post](https://dev.to/cicirello/how-to-configure-jitpack-for-recent-jdk-versions-4pek) in the series for more on this, including [configuring JitPack for recent JDK versions](https://dev.to/cicirello/how-to-configure-jitpack-for-recent-jdk-versions-4pek).

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](https://github.com/cicirello/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:

```XML
<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):

```XML
<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](https://github.com/cicirello/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](https://dev.to/) posts about the library. Check out JPT if you have the chance.

JPT has a website:

{% embed https://jpt.cicirello.org %}

And here is it's GitHub repository:

{% github cicirello/JavaPermutationTools %}


## Where You Can Find Me

On the Web:

{% embed https://www.cicirello.org/ %}

Follow me here on DEV:

{% user cicirello %}

Follow me on GitHub:

{% github cicirello/cicirello %}

| [![Liberapay](https://actions.cicirello.org/images/Liberapay.svg)](https://liberapay.com/cicirello) | [![Ko-Fi](https://actions.cicirello.org/images/ko-fi.svg)](https://ko-fi.com/cicirello) |
| :---: | :---: |
| [![GitHub Sponsors](https://actions.cicirello.org/images/github-sponsors.svg)](https://github.com/sponsors/cicirello) | |