Le 24/12/2016 à 17:11, Hervé BOUTEMY a écrit :
Le vendredi 23 décembre 2016, 09:32:50 CET Christian Schulte a écrit :
Am 12/23/16 um 08:16 schrieb Hervé BOUTEMY:
Le vendredi 23 décembre 2016, 03:59:17 CET Christian Schulte a écrit :
Am 12/22/16 um 19:14 schrieb Robert Scholte:
-0.9 for the commandline option, there should be only one truth.
+1
Dependency management is way too important, you should not have an
option
to choose. Better to agree that we are indeed fixing a bug or that we
should maintain the current behavior. And that'll take time. I will have
a
look at all the related issues which could be controlled by this flag
and
find a way to get feedback from more people.
-1 for maintaining the current behavior. Issues will get reported over
and over again.
you keep saying that but don't give any other example than MPLUGIN-296 = a
failure caused by your purist fix in MRESOLVER-8
and you talked about findbugs-maven-plugin, but did not give any pointer
once again, can you give examples of something that MRESOLVER-8 fixes,
apart from the logic of exact resolution?
Why are you questioning making plugin resolution work the same way
project resolution is performed? I don't get that.
please look at "if it ain't broke, don't fix it" proverb, or "never change a
running system"
for example at https://en.wiktionary.org/wiki/if_it_ain't_broke,_don't_fix_it
The bugfix
immediately uncovered a mistake in a POM of a plugin everyone agrees to
be a real issue.
no, I don't agree that it is a real issue
I just verified that selector had that bug right from
the intial resolver contribution outside Apache so has always been
there. Right now only the maven-plugin-plugin version 3.4 is affected.
Version 3.3 and 3.5 are not affected.
I fear it's not only one plugin, but every plugin that applied the
scope=provided recipe that Maven Plugin Tools Annotations promotes
The findbugs-maven-plugin issue
I've been talking about is unrelated to the resolver and is also fixed
in recent releases.
ok, I don't know why you talked about it if it's not related
[...]
I respect logic, since I can imagine that in addition to the case that
worked magically, there can be cases that fail magically = not something
I want forever.
You found a few cases working magically = in fact one recipe based on it,
that is still in our documentation [1] as "<!-- annotations are needed
only to build the plugin -->").
If we didn't find cases failing magically, pressure to change is not the
same.
Things working magically are a recipe for desaster.
disaster didn't happen for years before your work on "fixing" something that
didn't break: remember to read about "if it ain't broke, don't fix it" proverb,
it has to be known and respected at least in some cases
It's just
unpredictable behaviour presented to be something done intentionally
although things are just a matter of luck or bad luck.
that's why I try to know if you have reported cases (as you told) of something
really broken (= something with bad luck)
IIUC, you don't have any case of bad luck
Especially when a
lot of the POMs around are a result of trial and error. Maven should
have produced an error but did not "magically". Chances are great
someone starts applying his findings to each and every project without
ever noticing things really are not working as intended. We should be
super sure that this trial and error always leads to valid POMs.
And of course, this wrong explanation in our doc should be fixed and
explained: I'll work on that (because, remember, I already told I'm
supportive of improvements): I opened MPLUGIN-321 [2], please review and
improve explanations if necessary = this is the start of something that
will also appear in release notes for the version of Maven that will
contaning the updated plugin resolution algorithm (we'll see later if
it's Maven 3.4.0 or not)
There is nothing wrong about that documentation. It's a special case
with the maven-plugin-plugin. Only that plugin must not use "provided"
for the annotations because that plugin is what needs them at runtime.
It is the provider itself. Other plugins should in fact use "provided"
because the annotations are provided by maven-plugin-plugin and not used
by anything else.
ok, I start to understand: no, the plugin does not provide the annotations
dependency (as I wrote in MPLUGIN-321, Maven core uses META-INF/maven/
plugin.xml) but this is one of the rare case where a dependency is simply *not
used* at runtime...
Ok, I now understand the real impact on plugins: no impact in general, only
maven-plugin-plugin is impacted because it uses annotations to extract
information from bytecode to generate META-INF/maven/plugin.xml
I'll improve MPLUGIN-296 description, which is currently at least not clear at
all (which I knew but could not get any useful answer)
But at least, now, I think I better imagine the impact of this bugfix of a bug
that nobody noticed: it just breaks maven-plugin-plugin, which is an edge case
of the bugfix edge case.
I feel more confident now on this one
let's move on evaluating other changes currently in 3.4.0-SNAPSHOT
Yes, I agree with this. The plugin doesn't need to inspect its own
annotations at runtime, so the dependency is "only needed at
compile-time, unused at run-time". The provided scope may be a bit of an
abuse for lack of a "compile-only" scope... but it works. The current
documentation on how to create plugins is correct, clarifying that
nothing is providing the dependency in MPLUGIN-321 is great.
Regards,
Hervé
Regards,
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel
antivirus Avast.
https://www.avast.com/antivirus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
