This is indeed a good approach.
The first group doesn't care about this warning, the second one should.
Hervé, can you confirm that in case of *only* specifying the latest
maven-jar-plugin or maven-war-plugin or other packaging plugin, you
won't
get these warnings.
It really matters where the default lifecycle bindings are comings from:
maven-core or packaging plugin.
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
