You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2023/06/26 19:28:32 UTC
Weird behavior in plugin phase resolution
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>
Re: Weird behavior in plugin phase resolution
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <ma...@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 <ma...@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 <ma...@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 <
> mail@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-unsubscribe@maven.apache.org
> >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Weird behavior in plugin phase resolution
Posted by Christoph Läubrich <ma...@laeubi-soft.de>.
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 <ma...@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 <ma...@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 <ma...@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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Weird behavior in plugin phase resolution
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mar. 27 juin 2023 à 08:27, Christoph Läubrich <ma...@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 <ma...@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 <ma...@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-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Weird behavior in plugin phase resolution
Posted by Christoph Läubrich <ma...@laeubi-soft.de>.
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...
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 <ma...@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 <ma...@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Weird behavior in plugin phase resolution
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <ma...@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 <ma...@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-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Weird behavior in plugin phase resolution
Posted by Christoph Läubrich <ma...@laeubi-soft.de>.
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 <ma...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Weird behavior in plugin phase resolution
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <ma...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Weird behavior in plugin phase resolution
Posted by Christoph Läubrich <ma...@laeubi-soft.de>.
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.
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
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)
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.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org