maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte" <rfscho...@apache.org>
Subject Re: Update versions of all plugins in default-bindings.xml
Date Sun, 13 Jan 2019 20:18:28 GMT
On Sun, 13 Jan 2019 21:03:20 +0100, Hervé BOUTEMY <herve.boutemy@free.fr>  
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  
>> <herve.boutemy@free.fr>
>>
>> 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
>> >> <herve.boutemy@free.fr>
>> >>
>> >> wrote:
>> >> > we have 2 opposite objectives:
>> >> > - make default near-empty pom work at best,
>> >> > - but force people to have defined plugins versions (then not  
>> really
>> >> > empty pom) to get stable build
>> >> >
>> >> > and I checked about the warning message: I was wrong, there is no
>> >> > warning message when plugins without versions are injected by  
>> default
>> >> > lifecycle bindings
>> >> >
>> >> > Just test for yourself following pom.xml from any beginner:
>> >> >   <project>
>> >> >
>> >> >     <modelVersion>4.0.0</modelVersion>
>> >> >     <groupId>com.mycompany.app</groupId>
>> >> >     <artifactId>my-app</artifactId>
>> >> >     <version>1.0-SNAPSHOT</version>
>> >> >
>> >> >   </project>
>> >> >
>> >> > it works = what we expect to ease newcomers experience
>> >> > but there is no warning...
>> >> >
>> >> > IMHO, this is where we need to improve the tool, by adding a  
>> warning:
>> >> > I worked on a PoC of DefaultLifecycleBindingsInjector improvement 

>> that
>> >> > displays:
>> >> > [WARNING]
>> >> > [WARNING] Some problems were encountered while building the  
>> effective
>> >> > model for com.mycompany.app:my-app:jar:1.0-SNAPSHOT
>> >> > [WARNING] Using default plugins versions from bindings:
>> >> > [org.apache.maven.plugins:maven-clean-plugin,
>> >> > org.apache.maven.plugins:maven-install-plugin,
>> >> > org.apache.maven.plugins:maven-resources-plugin,
>> >> > org.apache.maven.plugins:maven-surefire-plugin,
>> >> > org.apache.maven.plugins:maven-compiler-plugin,
>> >> > org.apache.maven.plugins:maven-jar-plugin,
>> >> > org.apache.maven.plugins:maven-deploy-plugin,
>> >> > org.apache.maven.plugins:maven-site-plugin]
>> >> > [WARNING]
>> >> > [WARNING] It is highly recommended to fix these problems because  
>> they
>> >> > threaten the stability of your build.
>> >> > [WARNING]
>> >> > [WARNING] For this reason, future Maven versions might no longer
>> >>
>> >> support
>> >>
>> >> > building such malformed projects.
>> >> > [WARNING]
>> >> >
>> >> > With this warning, and a parent pom to have an easy fix (instead  
>> of 8
>> >> > plugins versions definition), IMHO, we have what we strongly need.
>> >> >
>> >> > And even better, with this warning in place to avoid people to
>> >>
>> >> continue
>> >>
>> >> > to rely on default plugins versions (because of the nasty  
>> warning), I
>> >> > could find upgrading default plugins versions not an issue any  
>> more!!!
>> >> >
>> >> > Should we try to go this route?
>> >> >
>> >> > Regards,
>> >> >
>> >> > Hervé
>> >> >
>> >> > Le dimanche 13 janvier 2019, 00:15:38 CET Stephen Connolly a écrit
 
>> :
>> >> >> The original plan was to make plugin version mandatory. Perhaps
>> >>
>> >> 3.7.0 is
>> >>
>> >> >> the time to do that, with a CLI option (to be removed after  
>> 3.7.x) to
>> >> >> pull
>> >> >> in the 3.6.x default versions if your pom is missing plugin  
>> versions.
>> >> >>
>> >> >> The warning has been there long enough. Let’s pull the trigger.
>> >> >>
>> >> >> On Sat 12 Jan 2019 at 21:34, Tibor Digana <tibordigana@apache.org>
>> >> >>
>> >> >> wrote:
>> >> >> > I have a strong reason to update Surefire due to new JRE 

>> versions
>> >>
>> >> have
>> >>
>> >> >> > been
>> >> >> > updated too many times last two years.
>> >> >> > They required a fix done within a few days and some of them
are
>> >> >>
>> >> >> shaking on
>> >> >>
>> >> >> > the chair...
>> >> >> > Our Maven Core is stable and Java 9+ ready but the obsolete
 
>> plugins
>> >> >>
>> >> >> are
>> >> >>
>> >> >> > not.
>> >> >> > I want only the same compatibility with default plugins because
>> >> >>
>> >> >> people do
>> >> >>
>> >> >> > not see these plugins as a distinct community. They are both
 
>> Maven
>> >>
>> >> and
>> >>
>> >> >> > plugins from us Apache, so they most probably would expect
it
>> >> >>
>> >> >> consistent
>> >> >>
>> >> >> > altogether.
>> >> >> > Makes sense?
>> >> >> >
>> >> >> > On Sat, Jan 12, 2019 at 7:24 PM Bernd Eckenfels
>> >> >>
>> >> >> <ecki@zusammenkunft.net>
>> >> >>
>> >> >> > wrote:
>> >> >> > > I think that’s a real bad idea if you have to do local
>> >> >>
>> >> >> modifications to
>> >> >>
>> >> >> > > get to a working build environment. Maven is all about
not
>> >> >>
>> >> >> requiring you
>> >> >>
>> >> >> > to
>> >> >> >
>> >> >> > > do that (anymore). So even requiring a certain Maven
Version  
>> does
>> >> >>
>> >> >> not
>> >> >>
>> >> >> > > fit
>> >> >> > > in that pattern (although unavoidable if you do not want
to  
>> work
>> >> >>
>> >> >> with
>> >> >>
>> >> >> > > wrappers).
>> >> >> > >
>> >> >> > > So this means: keep old standard versions and overwrite
them
>> >>
>> >> always
>> >>
>> >> >> in
>> >> >>
>> >> >> > > poms. (And it means the amount of default versions should
be
>> >> >>
>> >> >> reduced or
>> >> >>
>> >> >> > at
>> >> >> >
>> >> >> > > least not add new ones)
>> >> >> > >
>> >> >> > > Gruss
>> >> >> > > Bernd
>> >> >> > > --
>> >> >> > > http://bernd.eckenfels.net
>> >> >> > >
>> >> >> > > ________________________________
>> >> >> > > Von: Robert Scholte <rfscholte@apache.org>
>> >> >> > > Gesendet: Samstag, Januar 12, 2019 5:07 PM
>> >> >> > > An: Maven Developers List
>> >> >> > > Betreff: Re: Update versions of all plugins in
>> >>
>> >> default-bindings.xml
>> >>
>> >> >> > > I had chats with both Adam Bien and Sebastian Daschner
asking
>> >>
>> >> for a
>> >>
>> >> >> > better
>> >> >> >
>> >> >> > > way to work with a simple high-speed throw-away development
 
>> pom.
>> >> >> > >
>> >> >> > > They are both working a lot with Java EE applications
and  
>> want to
>> >> >>
>> >> >> rely
>> >> >>
>> >> >> > > on
>> >> >> > > defaults as much as possible.
>> >> >> > > So in a way they don't care about plugin versions.
>> >> >> > > They only case about things in poms that does matter
(unique  
>> to
>> >>
>> >> that
>> >>
>> >> >> > > project): dependencies
>> >> >> > > However, with Java 9+ stuff they are forced to specify
plugins
>> >>
>> >> with
>> >>
>> >> >> more
>> >> >>
>> >> >> > > recent versions right now.
>> >> >> > >
>> >> >> > > So here comes the idea of extensions: you can put it
in your
>> >> >> >
>> >> >> > maven/lib/ext
>> >> >> >
>> >> >> > > ONCE and your pom is again as clean as possible.
>> >> >> > >
>> >> >> > > This seems to be a common way of work for some kind of
 
>> developers
>> >> >>
>> >> >> and it
>> >> >>
>> >> >> > > would make sense if Maven could support this.
>> >> >> > >
>> >> >> > > To me default plugin versions are bound to a minor Maven
 
>> release,
>> >> >>
>> >> >> not a
>> >> >>
>> >> >> > > major.
>> >> >> > > When starting with Maven and create your first hello
world, it
>> >> >>
>> >> >> should
>> >> >>
>> >> >> > work
>> >> >> >
>> >> >> > > out of the box.
>> >> >> > > Right now if you are using Java 11, you'll probably hit
issues
>> >> >>
>> >> >> because
>> >> >>
>> >> >> > > some defaults won't work anymore.
>> >> >> > > That's a bad thing to me and a valid reason to upgrade
the
>> >>
>> >> plugins.
>> >>
>> >> >> > > I do understand Hervé concerns. We should motivate people
to  
>> lock
>> >> >>
>> >> >> their
>> >> >>
>> >> >> > > plugins in their pom.
>> >> >> > > Most of all the packaging-plugin is important. AFAIK
all 3.0+
>> >> >>
>> >> >> versions
>> >> >>
>> >> >> > > contain plugin bindings, in which case it should be good
 
>> enough
>> >>
>> >> if
>> >>
>> >> >> that
>> >> >>
>> >> >> > > plugin is at least specified.
>> >> >> > >
>> >> >> > > thanks,
>> >> >> > > Robert
>> >> >> > >
>> >> >> > > On Sat, 12 Jan 2019 16:24:31 +0100, Hervé BOUTEMY
>> >> >>
>> >> >> <herve.boutemy@free.fr
>> >> >>
>> >> >> > > wrote:
>> >> >> > > > original idea, let's try to evaluate :)
>> >> >> > > >
>> >> >> > > > IMHO this could work for packaging plugins in default
>> >>
>> >> lifecycle,
>> >>
>> >> >> that
>> >> >>
>> >> >> > are
>> >> >> >
>> >> >> > > > defined in default-bindings.xml, but would not for
other
>> >> >>
>> >> >> lifecycles
>> >> >>
>> >> >> > that
>> >> >> >
>> >> >> > > > are
>> >> >> > > > configured in components.xml (without copy/pasting
content  
>> not
>> >> >>
>> >> >> related
>> >> >>
>> >> >> > to
>> >> >> >
>> >> >> > > > plugins)
>> >> >> > > >
>> >> >> > > > I don't think an extension would be easier to use
than a
>> >>
>> >> pom.xml,
>> >>
>> >> >> it's
>> >> >>
>> >> >> > > > even
>> >> >> > > > IMHO worse since you have to create a new file in
a new
>> >>
>> >> directory.
>> >>
>> >> >> > > > one question is: is there a use case that an extension
would
>> >> >>
>> >> >> permit
>> >> >>
>> >> >> > that
>> >> >> >
>> >> >> > > > a
>> >> >> > > > parent pom would not?
>> >> >> > > > the only case I see is if a user does not want to
change his
>> >> >>
>> >> >> parent
>> >> >>
>> >> >> > > > pom
>> >> >> > > > (or
>> >> >> > > > cannot): since we don't have "pluginManagement import"
 
>> (like we
>> >> >>
>> >> >> have
>> >> >>
>> >> >> > for
>> >> >> >
>> >> >> > > > dependency management).
>> >> >> > > >
>> >> >> > > >
>> >> >> > > > I think for the moment that a parent pom would be
more
>> >>
>> >> classical,
>> >>
>> >> >> > easier
>> >> >> >
>> >> >> > > > to
>> >> >> > > > explain: I don't really see a clear benefit to do
the job  
>> as an
>> >> >> >
>> >> >> > extension
>> >> >> >
>> >> >> > > > instead, this would IMHO make the change harder
for users
>> >> >> > > >
>> >> >> > > > Regards,
>> >> >> > > >
>> >> >> > > > Hervé
>> >> >> > > >
>> >> >> > > > Le samedi 12 janvier 2019, 15:42:57 CET Robert Scholte
a  
>> écrit
>> >> >> > > >
>> >> >> > > >> Just wondering, can this be solved by an extension?
>> >> >> > > >>
>> >> >> > > >> So instead of changing this in Maven Core itself,
people  
>> can
>> >>
>> >> add
>> >>
>> >> >> an
>> >> >>
>> >> >> > > >> extension to Maven with the latest+stable releases.
>> >> >> > > >>
>> >> >> > > >> Hervé and I already discovered that current
focus is  
>> mainly on
>> >> >> > > >> plugins
>> >> >> > > >> right now. We should also work on extensions.
>> >> >> > > >>
>> >> >> > > >> Robert
>> >> >> > > >>
>> >> >> > > >> On Sat, 12 Jan 2019 15:37:23 +0100, Hervé BOUTEMY
>> >> >> > > >> <herve.boutemy@free.fr>
>> >> >> > > >>
>> >> >> > > >> wrote:
>> >> >> > > >> > Le vendredi 11 janvier 2019, 12:55:03 CET
Tibor Digana a
>> >>
>> >> écrit
>> >>
>> >> >> > > >> >> ok, Herve, the fact is that these plugins
have been  
>> updated
>> >> >>
>> >> >> from
>> >> >>
>> >> >> > > >> time to
>> >> >> > > >>
>> >> >> > > >> >> time.
>> >> >> > > >> >
>> >> >> > > >> > yes, we did it in the past (years ago,
look at the  
>> history)
>> >>
>> >> and
>> >>
>> >> >> > > >> > went
>> >> >> > > >>
>> >> >> > > >> to
>> >> >> > > >>
>> >> >> > > >> > the
>> >> >> > > >> > conclusion we should not do that to improve
 
>> reproducibility,
>> >> >>
>> >> >> unless
>> >> >>
>> >> >> > > >> > there is a
>> >> >> > > >> > strong reason to do it sometimes on some
specific plugins
>> >> >> > > >> > = what I'm trying to explain, for the moment
without much
>> >> >>
>> >> >> success
>> >> >>
>> >> >> > > >> > What we could do would be to create a new
POM to use as
>> >>
>> >> parent
>> >>
>> >> >> POM,
>> >> >>
>> >> >> > > >> that
>> >> >> > > >>
>> >> >> > > >> > would
>> >> >> > > >> >
>> >> >> > > >> > define the versions of every plugin from
the default
>> >> >>
>> >> >> lifecycles:
>> >> >> > this
>> >> >> >
>> >> >> > > >> > would
>> >> >> > > >> > avoid to have everybody to write the full
list of plugins
>> >> >>
>> >> >> (which is
>> >> >>
>> >> >> > a
>> >> >> >
>> >> >> > > >> > pain: I
>> >> >> > > >> > know because in MARCHETYPES-54 [1] I added
the list in  
>> Maven
>> >> >> > > >> > Archetypes...)
>> >> >> > > >> > We could name it "maven-default-plugins",
or if somebody
>> >>
>> >> has a
>> >>
>> >> >> > better
>> >> >> >
>> >> >> > > >> > idea.
>> >> >> > > >> > This way, changing plugins versions would
not be tied to
>> >> >>
>> >> >> changing
>> >> >>
>> >> >> > > >> Maven
>> >> >> > > >>
>> >> >> > > >> > version
>> >> >> > > >> >
>> >> >> > > >> > WDYT?
>> >> >> > > >> >
>> >> >> > > >> > Regards,
>> >> >> > > >> >
>> >> >> > > >> > Hervé
>> >> >> > > >> >
>> >> >> > > >> > [1] https://issues.apache.org/jira/browse/MARCHETYPES-54
>> >> >> > > >> >
>> >> >> > > >> >> How can we be on safe side with these
updates? What is
>> >> >>
>> >> >> mandatory
>> >> >>
>> >> >> > > >> >> to
>> >> >> > > >>
>> >> >> > > >> do
>> >> >> > > >>
>> >> >> > > >> >> for
>> >> >> > > >> >> such upgrade?
>> >> >> > > >> >>
>> >> >> > > >> >> On Fri, Jan 11, 2019 at 7:41 AM Hervé
BOUTEMY <
>> >> >> >
>> >> >> > herve.boutemy@free.fr
>> >> >> >
>> >> >> > > >> >> wrote:
>> >> >> > > >> >> > As I wrote in many Jira issues
over years on this  
>> topic,
>> >> >>
>> >> >> I'm not
>> >> >>
>> >> >> > in
>> >> >> >
>> >> >> > > >> >> favor
>> >> >> > > >> >>
>> >> >> > > >> >> > of
>> >> >> > > >> >> > that
>> >> >> > > >> >> >
>> >> >> > > >> >> > To me, staying with the same default
plugins versions
>> >>
>> >> from
>> >>
>> >> >> Maven
>> >> >>
>> >> >> > > >> >> version
>> >> >> > > >> >>
>> >> >> > > >> >> > to
>> >> >> > > >> >> > Maven version is a feature: nobody
should expect to
>> >>
>> >> change
>> >>
>> >> >> his
>> >> >>
>> >> >> > > >> Maven
>> >> >> > > >>
>> >> >> > > >> >> > version
>> >> >> > > >> >> > to change the plugins versions
>> >> >> > > >> >> > The best practice is to define
plugins versions in  
>> your
>> >> >>
>> >> >> pom.xml
>> >> >>
>> >> >> > (or
>> >> >> >
>> >> >> > > >> >> > parent).
>> >> >> > > >> >> > Getting very old versions of plugins
by default is the
>> >>
>> >> best
>> >>
>> >> >> > > >> additional
>> >> >> > > >>
>> >> >> > > >> >> > feature
>> >> >> > > >> >> > we have after the WARN "plugin
version not defined"
>> >> >> > > >> >> >
>> >> >> > > >> >> > Then IMHO, upgrading default plugins
versions is a bad
>> >> >>
>> >> >> idea, is
>> >> >>
>> >> >> > > >> >> > a
>> >> >> > > >>
>> >> >> > > >> bad
>> >> >> > > >>
>> >> >> > > >> >> > message
>> >> >> > > >> >> > = "you can continue to ignore
the WARN on plugins
>> >>
>> >> versions
>> >>
>> >> >> and
>> >> >>
>> >> >> > > >> still
>> >> >> > > >>
>> >> >> > > >> >> get
>> >> >> > > >> >>
>> >> >> > > >> >> > newest and latest plugins"
>> >> >> > > >> >> >
>> >> >> > > >> >> > this leads IMHO to one (bad) reason
for people to  
>> require
>> >> >>
>> >> >> Maven
>> >> >>
>> >> >> > > >> >> Wrapper
>> >> >> > > >> >>
>> >> >> > > >> >> > I know, this is counter intuitive,
that's why it is
>> >> >>
>> >> >> required to
>> >> >>
>> >> >> > > >> really
>> >> >> > > >>
>> >> >> > > >> >> > take a
>> >> >> > > >> >> > moment to think about it
>> >> >> > > >> >> >
>> >> >> > > >> >> > Regards,
>> >> >> > > >> >> >
>> >> >> > > >> >> > Hervé
>> >> >> > > >> >> >
>> >> >> > > >> >> > Le jeudi 10 janvier 2019, 17:08:57
CET Tibor Digana a
>> >>
>> >> écrit
>> >>
>> >> >> > > >> >> > > Why we use old versions in
default-bindings.xml?
>> >> >> > > >> >> > > Can we update all versions
in 3.6.1 release?
>> >> >> > > >> >> > >
>> >> >> > > >> >> > > Here is MNG-6557 which is
related to Surefire but I
>> >>
>> >> guess
>> >>
>> >> >> this
>> >> >>
>> >> >> > > >> Jira
>> >> >> > > >>
>> >> >> > > >> >> > > issue
>> >> >> > > >> >> > > can be freely related to
all plugins.
>> >> >> > > >> >> > >
>> >> >> > > >> >> > > WDYT?
>> >> >> > > >> >> > > Any objections to update
all plugins and assign this
>> >> >>
>> >> >> issue in
>> >> >>
>> >> >> > > >> 3.6.1?
>> >> >> > > >>
>> >> >> > > >> >> > > Cheers
>> >> >> > > >> >> > > Tibor
>> >> >>
>> >> >>  
>> ---------------------------------------------------------------------
>> >> >>
>> >> >> > > >> >> > To unsubscribe, e-mail:  
>> dev-unsubscribe@maven.apache.org
>> >>
>> >> >> > > >> >> > For additional commands, e-mail:
>> >> dev-help@maven.apache.org
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >>
>> >> >> > > >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> >> > > >> > For additional commands, e-mail:  
>> dev-help@maven.apache.org
>> >> >>
>> >> >>  
>> ---------------------------------------------------------------------
>> >> >>
>> >> >> > > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> >> > > >> For additional commands, e-mail: dev-help@maven.apache.org
>> >> >>
>> >> >>  
>> ---------------------------------------------------------------------
>> >> >>
>> >> >> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> >> > > > For additional commands, e-mail: dev-help@maven.apache.org
>> >> >>
>> >> >>  
>> ---------------------------------------------------------------------
>> >> >>
>> >> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> >> > > For additional commands, e-mail: dev-help@maven.apache.org
>> >> >
>> >> >  
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> > For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message