Public repository artifacts on JitPack are immutable after 7 days of publishing. You will see an indicator in the list of versions when a build becomes frozen (snowflake icon). Within the first 7 days they can be re-built to fix any release issues. Even then we recommend creating a patch release instead.
JitPack will also keep hosting artifacts after the originating git repository is deleted. To delete a build you need to have git push permissions to your git repository.
If the project was already built then JitPack will continue serving the existing artifacts. It will not rebuild the project at the new tag. In case you need to redo a release the best option is to create a new version on GitHub.
In your build file set the version of your dependency to anyBranch-SNAPSHOT. This is useful during development but we don’t recommend to be used in production.
You can also customize how often you want Gradle to check for new snapshots - see the Gradle documentation.
Yes. See private repositories
Yes. See Artifact Sharing
Yes. We support mapping your domain name to your GitHub organization. Then instead of ‘com.github.yourcompany’ groupId you can use ‘com.yourcompany’.
Steps:
Example: https://jitpack.io/#io.jitpack/gradle-simple
failed to resolve error in Gradle?There could be a number of reasons so we need to find the cause of this error. The first thing to check is if the build was successful by doing a Look Up on https://jitpack.io.
To get more details run Gradle from command line with --info --refresh-dependencies flags.
The output should contain a line “HTTP Could not get” with the full URL and HTTP Status Code.
Possible reasons:
To re-authorize JitPack for private repositories:
If the error is unclear, feel free to contact Support.
Yes. Register your server in your user page
Yes. Tag folders such as feature/abc are supported. Set the dependency version as feature~abc.
Yes. Branch names such as branch/abc are supported. Set the dependency version as branch~abc.
Absolutely. Once JitPack builds a project it keeps the build artifacts (jar, aar, … files) and continues to serve those for all subsequent requests.
JitPack encourages reproducible builds in general since you need to have a working build file in order to publish artifacts. See also Reproducible Build article by Martin Fowler.
Note that -SNAPSHOT version will always provide the latest build therefore its only recommended during development and not in production.
Build artifact licenses are specified in the originating source code repositories.
Not really. With JitPack you specify which exact version you want and JitPack builds it. The author of the repository controls when to release a new version using GitHub’s releases so from a consumer’s perspective it’s a typical package repository.
Each project is built in its own Docker container that only has access to the project’s source code. It doesn’t have access to other projects or build artifacts. Containers run only with normal user privileges (non root).
All communication between our servers is VPN secured and files produced by the build are served over HTTPS (only).
Private repository builds are protected by authentication and require an access token.
If you’d like to report a security issue please contact [email protected]
If your first build wasn’t successful you can rebuild it. If you Sign In on JitPack.io then you’ll be able to remove the old build and re-requesting it will trigger a new build.
See also Rebuilding
You can use version ranges and Gradle’s dynamic versions for releases. Currently they only resolve to releases that have been built.
implementation 'com.github.User:Repo:1.+'
Up to 15 minutes
JitPack is a public maven repository and serves maven artifacts. In that sense it is similar to Maven Central. However, JitPack takes a completely different approach to how you get your artifacts in the repository. With Maven Central you build the artifacts yourself and then upload them. With JitPack you create a git tag for a release and it will build the artifacts from source.
peer not authenticated error in Gradle?If you are running Gradle on Linux you might get the peer not authenticated error. There are at least two ways to solve this:
You can but the recommended way is always to build from source.
Sometimes you already have an existing artifact (.aar,.jar) as your dependency. For example, it may be provided by a third party without the source so you can’t build it on JitPack.
There are a couple of ways of dealing with this:
With option 2. the third party artifact becomes available as a Gradle/Maven dependency on JitPack.
JitPack creates sha and md5 checksums for all artifacts. Artifact signing is not yet available; however, we are planning to add it as well.
Read timed out error in Gradle?Since version 4.3 Gradle has reduced HTTP timeouts which can cause downloads to time out when JitPack waits for a build to finish. To increase timeouts add these settings to your gradle.properties file:
systemProp.org.gradle.internal.http.connectionTimeout=180000
systemProp.org.gradle.internal.http.socketTimeout=180000
Invoices are available on your user page - Sign In and click on your username (https://jitpack.io/w/user). You can also receive invoices by email if you add an email address on your user page.
No access tokenWhen JitPack detects a private repository it caches this result for 1 hour. So, after you change your repository to public you still need to wait 1 hour to be able to access it without authentication.
Contact Support or open an issue on GitHub
(c) 2022 JitPack.io
