Dumitru Preguza
12/05/2025, 7:47 PMjoffrey
12/05/2025, 8:22 PMjoffrey
12/05/2025, 8:22 PMDumitru Preguza
12/05/2025, 8:34 PMDumitru Preguza
12/05/2025, 8:54 PMjoffrey
12/05/2025, 9:59 PMLet me explain, for example you see a github dependency, you want to check the entire code, you copy paste the URL and you are right in the github repository.
Whereas with maven-central dependency style, you have to google the artifact name, match it with a github/gitlab/butbucket repository, and sometimes companies don’t have matching artifacts for their repo code etcIf the project is open-source, the maven dependencies normally come with a
-sources jar as well, so you don't need to go anywhere, you can navigate to the sources right from your IDE (which already downloaded them). So on the consumer side, it wouldn't be an improvement IMO.joffrey
12/05/2025, 10:09 PMThen it comes deployment of a particular lib, usually pushing something to the git repo and creating the new tag would result in a new release by itself, no need to double push to maven-repository, it results in a clearer workflowYeah, publishing to Maven Central is definitely a pain point on the publisher side, I agree. So indeed it would make things easier for library authors. That said, it also means that the same code has to be compiled as many times as there are builds with this dependency, as opposed to once at publication time, which is a bit sad (and not very eco-friendly 😄). So yeah it is an interesting idea to improve the experience of library authors. At the moment, we believe we can already improve a lot the experience of library authors by providing built-in support for Maven Central publication, and possibly signature setup etc. On Sonatype side they already made some improvements to the process. But as I said, it's not out of the picture. It was actually brought up in recent discussions in the team (in the context of sharing Amper plugins via a github repo).
Dumitru Preguza
12/06/2025, 1:11 AMDumitru Preguza
12/06/2025, 1:14 AM