Re: Update versions of all plugins in default-bindings.xml

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Update versions of all plugins in default-bindings.xml

Anders Hammar
IMHO it shouldn't be done in a patch release, but rather a minor release
(3.7.0).

/Anders (mobile)

Den tors 10 jan. 2019 17:09 skrev Tibor Digana <[hidden email]>:

> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Update versions of all plugins in default-bindings.xml

Tibor Digana
ok, Herve, the fact is that these plugins have been updated from time to
time.
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Update versions of all plugins in default-bindings.xml

Robert Scholte-8
In reply to this post by Anders Hammar
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 <[hidden email]>  
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  
>> <[hidden email]>
>>
>> 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 <[hidden email]>
>> >>
>> >> 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: [hidden email]
>> >> > For additional commands, e-mail: [hidden email]
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Update versions of all plugins in default-bindings.xml

Hervé BOUTEMY
In reply to this post by Anders Hammar
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 <[hidden email]> 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 <[hidden email]>
> >
> > 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 <[hidden email]>
> > > 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 <[hidden email]
> > >
> > > 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
> > > >> <[hidden email]>
> > > >>
> > > >> 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 <
> >
> > [hidden email]
> >
> > > >> >> 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: [hidden email]
> > > >> >> > For additional commands, e-mail: [hidden email]
> >
> > ---------------------------------------------------------------------
> >
> > > >> > To unsubscribe, e-mail: [hidden email]
> > > >> > For additional commands, e-mail: [hidden email]
> > > >>
> > > >> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: [hidden email]
> > > >> For additional commands, e-mail: [hidden email]
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Update versions of all plugins in default-bindings.xml

Enrico Olivelli
Il dom 13 gen 2019, 12:53 Stephen Connolly <[hidden email]>
ha scritto:

> I think where we want to go is warnings and no version injected. Thus if
> you ignore the warnings you get latest version always *and* we don’t have
> to update the versions ever. ;-)
>
> Add a CLI option to fail if versions unspecified.
>
> Start publishing base parent poms defining a profile of plugin versions
> (and when 5.0.0 comes along they become mixins)
>
> If we publish a base parent pom then users can just follow that. It could
> use semver to decide how aggressively to bump versions.
>
> Imho we need to get out of the game of supplying versions to users from the
> Maven tool itself
>


I totally agree with this Stephen's proposal ! It is the right choice in
the mid term.

The only variant would be to have empty binding by default, so that without
and plugin Maven does mostly nothing (with a warning ?)

Enrico


> On Sun 13 Jan 2019 at 11:16, Tibor Digana <[hidden email]> wrote:
>
> > Robert, your email still was not totally concrete.
> > I understand it like this; the warnings proposed by Herve been introduced
> > in the nearest version 3.6.x, and an update of default bindings in 3.7.0.
> > Do we understand it in the same roadmap?
> >
> > In my experiences, developers do not read warnings because they do not
> have
> > time and they expect Maven been an executor which should "just work".
> Even
> > nobody cares in the log at all except the end, whether it is BUILD
> SUCCESS
> > or failure. And then the people track failed tests or compilations
> errors,
> > but never the log or warnings on the top, never.
> >
> > T
> >
> >
> > On Sun, Jan 13, 2019 at 11:37 AM Robert Scholte <[hidden email]>
> > wrote:
> >
> > > 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 <
> [hidden email]
> > >
> > >
> > > 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 <[hidden email]>
> > > >> 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
> > > >> <[hidden email]>
> > > >> >
> > > >> > 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 <[hidden email]>
> > > >> > > 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
> > > >> <[hidden email]
> > > >> > >
> > > >> > > 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
> > > >> > > >> <[hidden email]>
> > > >> > > >>
> > > >> > > >> 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 <
> > > >> >
> > > >> > [hidden email]
> > > >> >
> > > >> > > >> >> 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:
> [hidden email]
> > > >> > > >> >> > For additional commands, e-mail:
> > [hidden email]
> > > >> >
> > > >> >
> > ---------------------------------------------------------------------
> > > >> >
> > > >> > > >> > To unsubscribe, e-mail: [hidden email]
> > > >> > > >> > For additional commands, e-mail: [hidden email]
> > > >> > > >>
> > > >> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> > > >> To unsubscribe, e-mail: [hidden email]
> > > >> > > >> For additional commands, e-mail: [hidden email]
> > > >> > > >
> > > >> > > >
> > > >>
> ---------------------------------------------------------------------
> > > >> > > > To unsubscribe, e-mail: [hidden email]
> > > >> > > > For additional commands, e-mail: [hidden email]
> > > >> > >
> > > >> > >
> > > >>
> ---------------------------------------------------------------------
> > > >> > > To unsubscribe, e-mail: [hidden email]
> > > >> > > For additional commands, e-mail: [hidden email]
> > > >
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> --
> Sent from my phone
>
--


-- Enrico Olivelli
Reply | Threaded
Open this post in threaded view
|

Re: Update versions of all plugins in default-bindings.xml

Hervé BOUTEMY
In reply to this post by Hervé BOUTEMY
thank you for the improved message: yes, we'll need help to define the right message since it will be seen by many many users who are quite new to Maven...

To help on plugins upgrade, there is versions:display-plugin-updates
https://www.mojohaus.org/versions-maven-plugin/display-plugin-updates-mojo.html

Perhaps a FAQ page on Maven site will be useful

Regards,

Hervé

Le dimanche 13 janvier 2019, 07:45:19 CET David Jencks a écrit :

> I think the warning is a really good idea but I don’t think this wording
> will mean anything to the average maven user, as I don’t understand from it
> what I should do to fix the problem. How about something like: “Specify
> explicit versions for these plugins in the project pom or an ancestor
> pom:...”
>
> If someone is maintaining plug-in versions manually is there a tool to point
> out all the upgrade possibilities?
>
> Thanks
> David Jencks
> Sent from my iPhone
>
> > On Jan 12, 2019, at 7:39 PM, Hervé BOUTEMY <[hidden email]> 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 <[hidden email]>
> >>> 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 <[hidden email]>
> >>>
> >>> 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 <[hidden email]>
> >>>> 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
> >>>> <[hidden email]
> >>>>
> >>>> 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
> >>>>>> <[hidden email]>
> >>>>>>
> >>>>>> 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 <
> >>>
> >>> [hidden email]
> >>>
> >>>>>>>> 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: [hidden email]
> >>>>>>>>> For additional commands, e-mail: [hidden email]
> >>>
> >>> ---------------------------------------------------------------------
> >>>
> >>>>>>> To unsubscribe, e-mail: [hidden email]
> >>>>>>> For additional commands, e-mail: [hidden email]
> >>>>>>
> >>>>>> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: [hidden email]
> >>>>>> For additional commands, e-mail: [hidden email]
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: [hidden email]
> >>>>> For additional commands, e-mail: [hidden email]
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: [hidden email]
> >>>> For additional commands, e-mail: [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Update versions of all plugins in default-bindings.xml

Tibor Digana
In reply to this post by Hervé BOUTEMY
Herve, and only those two plugins would appear in the Warning?
Reading StephenC email, this reminds me to think of an algorithm which
downloads the latest version for these two plugins from Maven Central. Here
the question is; Do we need to use default bindings in lifecycle plugin
online builds?

On Sun, Jan 13, 2019 at 6:48 PM Hervé BOUTEMY <[hidden email]> wrote:

> Le dimanche 13 janvier 2019, 11:37:43 CET Robert Scholte a écrit :
> > 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.
> I don't understand why you are talking about "latest": this has to do with
> versions injected from default lifecycle plugin bindings, whatever the
> version
> is
> 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 <[hidden email]
> >
> >
> > 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 <[hidden email]>
> > >>
> > >> 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
> > >>
> > >> <[hidden email]>
> > >>
> > >> > 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 <[hidden email]>
> > >> > > 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
> > >>
> > >> <[hidden email]
> > >>
> > >> > > 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
> > >> > > >> <[hidden email]>
> > >> > > >>
> > >> > > >> 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 <
> > >> >
> > >> > [hidden email]
> > >> >
> > >> > > >> >> 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: [hidden email]
> > >> > > >> >> > For additional commands, e-mail:
> [hidden email]
> > >> >
> > >> >
> ---------------------------------------------------------------------
> > >> >
> > >> > > >> > To unsubscribe, e-mail: [hidden email]
> > >> > > >> > For additional commands, e-mail: [hidden email]
> > >>
> > >> ---------------------------------------------------------------------
> > >>
> > >> > > >> To unsubscribe, e-mail: [hidden email]
> > >> > > >> For additional commands, e-mail: [hidden email]
> > >>
> > >> ---------------------------------------------------------------------
> > >>
> > >> > > > To unsubscribe, e-mail: [hidden email]
> > >> > > > For additional commands, e-mail: [hidden email]
> > >>
> > >> ---------------------------------------------------------------------
> > >>
> > >> > > To unsubscribe, e-mail: [hidden email]
> > >> > > For additional commands, e-mail: [hidden email]
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Update versions of all plugins in default-bindings.xml

Robert Scholte-8
In reply to this post by Hervé BOUTEMY
I would say: we need to externalize this configuration.

It should be possible to create a jar-file with a minimum pom, but Maven  
should know which plugin belongs to which packaging. So we always need to  
have this mapping, and it would make it easier for custom packaging types  
to register their plugin too.
If we need to keep this mapping anyway, I'd prefer to include the version  
anyway. Especially if we're going to introduce a maven-wrapper-plugin,  
then it makes sense to keep the versions in Maven Core to get the most  
reliable build setup.

thanks,
Robert

On Sun, 13 Jan 2019 12:44:49 +0100, Stephen Connolly  
<[hidden email]> wrote:

> I think where we want to go is warnings and no version injected. Thus if
> you ignore the warnings you get latest version always *and* we don’t have
> to update the versions ever. ;-)
>
> Add a CLI option to fail if versions unspecified.
>
> Start publishing base parent poms defining a profile of plugin versions
> (and when 5.0.0 comes along they become mixins)
>
> If we publish a base parent pom then users can just follow that. It could
> use semver to decide how aggressively to bump versions.
>
> Imho we need to get out of the game of supplying versions to users from  
> the
> Maven tool itself
>
> On Sun 13 Jan 2019 at 11:16, Tibor Digana <[hidden email]> wrote:
>
>> Robert, your email still was not totally concrete.
>> I understand it like this; the warnings proposed by Herve been  
>> introduced
>> in the nearest version 3.6.x, and an update of default bindings in  
>> 3.7.0.
>> Do we understand it in the same roadmap?
>>
>> In my experiences, developers do not read warnings because they do not  
>> have
>> time and they expect Maven been an executor which should "just work".  
>> Even
>> nobody cares in the log at all except the end, whether it is BUILD  
>> SUCCESS
>> or failure. And then the people track failed tests or compilations  
>> errors,
>> but never the log or warnings on the top, never.
>>
>> T
>>
>>
>> On Sun, Jan 13, 2019 at 11:37 AM Robert Scholte <[hidden email]>
>> wrote:
>>
>> > 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  
>> <[hidden email]
>> >
>> >
>> > 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 <[hidden email]>
>> > >> 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
>> > >> <[hidden email]>
>> > >> >
>> > >> > 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 <[hidden email]>
>> > >> > > 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
>> > >> <[hidden email]
>> > >> > >
>> > >> > > 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
>> > >> > > >> <[hidden email]>
>> > >> > > >>
>> > >> > > >> 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 <
>> > >> >
>> > >> > [hidden email]
>> > >> >
>> > >> > > >> >> 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:  
>> [hidden email]
>> > >> > > >> >> > For additional commands, e-mail:
>> [hidden email]
>> > >> >
>> > >> >
>> ---------------------------------------------------------------------
>> > >> >
>> > >> > > >> > To unsubscribe, e-mail: [hidden email]
>> > >> > > >> > For additional commands, e-mail: [hidden email]
>> > >> > > >>
>> > >> > > >>
>> > >>  
>> ---------------------------------------------------------------------
>> > >> > > >> To unsubscribe, e-mail: [hidden email]
>> > >> > > >> For additional commands, e-mail: [hidden email]
>> > >> > > >
>> > >> > > >
>> > >>  
>> ---------------------------------------------------------------------
>> > >> > > > To unsubscribe, e-mail: [hidden email]
>> > >> > > > For additional commands, e-mail: [hidden email]
>> > >> > >
>> > >> > >
>> > >>  
>> ---------------------------------------------------------------------
>> > >> > > To unsubscribe, e-mail: [hidden email]
>> > >> > > For additional commands, e-mail: [hidden email]
>> > >
>> > >
>> > >
>> > >
>> > >  
>> ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: [hidden email]
>> > > For additional commands, e-mail: [hidden email]
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>> >

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Update versions of all plugins in default-bindings.xml

Hervé BOUTEMY
In reply to this post by Tibor Digana
Le dimanche 13 janvier 2019, 20:21:07 CET Tibor Digana a écrit :
> Herve, and only those two plugins would appear in the Warning?
yes, we can do that if we want: you'll see that soon in MNG-6562 branch that I
will push

> Reading StephenC email, this reminds me to think of an algorithm which
> downloads the latest version for these two plugins from Maven Central.
2 plugins?

> Here
> the question is; Do we need to use default bindings in lifecycle plugin
> online builds?
online builds?

everybody: don't hesitate to have a look at LifecycleBindingsInjector.java:
you'll see where the "magic" currently happens, and imagine how you could
inject more complex algorithm than the current LifeCyclePluginAnalyzer, and
eventually if this will remain as dreams...

Regards,

Hervé


>
> On Sun, Jan 13, 2019 at 6:48 PM Hervé BOUTEMY <[hidden email]> wrote:
> > Le dimanche 13 janvier 2019, 11:37:43 CET Robert Scholte a écrit :
> > > 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.
> >
> > I don't understand why you are talking about "latest": this has to do with
> > versions injected from default lifecycle plugin bindings, whatever the
> > version
> > is
> > 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 <[hidden email]
> > >
> > > 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 <[hidden email]>
> > > >>
> > > >> 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
> > > >>
> > > >> <[hidden email]>
> > > >>
> > > >> > 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 <[hidden email]>
> > > >> > > 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
> > > >>
> > > >> <[hidden email]
> > > >>
> > > >> > > 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
> > > >> > > >> <[hidden email]>
> > > >> > > >>
> > > >> > > >> 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 <
> > > >> >
> > > >> > [hidden email]
> > > >> >
> > > >> > > >> >> 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: [hidden email]
> >
> > > >> > > >> >> > For additional commands, e-mail:
> > [hidden email]
> >
> >
> > ---------------------------------------------------------------------
> >
> > > >> > > >> > To unsubscribe, e-mail: [hidden email]
> > > >> > > >> > For additional commands, e-mail: [hidden email]
> > > >>
> > > >> ---------------------------------------------------------------------
> > > >>
> > > >> > > >> To unsubscribe, e-mail: [hidden email]
> > > >> > > >> For additional commands, e-mail: [hidden email]
> > > >>
> > > >> ---------------------------------------------------------------------
> > > >>
> > > >> > > > To unsubscribe, e-mail: [hidden email]
> > > >> > > > For additional commands, e-mail: [hidden email]
> > > >>
> > > >> ---------------------------------------------------------------------
> > > >>
> > > >> > > To unsubscribe, e-mail: [hidden email]
> > > >> > > For additional commands, e-mail: [hidden email]
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Update versions of all plugins in default-bindings.xml

Robert Scholte-8
In reply to this post by Anders Hammar
On Sun, 13 Jan 2019 21:03:20 +0100, Hervé BOUTEMY <[hidden email]>  
wrote:

> Le dimanche 13 janvier 2019, 20:22:15 CET Robert Scholte a écrit :
>> On Sun, 13 Jan 2019 18:48:29 +0100, Hervé BOUTEMY  
>> <[hidden email]>
>>
>> wrote:
>> > Le dimanche 13 janvier 2019, 11:37:43 CET Robert Scholte a écrit :
>> >> 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.
>> >
>> > I don't understand why you are talking about "latest": this has to do
>> > with
>> > versions injected from default lifecycle plugin bindings, whatever the
>> > version
>> > is
>>
>> I'm saying latest, because we recently started to add these  
>> configurations
>> to the packaging-plugin, I'm just not sure if all plugins already  
>> contain
>> it and since which version. For maven-jar-plugin it is 3.0.0 via
>> MJAR-183[1]
> IMHO, if we want to get the default bindings from configuration file  
> inside a
> plugin jar instead or maven-core, we'll still need to define which plugin
> version to look at, or we'll have reproducibility issues
> then in any case, LATEST is not a choice

Totally agree and this is exactly what's happening inside that file[1]


[1]  
https://github.com/apache/maven-jar-plugin/blob/master/src/main/filtered-resources/META-INF/plexus/components.xml#L67

>
>>
>> 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
>> >> <[hidden email]>
>> >>
>> >> 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 <[hidden email]>
>> >> >>
>> >> >> 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
>> >> >>
>> >> >> <[hidden email]>
>> >> >>
>> >> >> > 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 <[hidden email]>
>> >> >> > > 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
>> >> >>
>> >> >> <[hidden email]
>> >> >>
>> >> >> > > 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
>> >> >> > > >> <[hidden email]>
>> >> >> > > >>
>> >> >> > > >> 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 <
>> >> >> >
>> >> >> > [hidden email]
>> >> >> >
>> >> >> > > >> >> 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:  
>> [hidden email]
>> >>
>> >> >> > > >> >> > For additional commands, e-mail:
>> >> [hidden email]
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >>
>> >> >> > > >> > To unsubscribe, e-mail: [hidden email]
>> >> >> > > >> > For additional commands, e-mail:  
>> [hidden email]
>> >> >>
>> >> >>  
>> ---------------------------------------------------------------------
>> >> >>
>> >> >> > > >> To unsubscribe, e-mail: [hidden email]
>> >> >> > > >> For additional commands, e-mail: [hidden email]
>> >> >>
>> >> >>  
>> ---------------------------------------------------------------------
>> >> >>
>> >> >> > > > To unsubscribe, e-mail: [hidden email]
>> >> >> > > > For additional commands, e-mail: [hidden email]
>> >> >>
>> >> >>  
>> ---------------------------------------------------------------------
>> >> >>
>> >> >> > > To unsubscribe, e-mail: [hidden email]
>> >> >> > > For additional commands, e-mail: [hidden email]
>> >> >
>> >> >  
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: [hidden email]
>> >> > For additional commands, e-mail: [hidden email]
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Update versions of all plugins in default-bindings.xml

Hervé BOUTEMY
In reply to this post by Anders Hammar
PR also created :)
https://github.com/apache/maven/pull/233

Le lundi 14 janvier 2019, 12:06:40 CET Hervé BOUTEMY a écrit :

> MNG-6562 Jira issue [1] and Git branch [2] created: please review and
> comment
>
> I'll start to work on the new parent POM that locks down versions of plugins
> from default lifecycle bindings: see MPOM-215 [3] I'll do it in a personal
> GitHub git repo first while we choose the final name:
> maven-default-plugins?
>
> Regards,
>
> Hervé
>
> [1] https://issues.apache.org/jira/browse/MNG-6562
>
> [2]
> https://github.com/apache/maven/commit/05bc5c15dd37290e51190c6aa3fe4eb4a5bc
> e62c
>
> [3] https://issues.apache.org/jira/browse/MPOM-215
>
> Le dimanche 13 janvier 2019, 11:37:43 CET Robert Scholte a écrit :
> > 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 <[hidden email]>
> >
> > 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 <[hidden email]>
> > >>
> > >> 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
> > >>
> > >> <[hidden email]>
> > >>
> > >> > 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 <[hidden email]>
> > >> > > 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
> > >>
> > >> <[hidden email]
> > >>
> > >> > > 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
> > >> > > >> <[hidden email]>
> > >> > > >>
> > >> > > >> 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 <
> > >> >
> > >> > [hidden email]
> > >> >
> > >> > > >> >> 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: [hidden email]
> > >> > > >> >> > For additional commands, e-mail: [hidden email]
> > >> >
> > >> > ---------------------------------------------------------------------
> > >> >
> > >> > > >> > To unsubscribe, e-mail: [hidden email]
> > >> > > >> > For additional commands, e-mail: [hidden email]
> > >>
> > >> ---------------------------------------------------------------------
> > >>
> > >> > > >> To unsubscribe, e-mail: [hidden email]
> > >> > > >> For additional commands, e-mail: [hidden email]
> > >>
> > >> ---------------------------------------------------------------------
> > >>
> > >> > > > To unsubscribe, e-mail: [hidden email]
> > >> > > > For additional commands, e-mail: [hidden email]
> > >>
> > >> ---------------------------------------------------------------------
> > >>
> > >> > > To unsubscribe, e-mail: [hidden email]
> > >> > > For additional commands, e-mail: [hidden email]
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]