Well, for *existing* core component I don't see an issue to add a toggle to say "deploy at end". What can be an issue there is only to make it global for the session and not per artifact + how to define "end" - agree onSessionClose can be too late but sure we can find a good "phase" (plain english not maven phases).
I understand you only talk about artifact but makes years it is no more what maven trigger as deployment and we don't have much issue with current solution but we have with combined ones and making it using a different lifecycle will make it even harder to handle, in particular with shared components where lifecycle is no more what is in the pom and therefore you don't control it properly anymore from the pom. Feels like regressing 10 years ago in terms of solution covering for me. I have no idea what you target with your block about sonatype, users are covered by sonatype (both solutions btw at the cost of some jvm.config and deps for the oldest). To be honest, today - and I never said it will not change ;), I don't care much of MDK but more about adding a concept we don't need and which will create new issues in maven so let's try to use one of the existing solutions maybe before moving to building a new maven - or discuss rebuilding maven from scratch if that is the ultimate intent, if we break the compat rule a lot of things can change and concepts can be simplified+refined but AFAIK we are not in this mood, are we? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le lun. 6 mai 2024 à 20:41, Tamás Cservenák <ta...@cservenak.net> a écrit : > And few more things: > - my intent is to target BOTH, Maven3 and Maven4, as when Sonatype > deprecates OSS/S01 in favor of Central Portal, Maven3 (and currently also > Maven4) users are doomed to "roll their own" solutions for Central > publishing. While Sonatype Nx2 (running on Sonatype OSS/S01 and ASF repo) > can work to a certain degree with m-deploy-p (at the "cost" of logging in > to the UI, and pressing Close button on auto-created staging repository), > the new Central Portal will not work with it (as it seems from doco). IMHO, > we cannot leave Maven3 users behind, we cannot afford to leave Maven3 users > without any solution. > - MDK like solution could also provide support in cases like this (my next > task on radar): > https://lists.apache.org/thread/j3r4hvoonx6ftl8vlgs0fo4f2z9pmll5 > - and finally, nothing forces you to use MDK, obviously. If you publish OCI > images or beam up little green people with Maven, you do not have to use > it! Solution is opt-in, that IS one of the key points of MDK :) > > But to have ANY progress on ANY of this: > - the plugin SPIs needs to be created/released > - we need to use SPIs in plugins > - and only then we can provide seamless experience to our users > > > T > > > On Mon, May 6, 2024 at 8:24 PM Tamás Cservenák <ta...@cservenak.net> > wrote: > > > > >> If you don't need to create a new module nor any new interface in maven > >> core or a shared module I'm all for the change, otherwise it is a new > >> shared thing whatever you present it. > >> > > > > So, if we don't change anything, you accept the "change"? :) > > > > In short: MDK is just a "tech demo", but the "real stuff" is: > > * introduce SPIs for targeted o.a.m.p plugins (the proposed ones are > > deploy and gpg plugins) > > * modify o.a.m.p plugins to use SPI pattern (again, m-deploy-p and > m-gpg-p) > > * and from that moment on, we have an "open for all" game in play, as MDK > > becomes really 'just one' solution. > > In fact, IMHO it is the Maven project itself that should be the home of > > something like MDK. > > Again, MDK is "just a tech demo". > > > > > >> I understand what you mean but it is the case of the "current" solution. > >> We don't need a new module nor anything outside plugins scope. > >> The "do at end" on maven built-in components is even a pretty bad > example > >> cause it would be saner for the goal you describe to add a parameter on > >> maven components methods more than a new concept IMHO - concretely > enable > >> this feature in repositorySystem directly which is already shared by > >> design. > >> > > > > This is the case where I'd like to _improve the current solution_ (as > > opposed to "this is what it is, live with it") as I personally am not > > satisfied with it. > > Each provider has its own plugin and "recipe", that you must > > adapt/incorporate (and pray it will not break with the following Maven > > release), and so on and so on. > > Hence the MDK demo and SPI pattern idea. Nothing new, as Maven Core > always > > worked like this, all I did was just documented it and created > > a proof-of-concept (MDK). > > Repository system has no notion of "at (maven) session end", but it does > > have "on session close" (which is happening way-way later). > > We discussed it and also rejected deploying at "on session end", we've > > been already there: https://github.com/apache/maven-resolver/pull/437 > > > > > >> > >> As soon as you make a plugin "living" more than its execution you are no > >> more "dead simple" and have a ton of edge cases as the one you > mentionned > >> which is a simple one where both cases can make sense (don't deploy if > the > >> test fail or let it be deployed - depends if you release or dev, close > to > >> "fail test at end"). > >> If you take the deploy jar + oci container case, the recover case is not > >> trivial, the "deploy at end" is just a broken concept by design and > >> requires something different to recover. > >> > >> What I mean is that we cover way enough cases without adding a new thing > >> in > >> core and that moving just one step further is not sufficient in most > cases > >> so the solution will be complex for a poor concrete gain so we should > >> probably look for something else - but I agree covering it completely is > >> quite more challenging cause either you can embrace reproducible builds > >> and > >> upsert/get-and-update or you have to burn a version (snapshot or not) if > >> you can't recover manually. > >> > > > > Again, IMHO you miss the point: m-deploy-p is not "living" more than > > execution (but, is NOT replaced either!). Quite the opposite! > > It works 'as before', and is really just like a "messenger". It does all > > and according to its config, and lives ONLY thru mojo execution. > > Unsure what you are aiming it with 'make a plugin "living" more than its > > execution' as none of that is happening here. Sigh. > > > > I heard for the first time that "deploy at end" is a broken concept. I > > have to strongly disagree here > > (and I am talking about Maven Artifact deployments, and I did talk > > about that ONLY, all the time. It is you who brought up OCI registry, not > > me) > > > > > > > >> No what you look at is "only artifacts deployment done my way", but it > >> breaks all the cases maven deploys something else - and once again it is > >> not rare today. > >> > >> > > Again, I _did_ talk all the time about "Maven artifact deployment" > > (I thought it was clear, as if you look at SPI, you see Resolver classes. > > You did look at sources, right?) > > You can always bring up any example, like OCI containers, or little green > > men or whatever, > > but how does any of that come here? > > > > T > > >
