You can take jetty example, no phase -> resolution -> failure if you use a not resolvable version or whatever. If you put a phase which is not "current" one then you get a passing build. This is a very bad end user experience cause you fixed something by a completely wrong solution IMHO.
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 mar. 27 juin 2023 à 08:45, Christoph Läubrich <m...@laeubi-soft.de> a écrit : > Can you please given an example where adding a phases "fixes" the build, > this does not fix anything nor would I suspect a user will use such a > solution to fix something that is completely hypothetical for me, as I > either would fix the error (e.g. wrong group id) or remove the execution > at all... > > > Am 27.06.23 um 08:36 schrieb Romain Manni-Bucau: > > Le mar. 27 juin 2023 à 08:27, Christoph Läubrich <m...@laeubi-soft.de> a > > écrit : > > > >> I'm not sure what snippet you refer to? If you mean the link, I don't > >> see any issue with it, if a phase is specified there is no need to > >> determine the default what might lead to a mojo never executed because I > >> specify a non existing phase or specify one that is not executed at > all... > >> > > > > Exactly, this is an internal reasoning, as explained, from an user > > standpoint you don't see that, you see that adding a phase fixes your > build > > which is wrong and misleading. > > That said I agree with you the behavior can be understood but means we > > should either log something (which can make the convention over config > > questionable depending if we propose to add the phase or not) or always > > resolve plugins. > > > > So to summarize: yes it is explainable as I pointed out in the original > > mail but for end users this looks weird so we have to enhance this > > experience somehow. While we don't question by that action the convention > > over config I'm more than happy with any solution. > > > > > >> > >> Am 27.06.23 um 08:17 schrieb Romain Manni-Bucau: > >>> Well I agree we should be lazy if we can but not at the cost to make > look > >>> like fixing the issue is about adding a phase (which makes the plugin > >>> ignored actually and does not fix the build). > >>> So think the snippet I sent should either always resolve the evaluated > >>> plugins or warn a plugin was wrongly resolved due to its default need. > >>> The choice between both is either we respect our convention over config > >>> mojo or we break it IMHO so I am to resolve it in general - that's the > >>> reasoning. > >>> > >>> 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 mar. 27 juin 2023 à 07:50, Christoph Läubrich <m...@laeubi-soft.de> > a > >>> écrit : > >>> > >>>> The main point is: If my build is "broken" by adding another phase, it > >>>> is not broken by that fact, it was broken before. > >>>> > >>>> > Do you have some example about that, where it is placed it > shouldn't > >>>> > until you use maven-core as a lib and then you have to > reimplement > >> the > >>>> > maven preconditions AFAIK. > >>>> > >>>> I'm not completely sure about the question, but at least in > >>>> integration-test phase I often use different plugins that might pull > in > >>>> a lot of dependencies, also quite often a phase is specified, so if > they > >>>> are now eager resolved it mean that 'mvn clean package' will download > >>>> them eagerly even if never executed while I would more expect it to > only > >>>> download things (like its done with dependencies) if the phase is > >>>> actually executed. > >>>> > >>>> If one want to eager resolve everything one could use > >>>> 'mvn dependency:go-offline' > >>>> > >>>> > It is globally my point, we do an optimization leading to a > "looking > >>>> > inconsistent" behavior (even if we can explain it, it is > >> misleading). > >>>> > >>>> I think such "inconsistencies" do not occur often enough to break the > >>>> general rule to be as lazy as possible to not download things > >>>> unnecessary (unless requested). I would even say this is a very very > >>>> rare case, each time I add something to the pom I immediately execute > >>>> that new "thing" to see its working and would see that error > >> immediately. > >>>> > >>>> > Not sure it is a point since it means the plugin is not part of > the > >>>> build. > >>>> > >>>> At least not of the current executed build, but I thought that was the > >>>> intend here that in such cases no download happen and you maybe miss a > >>>> thing (e.g. wrong group/artifact id). > >>>> > >>>> > >>>> > >>>> Am 27.06.23 um 07:37 schrieb Romain Manni-Bucau: > >>>>> Hi Christoph, > >>>>> > >>>>> Added a few questions inline cause I'm not sure I got it all. > >>>>> > >>>>> 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 mar. 27 juin 2023 à 06:38, Christoph Läubrich < > m...@laeubi-soft.de> > >> a > >>>>> écrit : > >>>>> > >>>>>> Just a few remarks: > >>>>>> > >>>>>> 1) There might be situations were no cache is there so it can hurt > >>>>>> performance to resolve "useless" plugins (e.g. from deploy phase) > and > >>>>>> probably long dependency chains. > >>>>>> > >>>>> > >>>>> Do you have some example about that, where it is placed it shouldn't > >>>> until > >>>>> you use maven-core as a lib and then you have to reimplement the > maven > >>>>> preconditions AFAIK. > >>>>> > >>>>> > >>>>>> > >>>>>> 2) one should not optimize for the error case, if I never test my > >>>>>> project it is not the task of maven to help me in that regards > >>>>>> > >>>>> > >>>>> It is globally my point, we do an optimization leading to a "looking > >>>>> inconsistent" behavior (even if we can explain it, it is misleading). > >>>>> > >>>>> > >>>>>> > >>>>>> 3) If it is cause by a temporary failure I might be happy that my > >> build > >>>>>> still works if I do not execute that phase (yet) > >>>>>> > >>>>> > >>>>> Not sure it is a point since it means the plugin is not part of the > >>>> build. > >>>>> Indeed there are cases like jetty plugin but there are not mainstream > >> and > >>>>> still, means your build setup is not reliable for dev so I even tend > it > >>>> is > >>>>> exactly the opposite which should happen to validate it. > >>>>> If you want the behavior you describe you use profiles in maven world > >>>> which > >>>>> are closer to the behavior you mention, not main plugin section. > >>>>> > >>>>> > >>>>>> > >>>>>> 4) I don't think its inconsistent e.g. if I call mvn validate it > might > >>>>>> not download dependencies, if I call mvn compile only some of them > so > >> in > >>>>>> general it is consistent to delay things as much as possible. > >>>>>> > >>>>> > >>>>> This is the ambiguous part. Seeing it like that can be consistent but > >> as > >>>> an > >>>>> end user you don't see that, you see that adding or not a phase makes > >>>> your > >>>>> build broken or not. > >>>>> This does not "look" consistent at all nor user friendly. > >>>>> I'm not sure of the outcome but we might either force the resolution > of > >>>> all > >>>>> plugins on the "line", ie even when a phase is forced we do resolve > it > >>>>> (which is still compatible with the lazy spirit but by "pipe" instead > >> of > >>>>> item) or we add a log in the case we resolved it for nothing > requesting > >>>>> user to set explicitly the phase which can lead to not using > >> defaultPhase > >>>>> as a good practise which is something I'm very doubtious about and > why > >> I > >>>>> sent this mail. > >>>>> > >>>>> > >>>>>> > >>>>>> Am 26.06.23 um 21:28 schrieb Romain Manni-Bucau: > >>>>>>> Hi all, > >>>>>>> > >>>>>>> With JB Onofré we discussed a surprising behavior of maven plugin > >>>>>> execution > >>>>>>> chain. > >>>>>>> Long story short it is this piece of code: > >>>>>>> > >>>>>> > >>>> > >> > https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/DefaultLifecycleMappingDelegate.java#L93 > >>>>>>> . > >>>>>>> > >>>>>>> The overall idea is: if the phase is not explicit then resolve the > >>>> plugin > >>>>>>> to get its descriptor and check its default phase else use the user > >>>>>>> explicit phase. > >>>>>>> > >>>>>>> This looks quite good and logical and it can save some plugin > >>>> resolution > >>>>>>> (which should be ~0 saved time after first cache). > >>>>>>> > >>>>>>> However it has a major drawback (what JB hit and why we discussed > >> it): > >>>> if > >>>>>>> you have a plugin which can't be resolved for whatever reason, > >> setting > >>>> a > >>>>>>> phase will not make the build being broken until you call it > whereas > >>>> not > >>>>>>> setting a phase will fail whatever lifecycle you call since you > will > >>>> have > >>>>>>> to resolve the plugin to get its default phase. > >>>>>>> > >>>>>>> Wonder if we would gain to just ensure the plugin is always > resolved > >>>> for > >>>>>>> behavior consistency. > >>>>>>> Idea being that setting or not a phase does not have side effects > for > >>>> end > >>>>>>> users. > >>>>>>> > >>>>>>> Side note: didn't check the whole code but can likely apply to > other > >>>>>>> attributes so always resolving sounds like the sanest default to > me. > >>>>>>> > >>>>>>> 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 > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > --------------------------------------------------------------------- > >>>>>> 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 > >
