[JAVA] About JitPack


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


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


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.



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


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.



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



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



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.


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.


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.



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.

Recommended Posts

About JitPack
About =
About method.invoke
About attr_accessor
About Hinemos
About inheritance
About params
About Docker
About Rails 6
About Spring ③
About enum
About polymorphism
About Optional
About hashes
About Dockerfile
About this ()
About devise
About encapsulation
About Docker
About active_hash
About static
About exceptions
About scope
[Maven] About Maven
About exception handling
About Java interface
[Java] About Java 12 features
About Rails routing
About cyclomatic complexity
About exception handling
About AsyncTask Generics
About array multiplication
[Java] About arrays
About ruby ​​form
[Swift] About generics
About Active Storage
About class inheritance.
About Spring AOP
About Ruby Hashes
About singular methods
About getter setter
About build tools
About MacinCloud introduction
[Note] About nil
About keyword arguments
Chew about API
[About double hash]
About installing Cocoapods
Something about java
Where about java
About HttpServlet () methods
About Java features
About ActiveRecord :: PendingMigrationError
About SIGNING_REGION: NoSuchFieldError
About the method
About standard classes
About spring AOP
About Ruby arrays
About Ruby inheritance
About Java threads