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