-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Host on Maven Repository #90
Comments
Another problem with jitpack is that it breaks when another project dependency starts with "com.github", making it necessary to break out either the other dependency or the jitpack dependency into another module. |
May I ask whether this deployment is officially sanctioned by the Vault team? (@Sleaker ) |
No, it is an unofficial "mirror" managed by codemc.io, the jenkins job is monitoring this github repo. |
I don't support 3rd party building/hosting because you have to trust the source. Jitpack is currently the official method and I'm not going to endorse self-hosted repositories. |
You say you have to trust the source, that makes sense, I wouldn't want to host my stuff on some repository I don't know either, but what is wrong with repo.maven.apache.org? |
MavenCentral does not really like artifacts that depend on artifacts which are on other repositories, however this stance has more or less changed over the years and it isn't all that bad nowadays. Of course other motivations can also play a role, such as the signing requirement, or others |
The Sonatype team have heavily reworked their standards and requirements. All the video tutorials from 2015 are gone and you have actual guides nowadays. But yeah you have a point, they basically allow hosting of any open source software nowadays, whether it's an API, a library or a dependency for something else. |
In case anyone is wondering why Jitpack is wholly inadequate as a repository solution: I run a build relying on Vault. Locally, it passes. On CI, it passes. On another CI, it fails. On the first CI, Jitpack resolves the artifact and all is well; on the second CI, Jitpack breaks and responds with a 521 error code. |
Jitpack is down at the moment (jitpack/jitpack.io#5337) |
Since this part of Vault is something that should be a dependency for many plugins, it would make sense to publish them somewhere.
The reason why I dislike jitpack is that it's good for snapshots but otherwise your build will take ages and might even need a few retries due to HTTP 500s whenever the gradle cache time has expired.
It would be just more convenient and since there is a versioning scheme in place, it wouldn't hurt to deploy the artifacts somewhere.
The text was updated successfully, but these errors were encountered: