It will mean the death of Maven Central, about which I have mixed feelings. On the one hand, Sonatype deserves enormous thanks for what they have done for the open source world, as does mvnrepository.org. Their central repository has been free and maintained for a long time. Thank you, Sonatype.
On the other hand, it took me three days to release a new version of one of my artifacts the other day. The process for doing a Maven deploy is very complex. It took hours to get my private key to work because the key registries were slow. Then the staging server was slow, and kept timing out. Support was responsive, and said they were dealing with a DDOS attack. On top of that, it takes a while for artifacts to show up in the registry even after they have been uploaded. I'm glad that getting that artifact out wasn't an emergency.
This new Github service separates the registry from the artifact storage, which is the right way to do it. The registry should be quick to update because it's only a pointer. The artifact storage will be under my control. Credentials and security should be easier to deal with. I really hope this works out.
Publishing to Maven Central comes with a bunch of requirements (https://central.sonatype.org/pages/requirements.html) may be seen as a burden to packagers, but is certainly a delight for end-users of those packages.
All packages are GPG signed, come with companion source and javadoc artifacts, and are guaranteed a certain amount of other metadata in the POM. There are "easier" repositories (like Bintray jcenter) but anyone who has used something from there that didn't include sources or proper licensing information soon comes to appreciate why it is that Maven Central (and not jcenter) that is the center of the Java ecosystem.
Just compare how well organized and neet are the packages in Maven Cetral to mess in JCenter. JCenter is full of inconsistent trash. I can imagine people pushing packages there for testing and then just forget about them.
Not everyone and not all of them, of course. But while I was looking around to figure out which repository to choose as my main, JCenter has put me off. I still can't understand how people can easily trade convenience for quality.
Unfortunately the GPG signing is worthless because there's no way of attaching trust to each key. So each package has been signed, but anyone could have issued the keys, so an attacker could easily do the same.
Also, not all artifacts have sources and javadoc. Most do but some certainly don't.
So continuing this way GPG is worthless in general. Most of the keys you can't verify in person so there is no trust whatsoever. In this case Sonatype is verifying key for you. They will check if your key belongs to you and you are in control of your organization. Otherwise package would not be accepted.
I may be wrong but source and javadoc are requirements. Maybe there are some old packages without it, but new ones should be complete.
Maybe they're historic and now it's a requirement, or maybe it's prereleases or something, but I have certainly seen some in the past. First one I can dig up: https://repo1.maven.org/maven2/com/google/protobuf/protobuf-...
The newer versions certainly do have sources and javadoc, but you can't assume their presence for everything.
> So each package has been signed, but anyone could have issued the keys, so an attacker could easily do the same.
Not true. The GPG signature means the key belongs to an account with access to the group id (namespace, usually a domain), and that sonatype has verified the group id belongs to the original admin account for that group id.
It's not a lot of guarantees, but you cannot just generate a GPG key, sign a package, and publish to maven central.
Anyone can issue a GPG key claiming to be whatever identity they want though. I've uploaded artifacts to Maven Central before and they didn't do any specific verification of the signing key - so if it just matches the domain that is no protection at all.
You could for example opt for TOFU. Then at least you’d be protected against a malicious takeover unless the attacker manages to access the maintainers private key. That’s been a pretty common issue in the recent past.
> It will mean the death of Maven Central, about which I have mixed feelings
I don't see it as such. A key reason that this offering from GitHub (and the corresponding one for GitLab) is useful is that it simplifies the enterprise stack - things that will never get posted to Maven or npm or DockerHub in the first place.
From the announcement:
> Packages in GitHub inherit the permissions of the repository, and you no longer need to manage third party solutions and sync team permissions across systems.
This impacts locally hosted Nexus repositories. The artifacts that I build for my team that currently get pushed to internal systems can now live along side the source code repository.
From the "What our customers are saying":
> GitHub Package Registry has allowed us to spend more time solving hard problems, and improving patient care. Since it uses the same permissions and security as the rest of GitHub, we spend less time managing multiple accounts, ACLs, and on-premise infrastructure, which leaves us with more time to code what matters!
That is exactly where it is useful.
For maven central, I am pleased to have the governance and management of those systems be part of my deployment chain for third party libraries and I will continue to prefer to pull something from Maven Central rather than somewhere else whenever possible.
I think you've been somewhat unlucky. I've been releasing some code on Maven Central for a while, and while original setup did take some time and was a bit confusing at times, once all keys were in place deploy works with a couple of short steps. It is true the packages do not appear immediately, but I imagine serving this much content requires heavy caching, so I can understand that, and the wait times aren't that outrageous either.
That said, would be interesting what Github's effort comes to. It's always better to have alternatives.
They're literally throwing around money creating new coding tools, languages, buying GitHub, LinkedIn, ... if we were to debate the effectiveness of its spending, there would be a lot to talk about.
2,5 Billion, with money from oversees on which they otherwise would be heavily taxed. They bought a game studio with significant growth potential at 20x its annual profits, but maybe even more important, they bought 54 Million and growing user accounts on a diversity of platforms, of often very young captive users, easily convertible into Microsoft accounts, a number which was poised to expand rapidly.
Indeed, Microsoft has sold and added 100M more Micecraft licenses and accounts since.
From an account acquisition point of view alone, which fairly often is the main driver of these transactions, the deal was a steal. I'd estimate the value of a fresh user account in a desirable demographic to be around $250 for Microsoft. Even the short term projected revenue would be close to $10.
Microsoft projected the deal to pay for itself in 1 year, and while not having followed the case up close, chances are it did.
Disagree about being the death of Maven Central - they are different beasts.
- Central has a global namespace of artifacts. com.google.guava is the same for everyone. This will probably stay the default of open-source libraries.
- GitHub Package Registry has a per-user maven repository, so a local namespace (https://maven.pkg.github.com/OWNER). This is likely to be used by companies internally.
In order to use GH Registry instead of Central, I would have to add a dozen maven repositories to my settings.xml. I doubt many developers will be up for that.
It's made by JFrog (makers of Artifactory), it's been around for while, it supports lots of formats including harder ones like apt, and it makes package distribution about as easy as it can be.
I tried it years ago and it didn't offer signed packages at the time. I ended up just using ansible to build my own rpm/deb repos on a server given to us by a University:
Their support is the worst. I anticipate a 4 day turn around if I ever need to contact them. Scary really.
Their Gradle plugin is pretty bad too; kinda ironic given their prominent position in the Android and Java community. But then, Gradle itself is crazy town so it's hard to blame them too much.
Yea same here. There are way too many workflows already setup around Maven Central. People publish to it from Scala/SBT, Gradle, Clojure/Leiningen, Kotlin, etc. It's not going to be going anywhere any time soon.
Exactly. It’s nice to have competition in the Java package space aside from Maven, Jfrog Artifactory and Nexus. It will take time to build up network effects for Github but if they make a good product I could see it happening eventually. We use Artifactory where I work and the generic aspect of it plus the ecosystem integrations are super nice. I can publish docker images, regular zip files, jar files, Python packages etc and use the same tooling for all of that. GitHub should really push for the one-stop-shop approach here because I feel like that’s going to be their major competitive advantage. That’s where Gitlab has been playing too so I wouldn’t be surprised to see a similar product from them in the near future.
Where do you think most of those project's are managing their code? And of those, what percentage are already publishing releases on GH? I'm willing to wager the migration will be much faster than you think.
I tried publishing a side-project to Maven Central for a few hours, only to give up and publish to Bintray in minutes.
I'm willing to admit I was probably doing it wrong, but I'm glad it forced me to look at other options. There are definitely easier methods of package/publishing out there, and GitHub package registry sounds awesome.
What? Maven Central is here to stay. It will be here even after a nuclear war. Jitpack does the same as GitHub Package Repository (or even simpler) and Maven Central is still here. I don't see why this would change anything.
It will mean the death of Maven Central, about which I have mixed feelings. On the one hand, Sonatype deserves enormous thanks for what they have done for the open source world, as does mvnrepository.org. Their central repository has been free and maintained for a long time. Thank you, Sonatype.
On the other hand, it took me three days to release a new version of one of my artifacts the other day. The process for doing a Maven deploy is very complex. It took hours to get my private key to work because the key registries were slow. Then the staging server was slow, and kept timing out. Support was responsive, and said they were dealing with a DDOS attack. On top of that, it takes a while for artifacts to show up in the registry even after they have been uploaded. I'm glad that getting that artifact out wasn't an emergency.
This new Github service separates the registry from the artifact storage, which is the right way to do it. The registry should be quick to update because it's only a pointer. The artifact storage will be under my control. Credentials and security should be easier to deal with. I really hope this works out.