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 > > > > > > > > >
