Robert
[1] https://issues.apache.org/jira/browse/MJAR-183
> And it perfectly detects if on the 8 plugins benefiting from default
> lifecycle
> plugin binding, 6 have a versions defined but only 2 have not then
> inherit the
> version form the default lifecycle plugin bindings
>
>> It really matters where the default lifecycle bindings are comings
from:
>> maven-core or packaging plugin.
>
> currently, they come from default-bindings.xml in core
>
> I'll prepare a Jira issue and a branch for review
>
> Regards,
>
> Hervé
>
>> All this is an interesting feature worth for 3.7.0
>>
>> thanks,
>> Robert
>>
>> On Sun, 13 Jan 2019 04:39:15 +0100, Hervé BOUTEMY
>> <herve.bout...@free.fr>
>>
>> wrote:
>> > we have 2 opposite objectives:
>> > - make default near-empty pom work at best,
>> > - but force people to have defined plugins versions (then not
really
>> > empty pom) to get stable build
>> >
>> > and I checked about the warning message: I was wrong, there is no
>> > warning message when plugins without versions are injected by
default
>> > lifecycle bindings
>> >
>> > Just test for yourself following pom.xml from any beginner:
>> > <project>
>> >
>> > <modelVersion>4.0.0</modelVersion>
>> > <groupId>com.mycompany.app</groupId>
>> > <artifactId>my-app</artifactId>
>> > <version>1.0-SNAPSHOT</version>
>> >
>> > </project>
>> >
>> > it works = what we expect to ease newcomers experience
>> > but there is no warning...
>> >
>> > IMHO, this is where we need to improve the tool, by adding a
warning:
>> > I worked on a PoC of DefaultLifecycleBindingsInjector improvement
that
>> > displays:
>> > [WARNING]
>> > [WARNING] Some problems were encountered while building the
effective
>> > model for com.mycompany.app:my-app:jar:1.0-SNAPSHOT
>> > [WARNING] Using default plugins versions from bindings:
>> > [org.apache.maven.plugins:maven-clean-plugin,
>> > org.apache.maven.plugins:maven-install-plugin,
>> > org.apache.maven.plugins:maven-resources-plugin,
>> > org.apache.maven.plugins:maven-surefire-plugin,
>> > org.apache.maven.plugins:maven-compiler-plugin,
>> > org.apache.maven.plugins:maven-jar-plugin,
>> > org.apache.maven.plugins:maven-deploy-plugin,
>> > org.apache.maven.plugins:maven-site-plugin]
>> > [WARNING]
>> > [WARNING] It is highly recommended to fix these problems because
they
>> > threaten the stability of your build.
>> > [WARNING]
>> > [WARNING] For this reason, future Maven versions might no longer
>>
>> support
>>
>> > building such malformed projects.
>> > [WARNING]
>> >
>> > With this warning, and a parent pom to have an easy fix (instead
of 8
>> > plugins versions definition), IMHO, we have what we strongly need.
>> >
>> > And even better, with this warning in place to avoid people to
>>
>> continue
>>
>> > to rely on default plugins versions (because of the nasty
warning), I
>> > could find upgrading default plugins versions not an issue any
more!!!
>> >
>> > Should we try to go this route?
>> >
>> > Regards,
>> >
>> > Hervé
>> >
>> > Le dimanche 13 janvier 2019, 00:15:38 CET Stephen Connolly a écrit
:
>> >> The original plan was to make plugin version mandatory. Perhaps
>>
>> 3.7.0 is
>>
>> >> the time to do that, with a CLI option (to be removed after
3.7.x) to
>> >> pull
>> >> in the 3.6.x default versions if your pom is missing plugin
versions.
>> >>
>> >> The warning has been there long enough. Let’s pull the trigger.
>> >>
>> >> On Sat 12 Jan 2019 at 21:34, Tibor Digana <tibordig...@apache.org>
>> >>
>> >> wrote:
>> >> > I have a strong reason to update Surefire due to new JRE
versions
>>
>> have
>>
>> >> > been
>> >> > updated too many times last two years.
>> >> > They required a fix done within a few days and some of them are
>> >>
>> >> shaking on
>> >>
>> >> > the chair...
>> >> > Our Maven Core is stable and Java 9+ ready but the obsolete
plugins
>> >>
>> >> are
>> >>
>> >> > not.
>> >> > I want only the same compatibility with default plugins because
>> >>
>> >> people do
>> >>
>> >> > not see these plugins as a distinct community. They are both
Maven
>>
>> and
>>
>> >> > plugins from us Apache, so they most probably would expect it
>> >>
>> >> consistent
>> >>
>> >> > altogether.
>> >> > Makes sense?
>> >> >
>> >> > On Sat, Jan 12, 2019 at 7:24 PM Bernd Eckenfels
>> >>
>> >> <e...@zusammenkunft.net>
>> >>
>> >> > wrote:
>> >> > > I think that’s a real bad idea if you have to do local
>> >>
>> >> modifications to
>> >>
>> >> > > get to a working build environment. Maven is all about not
>> >>
>> >> requiring you
>> >>
>> >> > to
>> >> >
>> >> > > do that (anymore). So even requiring a certain Maven Version
does
>> >>
>> >> not
>> >>
>> >> > > fit
>> >> > > in that pattern (although unavoidable if you do not want to
work
>> >>
>> >> with
>> >>
>> >> > > wrappers).
>> >> > >
>> >> > > So this means: keep old standard versions and overwrite them
>>
>> always
>>
>> >> in
>> >>
>> >> > > poms. (And it means the amount of default versions should be
>> >>
>> >> reduced or
>> >>
>> >> > at
>> >> >
>> >> > > least not add new ones)
>> >> > >
>> >> > > Gruss
>> >> > > Bernd
>> >> > > --
>> >> > > http://bernd.eckenfels.net
>> >> > >
>> >> > > ________________________________
>> >> > > Von: Robert Scholte <rfscho...@apache.org>
>> >> > > Gesendet: Samstag, Januar 12, 2019 5:07 PM
>> >> > > An: Maven Developers List
>> >> > > Betreff: Re: Update versions of all plugins in
>>
>> default-bindings.xml
>>
>> >> > > I had chats with both Adam Bien and Sebastian Daschner asking
>>
>> for a
>>
>> >> > better
>> >> >
>> >> > > way to work with a simple high-speed throw-away development
pom.
>> >> > >
>> >> > > They are both working a lot with Java EE applications and
want to
>> >>
>> >> rely
>> >>
>> >> > > on
>> >> > > defaults as much as possible.
>> >> > > So in a way they don't care about plugin versions.
>> >> > > They only case about things in poms that does matter (unique
to
>>
>> that
>>
>> >> > > project): dependencies
>> >> > > However, with Java 9+ stuff they are forced to specify plugins
>>
>> with
>>
>> >> more
>> >>
>> >> > > recent versions right now.
>> >> > >
>> >> > > So here comes the idea of extensions: you can put it in your
>> >> >
>> >> > maven/lib/ext
>> >> >
>> >> > > ONCE and your pom is again as clean as possible.
>> >> > >
>> >> > > This seems to be a common way of work for some kind of
developers
>> >>
>> >> and it
>> >>
>> >> > > would make sense if Maven could support this.
>> >> > >
>> >> > > To me default plugin versions are bound to a minor Maven
release,
>> >>
>> >> not a
>> >>
>> >> > > major.
>> >> > > When starting with Maven and create your first hello world, it
>> >>
>> >> should
>> >>
>> >> > work
>> >> >
>> >> > > out of the box.
>> >> > > Right now if you are using Java 11, you'll probably hit issues
>> >>
>> >> because
>> >>
>> >> > > some defaults won't work anymore.
>> >> > > That's a bad thing to me and a valid reason to upgrade the
>>
>> plugins.
>>
>> >> > > I do understand Hervé concerns. We should motivate people to
lock
>> >>
>> >> their
>> >>
>> >> > > plugins in their pom.
>> >> > > Most of all the packaging-plugin is important. AFAIK all 3.0+
>> >>
>> >> versions
>> >>
>> >> > > contain plugin bindings, in which case it should be good
enough
>>
>> if
>>
>> >> that
>> >>
>> >> > > plugin is at least specified.
>> >> > >
>> >> > > thanks,
>> >> > > Robert
>> >> > >
>> >> > > On Sat, 12 Jan 2019 16:24:31 +0100, Hervé BOUTEMY
>> >>
>> >> <herve.bout...@free.fr
>> >>
>> >> > > wrote:
>> >> > > > original idea, let's try to evaluate :)
>> >> > > >
>> >> > > > IMHO this could work for packaging plugins in default
>>
>> lifecycle,
>>
>> >> that
>> >>
>> >> > are
>> >> >
>> >> > > > defined in default-bindings.xml, but would not for other
>> >>
>> >> lifecycles
>> >>
>> >> > that
>> >> >
>> >> > > > are
>> >> > > > configured in components.xml (without copy/pasting content
not
>> >>
>> >> related
>> >>
>> >> > to
>> >> >
>> >> > > > plugins)
>> >> > > >
>> >> > > > I don't think an extension would be easier to use than a
>>
>> pom.xml,
>>
>> >> it's
>> >>
>> >> > > > even
>> >> > > > IMHO worse since you have to create a new file in a new
>>
>> directory.
>>
>> >> > > > one question is: is there a use case that an extension would
>> >>
>> >> permit
>> >>
>> >> > that
>> >> >
>> >> > > > a
>> >> > > > parent pom would not?
>> >> > > > the only case I see is if a user does not want to change his
>> >>
>> >> parent
>> >>
>> >> > > > pom
>> >> > > > (or
>> >> > > > cannot): since we don't have "pluginManagement import"
(like we
>> >>
>> >> have
>> >>
>> >> > for
>> >> >
>> >> > > > dependency management).
>> >> > > >
>> >> > > >
>> >> > > > I think for the moment that a parent pom would be more
>>
>> classical,
>>
>> >> > easier
>> >> >
>> >> > > > to
>> >> > > > explain: I don't really see a clear benefit to do the job
as an
>> >> >
>> >> > extension
>> >> >
>> >> > > > instead, this would IMHO make the change harder for users
>> >> > > >
>> >> > > > Regards,
>> >> > > >
>> >> > > > Hervé
>> >> > > >
>> >> > > > Le samedi 12 janvier 2019, 15:42:57 CET Robert Scholte a
écrit
>> >> > > >
>> >> > > >> Just wondering, can this be solved by an extension?
>> >> > > >>
>> >> > > >> So instead of changing this in Maven Core itself, people
can
>>
>> add
>>
>> >> an
>> >>
>> >> > > >> extension to Maven with the latest+stable releases.
>> >> > > >>
>> >> > > >> Hervé and I already discovered that current focus is
mainly on
>> >> > > >> plugins
>> >> > > >> right now. We should also work on extensions.
>> >> > > >>
>> >> > > >> Robert
>> >> > > >>
>> >> > > >> On Sat, 12 Jan 2019 15:37:23 +0100, Hervé BOUTEMY
>> >> > > >> <herve.bout...@free.fr>
>> >> > > >>
>> >> > > >> wrote:
>> >> > > >> > Le vendredi 11 janvier 2019, 12:55:03 CET Tibor Digana a
>>
>> écrit
>>
>> >> > > >> >> ok, Herve, the fact is that these plugins have been
updated
>> >>
>> >> from
>> >>
>> >> > > >> time to
>> >> > > >>
>> >> > > >> >> time.
>> >> > > >> >
>> >> > > >> > yes, we did it in the past (years ago, look at the
history)
>>
>> and
>>
>> >> > > >> > went
>> >> > > >>
>> >> > > >> to
>> >> > > >>
>> >> > > >> > the
>> >> > > >> > conclusion we should not do that to improve
reproducibility,
>> >>
>> >> unless
>> >>
>> >> > > >> > there is a
>> >> > > >> > strong reason to do it sometimes on some specific plugins
>> >> > > >> > = what I'm trying to explain, for the moment without much
>> >>
>> >> success
>> >>
>> >> > > >> > What we could do would be to create a new POM to use as
>>
>> parent
>>
>> >> POM,
>> >>
>> >> > > >> that
>> >> > > >>
>> >> > > >> > would
>> >> > > >> >
>> >> > > >> > define the versions of every plugin from the default
>> >>
>> >> lifecycles:
>> >> > this
>> >> >
>> >> > > >> > would
>> >> > > >> > avoid to have everybody to write the full list of plugins
>> >>
>> >> (which is
>> >>
>> >> > a
>> >> >
>> >> > > >> > pain: I
>> >> > > >> > know because in MARCHETYPES-54 [1] I added the list in
Maven
>> >> > > >> > Archetypes...)
>> >> > > >> > We could name it "maven-default-plugins", or if somebody
>>
>> has a
>>
>> >> > better
>> >> >
>> >> > > >> > idea.
>> >> > > >> > This way, changing plugins versions would not be tied to
>> >>
>> >> changing
>> >>
>> >> > > >> Maven
>> >> > > >>
>> >> > > >> > version
>> >> > > >> >
>> >> > > >> > WDYT?
>> >> > > >> >
>> >> > > >> > Regards,
>> >> > > >> >
>> >> > > >> > Hervé
>> >> > > >> >
>> >> > > >> > [1] https://issues.apache.org/jira/browse/MARCHETYPES-54
>> >> > > >> >
>> >> > > >> >> How can we be on safe side with these updates? What is
>> >>
>> >> mandatory
>> >>
>> >> > > >> >> to
>> >> > > >>
>> >> > > >> do
>> >> > > >>
>> >> > > >> >> for
>> >> > > >> >> such upgrade?
>> >> > > >> >>
>> >> > > >> >> On Fri, Jan 11, 2019 at 7:41 AM Hervé BOUTEMY <
>> >> >
>> >> > herve.bout...@free.fr
>> >> >
>> >> > > >> >> wrote:
>> >> > > >> >> > As I wrote in many Jira issues over years on this
topic,
>> >>
>> >> I'm not
>> >>
>> >> > in
>> >> >
>> >> > > >> >> favor
>> >> > > >> >>
>> >> > > >> >> > of
>> >> > > >> >> > that
>> >> > > >> >> >
>> >> > > >> >> > To me, staying with the same default plugins versions
>>
>> from
>>
>> >> Maven
>> >>
>> >> > > >> >> version
>> >> > > >> >>
>> >> > > >> >> > to
>> >> > > >> >> > Maven version is a feature: nobody should expect to
>>
>> change
>>
>> >> his
>> >>
>> >> > > >> Maven
>> >> > > >>
>> >> > > >> >> > version
>> >> > > >> >> > to change the plugins versions
>> >> > > >> >> > The best practice is to define plugins versions in
your
>> >>
>> >> pom.xml
>> >>
>> >> > (or
>> >> >
>> >> > > >> >> > parent).
>> >> > > >> >> > Getting very old versions of plugins by default is the
>>
>> best
>>
>> >> > > >> additional
>> >> > > >>
>> >> > > >> >> > feature
>> >> > > >> >> > we have after the WARN "plugin version not defined"
>> >> > > >> >> >
>> >> > > >> >> > Then IMHO, upgrading default plugins versions is a bad
>> >>
>> >> idea, is
>> >>
>> >> > > >> >> > a
>> >> > > >>
>> >> > > >> bad
>> >> > > >>
>> >> > > >> >> > message
>> >> > > >> >> > = "you can continue to ignore the WARN on plugins
>>
>> versions
>>
>> >> and
>> >>
>> >> > > >> still
>> >> > > >>
>> >> > > >> >> get
>> >> > > >> >>
>> >> > > >> >> > newest and latest plugins"
>> >> > > >> >> >
>> >> > > >> >> > this leads IMHO to one (bad) reason for people to
require
>> >>
>> >> Maven
>> >>
>> >> > > >> >> Wrapper
>> >> > > >> >>
>> >> > > >> >> > I know, this is counter intuitive, that's why it is
>> >>
>> >> required to
>> >>
>> >> > > >> really
>> >> > > >>
>> >> > > >> >> > take a
>> >> > > >> >> > moment to think about it
>> >> > > >> >> >
>> >> > > >> >> > Regards,
>> >> > > >> >> >
>> >> > > >> >> > Hervé
>> >> > > >> >> >
>> >> > > >> >> > Le jeudi 10 janvier 2019, 17:08:57 CET Tibor Digana a
>>
>> écrit
>>
>> >> > > >> >> > > Why we use old versions in default-bindings.xml?
>> >> > > >> >> > > Can we update all versions in 3.6.1 release?
>> >> > > >> >> > >
>> >> > > >> >> > > Here is MNG-6557 which is related to Surefire but I
>>
>> guess
>>
>> >> this
>> >>
>> >> > > >> Jira
>> >> > > >>
>> >> > > >> >> > > issue
>> >> > > >> >> > > can be freely related to all plugins.
>> >> > > >> >> > >
>> >> > > >> >> > > WDYT?
>> >> > > >> >> > > Any objections to update all plugins and assign this
>> >>
>> >> issue in
>> >>
>> >> > > >> 3.6.1?
>> >> > > >>
>> >> > > >> >> > > Cheers
>> >> > > >> >> > > Tibor
>> >>
>> >>
---------------------------------------------------------------------
>> >>
>> >> > > >> >> > 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
>> >>
>> >>
---------------------------------------------------------------------
>> >>
>> >> > > >> 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
>> >>
>> >>
---------------------------------------------------------------------
>> >>
>> >> > > 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
>>
>> ---------------------------------------------------------------------
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
