Hello Stefan,
I agree the overhead is less for simple plugins but still 1 line vs 5 lines
XML. And I think uniformity is a good thing as well. So either we use
properties or do not for plugins. Or at least document and explain why we do
stuff like we do it.
Best Regards
Mirko Friedenhagen
—
in my pov defining properties for versions of complex plugins that often have
multiple plugins/dependencies defined in a single POM which all have to set to
the same version is ok.
examples for such complex plugins are maven-release-plugin,
maven-surefire/failsave-plugin
for other "simple"
Hello Karl Heinz,I do not see the point, why properties are bad here. Overriding them on the command line is not the main benefit, but in a child project you may override versions with one line of code instead of at least 5 lines.Say you have problems
Hi, currently I'm working on some upgrade in the mojo-parent to get some
plugins upgrades
etc. afterwards I have planned to make a new release of
versions-maven-plugin.
Kind regards
Karl Heinz Marbaise
On Friday, May 22, 2020 at 9:14:18 AM UTC+2, sseifert wrote:
>
> i'm interested in getting
Hi to all,
currently we have some properties in our mojo-parent which define
maven-plugin versions.
I intend to remove them with the next release of the mojo-parent (51)
https://github.com/mojohaus/mojo-parent/issues/91
If there are no objections I will remove them on tuesday (May 26. 2020).
i'm interested in getting a new release of versions-maven-plugin 2.8 - last
release was 1.5 years ago, and there are currently no open issues assigned to
the github milestone [1]
any other open issues that should go into the release?
can I help to get it along? (i've currently only write access