Skip to content
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

Open
MeFisto94 opened this issue May 14, 2020 · 10 comments
Open

Host on Maven Repository #90

MeFisto94 opened this issue May 14, 2020 · 10 comments

Comments

@MeFisto94
Copy link

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.

@MilkBowl MilkBowl deleted a comment from robertlit Jun 13, 2020
@A248
Copy link

A248 commented Aug 1, 2020

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.

@sgdc3
Copy link

sgdc3 commented Dec 6, 2020

@A248
Copy link

A248 commented Dec 6, 2020

May I ask whether this deployment is officially sanctioned by the Vault team? (@Sleaker )

@sgdc3
Copy link

sgdc3 commented Dec 7, 2020

No, it is an unofficial "mirror" managed by codemc.io, the jenkins job is monitoring this github repo.
If @Sleaker wants I can give him edit access to the ci job configuration.

@Sleaker
Copy link
Member

Sleaker commented Dec 9, 2020

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.

@josephjthomas
Copy link

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?
It's the "central repository" where millions of open source artifacts are hosted since 2004.
What is your issue with it? My issue with Jitpack is that it very unreliable in terms of stability, uptime and caching, I have had days where I couldn't build my project because Jitpack was dead.

@Geolykt
Copy link
Contributor

Geolykt commented Jan 4, 2022

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

@josephjthomas
Copy link

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.
Artifact signing is only necessary for release builds, snapshot don't need to be signed, but maven has plugins for that (and so does gradle).

@A248
Copy link

A248 commented Dec 22, 2022

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.

@Geolykt
Copy link
Contributor

Geolykt commented Dec 22, 2022

Jitpack is down at the moment (jitpack/jitpack.io#5337)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants