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