one first step we could try could be adding a "deployToBundle" parameter to the deploy plugin, that would trigger an "at end" behaviour that would build a zip with all the deferred files, instead of copying each file separately
then see how just sending the bundle to the target (file: or https: or scp: or ...) would do the job this could be a minimalistic approach, that would have the benefit of showing "bundle vs individual deploy" approaches njord is that approach on steroids = really manage a local staging area (or name it as you want) and decide in a separate plugin where to put the staging area content and in which detailed format (PUT individual files, send everything as a unique archive, split the archive in smaller ones, or any future strategy) On 2025/07/22 12:14:28 Per Nyfelt wrote: > 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 > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
