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