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