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
