I hear a lot of complains about the Sonatype process being not trivial. Here is a background article about why: https://blog.sonatype.com/why-namespacing-matters-in-public-...
[deleted]
Migrating old artifacts from JCenter to MavenCentral
11–20 of 22 posts
Re: Migrating old artifacts from JCenter to MavenCentral
#12I hope a more convenient way is created. I've deployed some projects via Sonatype in the past. And while they are friendly and responsive, it's a complicated process that involves manual approvals by them (for your first release), setting up gpg keys, etc. It takes days for this to happen. It's a big reason jCenter became so popular: it removed a lot of the friction for publishing a simple jar. One thing with jcenter…
I'd agree, same experience.
But see the dependency confusion hack.
Re: Migrating old artifacts from JCenter to MavenCentral
#13I hope a more convenient way is created. I've deployed some projects via Sonatype in the past. And while they are friendly and responsive, it's a complicated process that involves manual approvals by them (for your first release), setting up gpg keys, etc. It takes days for this to happen. It's a big reason jCenter became so popular: it removed a lot of the friction for publishing a simple jar. One thing with jcenter…
If you think you don't need all the checks Sonatype performs for you even after this week's security exploit came up on npm and other less secure repos, you can use this for JVM libs:
EDIT: notice that I am not criticizing jitpack, it's great to be able to point at a git repository and get its jar as a simple dependency... but it's not as secure as Maven Central IMO because it requires you to fully trust `jitpack.io` to not insert malicious code in the jars it serves, as well as the GitHub/BitBucket/GitLab account owner to not have been hacked or "become" malicious... still much better than npm's ridiculous resolution that will just trust anything at all.
Re: Migrating old artifacts from JCenter to MavenCentral
#14I hope a more convenient way is created. I've deployed some projects via Sonatype in the past. And while they are friendly and responsive, it's a complicated process that involves manual approvals by them (for your first release), setting up gpg keys, etc. It takes days for this to happen. It's a big reason jCenter became so popular: it removed a lot of the friction for publishing a simple jar. One thing with jcenter…
github did? https://github.com/features/packages
Re: Migrating old artifacts from JCenter to MavenCentral
#15I wish Java would move to more distributed artifact storage. Just specify URL and let your build tool download library there. Why does it have to be some kind of central storage? It's not like they perform some curating or static analysis or something like that.
> Just specify URL and let your build tool download library there.
All build tools let you do just that. Many companies set up internal mirrors and encourage/force employees not to use Maven central and third party repositories. In fact, Maven central will blacklist IPs that generate too much traffic.
Re: Migrating old artifacts from JCenter to MavenCentral
#16I hope a more convenient way is created. I've deployed some projects via Sonatype in the past. And while they are friendly and responsive, it's a complicated process that involves manual approvals by them (for your first release), setting up gpg keys, etc. It takes days for this to happen. It's a big reason jCenter became so popular: it removed a lot of the friction for publishing a simple jar. One thing with jcenter…
If you think you don't need all the checks Sonatype performs for you even after this week's security exploit came up on npm and other less secure repos, you can use this for JVM libs: https://jitpack.io/ EDIT: notice that I am not criticizing jitpack, it's great to be able to point at a git repository and get its jar as a simple dependency... but it's not as secure as Maven Central IMO because it requires you to full…
A lot of projects publish to Central from cloud CIs. That means that private keys are stored in config/secrets. It is debatable whether that makes the artifacts more reliable since you have to trust the CI.
Re: Migrating old artifacts from JCenter to MavenCentral
#17I hope a more convenient way is created. I've deployed some projects via Sonatype in the past. And while they are friendly and responsive, it's a complicated process that involves manual approvals by them (for your first release), setting up gpg keys, etc. It takes days for this to happen. It's a big reason jCenter became so popular: it removed a lot of the friction for publishing a simple jar. One thing with jcenter…
github did? https://github.com/features/packages
That does not propagate to maven central (at least not that I know). So you have to add a custom repository. You can also use jitpack.io or rsync artifacts to your websiter (I've done both).
Re: Migrating old artifacts from JCenter to MavenCentral
#18I hear a lot of complains about the Sonatype process being not trivial. Here is a background article about why: https://blog.sonatype.com/why-namespacing-matters-in-public-...
And yet world + dog manages fine with a lot less complexity in the Rust, Php, Python, Javscript, Ruby, C++, docker, etc. communities. They all have tools for publishing packages and using them is straightforward and easy.
JCenter managed to work around some of the maven limitations and make the process similarly usable (but you need their gradle or maven plugin). And of course they were allowed to sync packages to maven central. I've done this. It works and was very easy to setup.
So, Sonatype can do better and they should consider doing so. Unless they look forward to manually approving gazillions of requests from stranded JCenter users in the next weeks. Maybe business is that good that they don't care about the overhead. Or alternatively, JFRog's move has prompted them to reconsider whether they want to keep on doing this at all. They are a for profit company after all and they must be similarly affected by big cloud providers putting up their own repositories.
In any case, their process is expensive and convoluted; it always was. It suffers from them having had no competition for being gatekeepers for maven central. There are multiple alternate ways of verifying identity and ownership that don't involve manual approvals, keypairs, etc. It's what everybody else does. Including JCenter and whatever they did seems to have been acceptable to Apache (who own and run maven central).
Re: Migrating old artifacts from JCenter to MavenCentral
#19I hear a lot of complains about the Sonatype process being not trivial. Here is a background article about why: https://blog.sonatype.com/why-namespacing-matters-in-public-...
And yet world + dog manages fine with a lot less complexity in the Rust, Php, Python, Javscript, Ruby, C++, docker, etc. communities. They all have tools for publishing packages and using them is straightforward and easy. JCenter managed to work around some of the maven limitations and make the process similarly usable (but you need their gradle or maven plugin). And of course they were allowed to sync packages to ma…
> Unless they look forward to manually approving gazillions of requests from stranded JCenter users in the next weeks. Maybe business is that good that they don't care about the overhead.
Getting approved for a groupId took me literally 2 minutes. It's really not that complicated.
Not sure yet about the process for actually getting releases approved, I'll see about that tomorrow.
Re: Migrating old artifacts from JCenter to MavenCentral
#20Earlier quoted context omitted.
And yet world + dog manages fine with a lot less complexity in the Rust, Php, Python, Javscript, Ruby, C++, docker, etc. communities. They all have tools for publishing packages and using them is straightforward and easy. JCenter managed to work around some of the maven limitations and make the process similarly usable (but you need their gradle or maven plugin). And of course they were allowed to sync packages to ma…
> Unless they look forward to manually approving gazillions of requests from stranded JCenter users in the next weeks. Maybe business is that good that they don't care about the overhead. Getting approved for a groupId took me literally 2 minutes. It's really not that complicated. Not sure yet about the process for actually getting releases approved, I'll see about that tomorrow.
Took me about half a week last time I tried this. That's from signing up to getting all the approvals needed and finally getting my jar out via maven central. I imagine they may have improved their processes a bit since then but as far as I know it still involves creating tickets in their issue tracker and a human doing stuff with it.