-
Notifications
You must be signed in to change notification settings - Fork 2
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
Publish to Maven Central #95
Comments
I don't publish anything to Maven Central (MC), and the reasons are explained in this post. In short:
How can you prove that you aren't using the Central Repository? You can't. So in summary, if you do not agree you can only STFU and accept that your artifacts will be distributed under the new terms. And they do not even need to notify you of the change in the terms, because you agreed to "review the Terms of Service from time to time". You become the notification. So I won't be publishing artifacts to MC, and do not understand the people that do. And I wonder if any corporate developer submitting artifacts to MC has ever asked for approval from the legal department of their company. |
Is there an alternative to maven central that i could use? E.g. some other well established maven repository i could get your artifacts from. My main issue with https://css4j.github.io/maven/ is that it's reliability and availability is not guaranteed. Github Packages seems to work but is rather annoying as it requires additional authentication with static credentials (when you're accessing artifacts from outside of github). |
No AFAIK, because there is no real competition. All the other repos belong to specific products: Atlassian, Spring, JBoss...
Why do you say that it is unreliable? It gives you a public history of changes which Maven Central never will. In Maven Notes I say that I do not control the hosting (Github does) and therefore cannot give service guarantees, which is true. My concern is that Apache Maven is designed in a way that punishes small repositories, treating alternative repos as Central-like servers and hitting them with potentially thousands of requests that they cannot handle (404 Not Found). If at some point Github decides that this is unacceptable (and probably is), it may terminate the service. But let's use it meanwhile. Moreover this project is not to blame for the monopolistic behaviors of Apache Maven, which I consider a de facto open core software (I mean, with Sonatype's Nexus product you can configure which Maven repos serve which group Ids, for example, and guess who used to pay the core Maven developers). If people used Gradle instead of Maven I would not have the above concern about the 404s, as Gradle does not do that.
Github Packages isn't a real alternative so far. |
I was mainly refering the uptime guarantees. But, there's also nothing stopping you from just taking the repo down. Not to say that i expect such a thing to happen but i still have to justify why there's another repo configured for our project.
I get your concerns, i'm just looking at it from a usage perspective. Maven Central guarantees that packages are (almost) never deleted and had almost no downtimes in the past.
I'm not blaming anyone, again: i get your point. I was just hoping that this would make it easier to use the lib.
Agreed. |
Would it be possible to publish all artifacts to maven central?
The text was updated successfully, but these errors were encountered: