https://jitpack.io/

JitPack is one of Maven Repository. The Maven Repository is famous for Nexus, but JitPack has a unique design that emphasizes cooperation with git repositories such as github.

In Nexus etc., the flow is to register the pre-packaged jar file in the Nexus server.

JitPack is designed to dynamically convert sources located on github etc. into pom files and jar files for reference.

Therefore, the developer just pushes the trusted source code to github etc. without any other work, and JitPack will resolve the version number and generate the pom / jar file.

Therefore, as long as proper code management is performed, it is a major feature for developers to reduce unnecessary effort in the CI / CD flow and to create a simple CI / CD configuration.

Setting Example

It can also work with Bitbucket, but here the git repository is written assuming github. Also, the package management tool is written assuming maven.

Below, it will be described separately for the github side and the maven dependency caller.

Settings on the github side

pom.xml

The following conditions must be met in advance.

--Put pom.xml in the root directory --mvn package is executable

The following is a sample project for checking the operation of JitPack. It's a simple project everywhere that you build as a Spring Boot application and when you make a GET request to ** / api / sada ** it returns the string ** masashi **.

https://github.com/moaikids/sada4j

Cooperation with JitPack

Once pom.xml is ready, try working with JitPack.

No special procedure is required for linking, and if you link accounts with your github account, the information in the corresponding repository will be available in JitPack as well.

If the source code is on public github, you can use it for free as follows.

https://jitpack.io/#moaikids/sada4j

There is a charge for private repositories, and security tokens are used for access.

https://jitpack.io/private

Version setting

JitPack is not a model like Nexus that uploads a pre-packaged jar file with version information.

JitPack will version the library version based on the following rules.

tag

If you tag a commit, it will be used as version information, and you can refer to the commit contents by specifying the version.

This is an example of commit history, but you can see that some commits are tagged with 0.0.8.

Based on this information, JitPack will package and retrieve the contents of the commit by calling <version> 0.0.8 </ version>.

branch

The latest push content for each branch can be viewed as a SNAPSHOT.

commit

The contents of each commit can also be referenced individually.

Caller settings

Another calling project adds the contents of the above github project using maven dependency.

pom.xml The contents registered on the github side will be converted according to the following rules when acquired as a dependency via JitPack.

Setting items	Settings	Case law	Supplement
groupId	com.github.{user_name}	com.github.moaikids	pom on github side.The xml definition is ignored.
artifactId	{repository_name}	sada4j	pom on github side.The xml definition is ignored.
version	(As mentioned above, use the one generated by some rules)	0.0.8	pom on github side.The xml definition is ignored.

The following is an actual setting example. It is OK if you add the dependency information converted based on the above rule and the repository information of JitPack.

<repositories>
    <repository>
        <id>jitpack.io</id>
        <url>https://jitpack.io</url>
    </repository>
</repositories>
 
 
<dependencies>
    <dependency>
        <groupId>com.github.moaikids</groupId>
        <artifactId>sada4j</artifactId>
        <version>0.0.8</version>
    </dependency>
</dependencies>

After that, if you execute the mvn command, you can automatically get the Jar file via JitPack.

At the first call, the file is generated on the JitPack side, so it will take some time.

Task

Risk of referencing corrupted source code

Of course, it's possible, and similar things can happen even if you're using Nexus or something.

It is necessary to prevent such accidents by creating rules on how to merge into the master branch and establishing a CI / CD flow.

Problem that takes time when calling for the first time

It's an overhead instead of eliminating the time to package and upload to the Maven Repository, but it can be stressful during actual development.

For the time being, JitPack supports Webhooks, so if you add JitPack Webhooks to github, it seems that pom / jar will be generated automatically at commit time.

https://jitpack.io/docs/BUILDING/#building-ahead-of-time

Instead of summarizing

JitPack is a breakthrough tool that has the potential to change the way Maven Repository has been so far, and in fact it seems to have significant benefits such as simplification of CI / CD flow.

However, there are few documents in Japanese and there are many parts that are different from other Maven Repository products, so it is necessary to master that part.

[JAVA] About JitPack