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