[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [m2e-dev] Plugin parameter types are not read from plugin.xml
|
Thanks Mickael for your feedback.
I decided to work around this issue in
gitflow-incremental-builder by using ByteBuddy to auto-add the
enum fields as regular members to the FakeMojo.
https://github.com/vackosar/gitflow-incremental-builder/tree/master/src/main/java/com/vackosar/gitflowincrementalbuild/mojo
The JavaDoc of MojoParametersGeneratingByteBuddyPlugin contains
more context.
Not the prettiest solution but it solves the problem and it is
well "guarded" by various tests.
Cheers,
Falko
Am 17.07.2020 um 08:46 schrieb Mickael
Istria:
I know that this "fake" mojo is a hack, but shouldn't m2e
respect
plugin.xml in all aspects?
Yes, probably.
However, since the plugin.xml is ignored at runtime while
Mojo is not, the Mojo itself can be considered as more
reliable source of info than the plugin.xml; I think m2e
behavior is actually safer (although it might be less
correct).
I would suggest that in case Mojo is not accessible or
isn't a mojo class, the plugin.xml is used and elements
don't get filtered out.
Why is it bypassing the
descriptor and is
reading the types on its own?
Another reason, beyond the higher reliability of the
actual mojo class, is that for complex types/beans and
generics, the plugin.xml cannot give much assistance while
introspecting the mojo can provide a deep completion.
If there are no good reasons to keep that I'd come up with a
PR.
There is a good reason to prefer mojo over plugin.xml; but
that doesn't mean it can't be improved to support your case a
bit better if you want to.
HTH
_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/m2e-dev