Well not sure what you didn't get from my mails but 1. I agree current solution does not need anything new if it was ambiguous 2. the mail you reference was for jreleaser outside maven so out of topic there IMHO
If MDK does not need an external SPI I agree with you there is no new concept nor need of any maven thread since we don't change anything ;) 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 à 21:02, Tamás Cservenák <ta...@cservenak.net> a écrit : > > > > > > 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). > > > > Which *existing* core component deploys today in Maven? > "At Maven Session end" (and no errors happened) is pretty good plain > english for me. > > > > > > 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. > > > > Nobody mentioned a different lifecycle, only you. > MDK is totally the opposite of what you write... > Current m-deploy-p solution (the one you consider "good") is unchanged > since Maven 2.x, so unsure what regressing you talk about. > To be precise, is unchanged since 18 years, so 10 years sounds quite good, > no? (a joke) > > > > 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). > > > > Does not sound to me like what you say stands: > https://lists.apache.org/thread/6t95xpkgjpxooljf613xf1853qrfv7yq > > I don't feel "covered", sorry. Also, remember that (old) nx-staging-m-p > already broke once in Maven 3.9.x span. > > > > 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? > > > > > You do it again: which "new concept" is added exactly by MDK? > (as everything else works based on existing and proven patterns). > > T >
