FTR this one https://github.com/apache/maven-javadoc-plugin/pull/375 I had such size issue with Jetty release when migrating to new central portal but finally used jdk22 and sorry forgot to release the javadoc plugin
On Tue, 8 Jul 2025 at 10:56 am, Olivier Lamy <ol...@apache.org> wrote: > Oh > Javadoc jars size issue because using last jdk? > I can release javadoc plugin next week when back holidays > > On Tue, 8 Jul 2025 at 1:38 am, 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 >> > >> > >> >
