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 <[email protected]> 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 >
