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
