It CAN be deployed as a single zip but it does not have to be. The downside of deploying each module separately is that if one deployment fails then you end up with a "partial" deploy (from the point of view of the whole project) but I think you only end up in this situation in the beginning when you have not configured everything properly. If we do internal validation first (check that an asc, md5 and sha1 accompanies each artifact) then this kind of error can be eliminated. What remains would then be network errors in which case you would just deploy the failed module again.
Regards, Per On Tue, 22 Jul 2025 at 13:25, Guillaume Nodet <gno...@apache.org> wrote: > And I think that's exactly the problem as the deployment needs to be a > single zip file IIUC. > > Guillaume > > Le mar. 22 juil. 2025 à 12:28, Per Nyfelt <per.nyf...@nordnet.se> a écrit > : > > > > Hi Tamas, > > > > I think it would work. Each part is zipped up and deployed e.g. assuming > > you have a multimodule project like this: > > Aggregator > > - common > > - subA (depends on common) > > - subB (depends on common) > > > > Deploying all of this would mean 4 zip files are created and published > > 1. The aggregator is just the pom (+ asc, md5 and sha1) > > 2. common is the pom, jar, javadoc and sources (all signed and with md5 > and > > sha1 files) > > 3. subA is the pom, jar, javadoc and sources (all signed and with md5 and > > sha1 files) > > 4 subB is the pom, jar, javadoc and sources (all signed and with md5 and > > sha1 files) > > > > That should work fine i think or am i missing something? > > > > Regards, > > Per > > > > On Tue, 22 Jul 2025 at 11:13, Tamás Cservenák <ta...@cservenak.net> > wrote: > > > > > Per, > > > > > > You cannot publish to central using plugin bound to lifecycle as it > will be > > > invoked in every module/subproject... Portal needs "at end; all > artifacts" > > > kind of operation and Maveniverse Njord does that without interference > to > > > your build. > > > > > > Maven4 has improved lifecycle with "after:all" but Maven3 does not, it > > > needs a bit more. > > > > > > T > > > > > > On Tue, Jul 22, 2025, 11:07 Per Nyfelt <per.nyf...@nordnet.se> wrote: > > > > > > > Hi, > > > > How about adding a deployToCentral (or similar) goal to the > > > > maven-deploy-plugin that uses the new API so that this is supported > > > > "natively"? > > > > I would be willing to implement it if you think it's a good idea. > > > > > > > > Regards > > > > Per > > > > > > > > On Tue, 22 Jul 2025 at 10:39, Jon Harper <jon.harpe...@gmail.com> > wrote: > > > > > > > > > Hi Hervé, > > > > > thanks for looking into it. Did you try the sonatype compatibility > > > > > service ? > > > > > > https://central.sonatype.org/publish/publish-portal-ossrh-staging-api > > > > > > > > > > Also, while the governance and roadmap of > > > > > central-publishing-maven-plugin is not open, the code itself is OSS > > > > > (uses the apache license v2 as indicated in the pom > > > > > > > > > > > > > > > > > > https://repo1.maven.org/maven2/org/sonatype/central/central-publishing-maven-plugin/0.8.0/central-publishing-maven-plugin-0.8.0.pom > > > > > ) > > > > > Cheers, > > > > > Jon > > > > > > > > > > On Sat, Jul 19, 2025 at 10:13 PM Hervé Boutemy < > hbout...@apache.org> > > > > > wrote: > > > > > > > > > > > > deep dive done, with personal evaluation > > > > > > > > > > > > https://github.com/apache/maven-studies/tree/deploy > > > > > > > > > > > > happy to discuss and complete the review > > > > > > > > > > > > Le jeudi 17 juillet 2025, 03:53:40 CEST Hervé Boutemy a écrit : > > > > > > > I finally stopped procrastinating and took time to test > > > > > > > > > > > > > > https://github.com/apache/maven-studies/tree/deploy > > > > > > > > > > > > > > This does not yet give me a strong answer about what I > personally > > > > would > > > > > > > choose to promote, but at least better understanding of the > misc > > > > > options > > > > > > > > > > > > > > Le mardi 8 juillet 2025, 08:45:25 CEST Hervé Boutemy a écrit : > > > > > > > > it seems we're back to Maven history of: > > > > > > > > 1. publication to simple file systems (eventually shared) > > > > > > > > 2. multi-module (aka. multi-subproject) publication > > > > > > > > 3. multi-file publication in a single gav > > > > > > > > > > > > > > > > On the positive side, this has been very flexible and > perfect for > > > > > > > > downloads. But on the negative side, this leads to quite > > > undefined > > > > > > > > publication protocol, and misunderstood, even when we tried > to > > > > share > > > > > some > > > > > > > > doc > > > > > > > > > > > > > > > > https://maven.apache.org/repository/layout.html > > > > > > > > > > > > > > > > In the past, the complaint was that there was no "standard" > REST > > > > API > > > > > to > > > > > > > > publish (ignoring that REST did not exist when Maven was > > > growing). > > > > > > > > Now there is a REST API with proper documentation > > > > > > > > > > > > > > > > https://central.sonatype.com/api-doc > > > > > > > > > > > > > > > > We could expect everybody to be happy, but no. > > > > > > > > We are discovering it is perfect for smaller publications. > > > > > > > > But it opens questions for bigger publications. > > > > > > > > > > > > > > > > And yes, we're still in a half undocumented mix of approaches > > > > > > > > (Maven-native > > > > > > > > per-file PUT vs REST API for publishing an archive vs how to > > > split > > > > > multi- > > > > > > > > module?) > > > > > > > > > > > > > > > > > > > > > > > > Reading Njörðr description > > > > > https://maveniverse.eu/docs/njord/what-is-it/, > > > > > > > > it is a Maven Resolver Repository Connector, looks like a > good > > > > > integration > > > > > > > > in the native Maven CLI: please call it something like > "Njörðr > > > > > publisher" > > > > > > > > and I may remember what it does... > > > > > > > > > > > > > > > > I definitively need to dive into it: very interesting. > > > > > > > > And next spte will be to have a wider community understand > all > > > > these > > > > > > > > concepts, as beginning of all the issues is that we're > touching > > > > many > > > > > > > > in-depth aspects that are unknown to many. > > > > > > > > > > > > > > > > One additional TODO on my ever growing TODO list... > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Hervé > > > > > > > > > > > > > > > > Le lundi 7 juillet 2025, 16:48:39 CEST Tamás Cservenák a > écrit : > > > > > > > > > Howdy, > > > > > > > > > > > > > > > > > > Cool that you brought up this topic, thanks! > > > > > > > > > Well, for start, to not repeat myself, a bit of history: > > > > > > > > > > > > https://maveniverse.eu/blog/2025/07/02/pom-proliferation-part-1/ > > > > > > > > > (note: this is in fact a response to completely unrelated > blog > > > > > entry, > > > > > > > > > but is good to "cover the grounds" for now) > > > > > > > > > > > > > > > > > > In short: what today happens with Maven Central (MC) is > totally > > > > > out of > > > > > > > > > scope of ASF Maven Project, that created it. > > > > > > > > > What I also find ironical (or sad) is that project > "causing" MC > > > > > lost > > > > > > > > > native access to it (while with Nx2 ran OSS/S01 you could > use > > > > > > > > > m-deploy-p just fine, from now on, you cannot). > > > > > > > > > > > > > > > > > > Hence, there is no "native" or "out of the box" support for > > > > > publishing > > > > > > > > > for Maven right now. > > > > > > > > > > > > > > > > > > As you know, there are some solutions offered, that are all > > > > > > > > > problematic for me as well: > > > > > > > > > - they either "reinvent" (or force you to) reconfigure > whole > > > > world > > > > > again > > > > > > > > > - or meddle with your build and have different > requirements you > > > > > need > > > > > > > > > to implement > > > > > > > > > > > > > > > > > > Hence, the thing I'd recommend from maveniverse is Njord: > > > > > > > > > https://maveniverse.eu/docs/njord/ > > > > > > > > > > > > > > > > > > That basically (re) implements what Nx2 had, but locally > and > > > adds > > > > > > > > > publishing support as well. > > > > > > > > > This extension was done to fully container all the issues > > > above: > > > > > > > > > - is not "aggressive", literally steps aside > > > > > > > > > - does not require to reconfigure your whole build (you can > > > > publish > > > > > > > > > even non integrated projects with it) > > > > > > > > > - uses Maven and is Maven "native", no parallel worlds > > > > > > > > > > > > > > > > > > Of course, Njord does not help with cases like TrinoDB has > > > (that > > > > is > > > > > > > > > Central Portal server side limitation), > > > > > > > > > and many other things, but is working for many other > projects. > > > > > > > > > > > > > > > > > > Also, as you mentioned, I created this issue (as Njord > suffers > > > > > from it > > > > > > > > > as > > > > > > > > > well): https://github.com/maveniverse/njord/issues/150 > > > > > > > > > > > > > > > > > > HTH > > > > > > > > > Tamas > > > > > > > > > > > > > > > > > > On Sun, Jul 6, 2025 at 2:37 PM Jon Harper < > > > > jon.harpe...@gmail.com> > > > > > > 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 > > > > > > > > > > -m > > > > > > > > > > a > > > > > > > > > > > ven-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 > > > > > > > > > > -m > > > > > > > > > > av > > > > > > > > > > > > > > > en-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 ? > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > > > > > > For additional commands, e-mail: > dev-h...@maven.apache.org > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > > > > > > > > -- > ------------------------ > Guillaume Nodet > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
