We have a plugin-based system so these are sources + tests + javadocs + plugins + server assembly (alone it's 1 GB)
On Mon, Jul 7, 2025 at 4:47 PM Andres Almiray <aalmi...@gmail.com> wrote: > I'm sorry, what? A single release encompassing 5.9Gb ?!?! > > This is not good, not good at all. Please tell you're uploading a full > product (ZIPs, and what not) other than just JARs and POMs. > If you do, _please_ stop. Do Not use Maven Central as a file storage just > because it's convenient to upload via the Maven deploy protocol. Use cloud > storage or upload to a GitHub Packages, or something else. Keep Maven > Central useful for its original purpose: resolve and download JAR > dependencies. > > OTOH if you release is comprised of JARs and POMs and it's still 5.9Gb ... > I have no words. > > If you think it's worth while pushing so much data for a single release and > those bits _must_ be consumed from Maven Central then approach Sonatype and > ask them for their bank details and pay them for the storage. > > ------------------------------------------- > Java Champion; Groovy Enthusiast > https://andresalmiray.com > https://www.linkedin.com/in/aalmiray > -- > What goes up, must come down. Ask any system administrator. > There are 10 types of people in the world: Those who understand binary, and > those who don't. > To understand recursion, we must first understand recursion. > > > On Mon, Jul 7, 2025 at 4:38 PM Mateusz Gajewski < > mateusz.gajew...@starburstdata.com> wrote: > > > I’d like to migrate to sonatype central but it introduced new set of > > limitations that made our project (Trino) unreleasable (2 gb upload limit > > where our project is 5.9 Gb) :) > > > > I have no idea what was wrong with the previous approach (create staging > > repo, upload multiple files, close repo, promote) > > > > On Mon, Jul 7, 2025 at 16:31 Michael Osipov <micha...@apache.org> wrote: > > > > > On 2025/07/06 12:36:02 Jon Harper wrote: > > > > Hi everyone, > > > > I think it would be very beneficial for the community that the maven > > > > dev team communicates on the current events of the sunset of OSSRH. > > > > Otherwise, I think there is a big risk of uncertainty and division in > > > > the community. > > > > > > > > Quoting Romain ( > > > > https://lists.apache.org/thread/bf3762lvd8l64hwyny7rnp3m6r852b9h ) > > > > from a year ago > > > > "most of us using central outside the asf will be impacted sometime > > > > next year probably" > > > > > > > > And now this time has come (note: I shamefully procrastinated the > > > > ossrh migration until I was forced to, but like many people I > > > > guess..). Unfortunately, it coincides with the last stages of the > > > > maven 4 release, so I understand that everyone is very busy at the > > > > moment. > > > > > > > > Maven is a tool that communicates with the outside world, so I would > > > > think it's legitimate for the maven devs to publicly express their > > > > guidelines. Unfortunately it's not an easy task (as a matter of fact, > > > > the best resource I currently know for this is the personal blog of > > > > Karl Heinz Marbaise), but maybe an email discussion can lay enough > > > > foundations by gathering many opinions so that a coherent message can > > > > be sent to the community ? > > > > > > > > Aggravating factors in central-publishing-maven-plugin that lead to > > > > uncertainty according to me: > > > > - Similarity with the standard maven-deploy-plugin. Sonatype even has > > > > a compatibility service but its use is discouraged ("We hope that > over > > > > time plugins will adopt the Portal API rather than rely on this > > > > service" in > > > https://central.sonatype.org/publish/publish-portal-ossrh-staging-api/ > > > > ). > > > > - No public scm system available makes it hard to get context > > > > information ( > > > > > > https://repo1.maven.org/maven2/org/sonatype/central/central-publishing-maven-plugin/0.8.0/central-publishing-maven-plugin-0.8.0.pom > > > > lists https://github.com/sonatype/central-publishing-maven-plugin > but > > > > is 404). (Note: The code is still available in the source jar > > > > alongside the plugin > > > > > > > > > > https://repo1.maven.org/maven2/org/sonatype/central/central-publishing-maven-plugin/0.8.0/central-publishing-maven-plugin-0.8.0-sources.jar > > > > ) > > > > - central-publishing-maven-plugin uses <extension>true</extension> to > > > > forcefully remove any invocation of the maven-deploy-plugin which I > > > > found surprising (aggressive ?) behavior. > > > > - impossible as of 0.8.0 to use central-publishing-maven-plugin > behind > > > > a corporate proxy which ( by virtue of the http client5 of apache > > > > httpcomponents without the extra code required to allow proxies ...) > > > > - looks like fighting instead of cooperating (even though the plugin > > > > architecture of maven invites this kind of work, maybe it's better > > > > when core functionality stays within the maven umbrella like the > > > > maven-deploy-plugin?) > > > > > > > > What are your thoughts ? Are the recent improvements to the > > > > maven-deploy-plugin strong enough the try and unite all publishing > > > > plugins as one ? > > > > > > Worst BS approach I have ever seen for an OSS ecosystem w/o having the > > > code for the deployment not using standard plugins. I don't understand > > why > > > Sonatype reinvented the wheel and had to make like so complicated. This > > > will scare off even more people. > > > > > > M > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > >
