Re: Update versions of all plugins in default-bindings.xml
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 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: > >4.0.0 >com.mycompany.app >my-app >1.0-SNAPSHOT > > > 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 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 >>> >>> 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 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 recen
Re: Update versions of all plugins in default-bindings.xml
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: 4.0.0 com.mycompany.app my-app 1.0-SNAPSHOT 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 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 > > > > 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 > > > 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
Re: Update versions of all plugins in default-bindings.xml
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 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 > 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 > > 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 > > > 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 > > >> > > >> > > >> wrote: > > >> > Le vendredi 11 janvier 2019, 12:55:03 CET Tibor Digana a
Re: Update versions of all plugins in default-bindings.xml
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 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 > 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 > 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 > >> > >> > >> 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
Re: Update versions of all plugins in default-bindings.xml
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 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 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 >> >> >> 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 >> >> >> >> wrote: >> >> > As I wrote in many Jira issues over years on this topic, I'm not in >> >> >> >> favor >>
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 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 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 >> >> 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 >
Re: Update versions of all plugins in default-bindings.xml
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 > > 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 > >> > >> 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.
Re: Update versions of all plugins in default-bindings.xml
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 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 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
Re: Update versions of all plugins in default-bindings.xml
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 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
Re: cannot delete workspace ... invoker-reports/BUILD-***.xml
On Sat, 12 Jan 2019 15:04:34 +0100, Enrico Olivelli wrote: Il sab 12 gen 2019, 14:09 Robert Scholte ha scritto: Using the following line to see all java.exe processes tasklist /FI "IMAGENAME eq java.exe" How do you do this on slave Jenkins machines? I ran it locally. Also ran it via a local Jenkins instance, same results. Robert Enrico current maven-jar-plugin (master) is using maven-shared-utils-3.2.1 After running this, I don't see new/hanging java processes Robert On Sat, 12 Jan 2019 12:59:08 +0100, Tibor Digana wrote: >>> which commit could have broken shared utils ? > > I have picked up three candidate commits: > > 362805fbf6341523edfdf509905812acb42f6a97 > fd082c077c78f8ce83fce2a92f0265e83599a42f > f2246e0653b185297451902ee278e6aec1ff470e > > Those devs who have Windows should run the build of maven-jar-plugin (mvn > verify -P run-its) and list all Java processes after the build. > This process should repeat with maven-shared-utils:3.1.0 and again list > all > Java processes. > Logically there should not be any Java processes alive after the build > has > completed. > > Then we can decide whether we will find the commit and release a new > version of maven-shared-utils or we will downgrade it in all > usages/projects/branches together with testing on Jenkins. > Cheers > T > > > > > On Sat, Jan 12, 2019 at 11:50 AM Enrico Olivelli > wrote: > >> Il giorno sab 12 gen 2019 alle ore 11:45 Enrico Olivelli >> ha scritto: >> > >> > >> > >> > Il sab 12 gen 2019, 11:39 Tibor Digana ha >> scritto: >> >> >> >> Such a drastic change? >> > >> > >> > If that version is buggy we should fix it or drop it. >> > >> > Do we have already released that buggy version to users? >> > >> > >> > How did you see our processes on Jenkins slave? Do you have access to >> slaves console? >> > >> >> b.q. >> which commit could have broken shared utils ? >> https://github.com/apache/maven-shared-utils/commits/master >> >> >> Enrico >> >> >> > Enrico >> > >> > >> >> First we should get the confidence using Jenkins CI for a long time >> run. >> >> >> >> On Sat, Jan 12, 2019 at 11:20 AM Enrico Olivelli >> >> >> wrote: >> >> >> >> > Can't we rollback to the previous version instead of a snapshot? >> >> > >> >> > Enrico >> >> > >> >> > Il sab 12 gen 2019, 09:23 Tibor Digana ha >> >> > scritto: >> >> > >> >> > > I think we should downgrade maven-shared-utils to 3.1.0 in the >> >> > m-invoker-p >> >> > > because we found the same problem in surefire:3.0.0-M1. >> >> > > We did not have time to fix it and I have realized the connection >> to the >> >> > > Invoker just now. >> >> > > Faster than a release is to deploy SNAPSHOT version of the >> Invoker >> and >> >> > use >> >> > > it in JAR plugin and we will see again fully working Jenkins >> build >> >> > > >> >> > >> https://builds.apache.org/job/maven-box/job/maven-jar-plugin/job/MJAR-238/ >> >> > > The precondition is to ask the INFRA to restart all Windows or >> kill >> all >> >> > > Java processes. >> >> > > T >> >> > > >> >> > -- >> >> > >> >> > >> >> > -- Enrico Olivelli >> >> > >> > >> > -- >> > >> > >> > -- Enrico Olivelli >> >> - >> 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 -- -- Enrico Olivelli - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: cannot delete workspace ... invoker-reports/BUILD-***.xml
Il sab 12 gen 2019, 14:09 Robert Scholte ha scritto: > Using the following line to see all java.exe processes > > tasklist /FI "IMAGENAME eq java.exe" > How do you do this on slave Jenkins machines? Enrico > > current maven-jar-plugin (master) is using maven-shared-utils-3.2.1 > After running this, I don't see new/hanging java processes > > Robert > > On Sat, 12 Jan 2019 12:59:08 +0100, Tibor Digana > wrote: > > >>> which commit could have broken shared utils ? > > > > I have picked up three candidate commits: > > > > 362805fbf6341523edfdf509905812acb42f6a97 > > fd082c077c78f8ce83fce2a92f0265e83599a42f > > f2246e0653b185297451902ee278e6aec1ff470e > > > > Those devs who have Windows should run the build of maven-jar-plugin (mvn > > verify -P run-its) and list all Java processes after the build. > > This process should repeat with maven-shared-utils:3.1.0 and again list > > all > > Java processes. > > Logically there should not be any Java processes alive after the build > > has > > completed. > > > > Then we can decide whether we will find the commit and release a new > > version of maven-shared-utils or we will downgrade it in all > > usages/projects/branches together with testing on Jenkins. > > Cheers > > T > > > > > > > > > > On Sat, Jan 12, 2019 at 11:50 AM Enrico Olivelli > > wrote: > > > >> Il giorno sab 12 gen 2019 alle ore 11:45 Enrico Olivelli > >> ha scritto: > >> > > >> > > >> > > >> > Il sab 12 gen 2019, 11:39 Tibor Digana ha > >> scritto: > >> >> > >> >> Such a drastic change? > >> > > >> > > >> > If that version is buggy we should fix it or drop it. > >> > > >> > Do we have already released that buggy version to users? > >> > > >> > > >> > How did you see our processes on Jenkins slave? Do you have access to > >> slaves console? > >> > > >> > >> b.q. > >> which commit could have broken shared utils ? > >> https://github.com/apache/maven-shared-utils/commits/master > >> > >> > >> Enrico > >> > >> > >> > Enrico > >> > > >> > > >> >> First we should get the confidence using Jenkins CI for a long time > >> run. > >> >> > >> >> On Sat, Jan 12, 2019 at 11:20 AM Enrico Olivelli > >> > >> >> wrote: > >> >> > >> >> > Can't we rollback to the previous version instead of a snapshot? > >> >> > > >> >> > Enrico > >> >> > > >> >> > Il sab 12 gen 2019, 09:23 Tibor Digana ha > >> >> > scritto: > >> >> > > >> >> > > I think we should downgrade maven-shared-utils to 3.1.0 in the > >> >> > m-invoker-p > >> >> > > because we found the same problem in surefire:3.0.0-M1. > >> >> > > We did not have time to fix it and I have realized the connection > >> to the > >> >> > > Invoker just now. > >> >> > > Faster than a release is to deploy SNAPSHOT version of the > >> Invoker > >> and > >> >> > use > >> >> > > it in JAR plugin and we will see again fully working Jenkins > >> build > >> >> > > > >> >> > > >> > https://builds.apache.org/job/maven-box/job/maven-jar-plugin/job/MJAR-238/ > >> >> > > The precondition is to ask the INFRA to restart all Windows or > >> kill > >> all > >> >> > > Java processes. > >> >> > > T > >> >> > > > >> >> > -- > >> >> > > >> >> > > >> >> > -- Enrico Olivelli > >> >> > > >> > > >> > -- > >> > > >> > > >> > -- Enrico Olivelli > >> > >> - > >> 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 > > -- -- Enrico Olivelli
Re: cannot delete workspace ... invoker-reports/BUILD-***.xml
Using the following line to see all java.exe processes tasklist /FI "IMAGENAME eq java.exe" current maven-jar-plugin (master) is using maven-shared-utils-3.2.1 After running this, I don't see new/hanging java processes Robert On Sat, 12 Jan 2019 12:59:08 +0100, Tibor Digana wrote: which commit could have broken shared utils ? I have picked up three candidate commits: 362805fbf6341523edfdf509905812acb42f6a97 fd082c077c78f8ce83fce2a92f0265e83599a42f f2246e0653b185297451902ee278e6aec1ff470e Those devs who have Windows should run the build of maven-jar-plugin (mvn verify -P run-its) and list all Java processes after the build. This process should repeat with maven-shared-utils:3.1.0 and again list all Java processes. Logically there should not be any Java processes alive after the build has completed. Then we can decide whether we will find the commit and release a new version of maven-shared-utils or we will downgrade it in all usages/projects/branches together with testing on Jenkins. Cheers T On Sat, Jan 12, 2019 at 11:50 AM Enrico Olivelli wrote: Il giorno sab 12 gen 2019 alle ore 11:45 Enrico Olivelli ha scritto: > > > > Il sab 12 gen 2019, 11:39 Tibor Digana ha scritto: >> >> Such a drastic change? > > > If that version is buggy we should fix it or drop it. > > Do we have already released that buggy version to users? > > > How did you see our processes on Jenkins slave? Do you have access to slaves console? > b.q. which commit could have broken shared utils ? https://github.com/apache/maven-shared-utils/commits/master Enrico > Enrico > > >> First we should get the confidence using Jenkins CI for a long time run. >> >> On Sat, Jan 12, 2019 at 11:20 AM Enrico Olivelli >> wrote: >> >> > Can't we rollback to the previous version instead of a snapshot? >> > >> > Enrico >> > >> > Il sab 12 gen 2019, 09:23 Tibor Digana ha >> > scritto: >> > >> > > I think we should downgrade maven-shared-utils to 3.1.0 in the >> > m-invoker-p >> > > because we found the same problem in surefire:3.0.0-M1. >> > > We did not have time to fix it and I have realized the connection to the >> > > Invoker just now. >> > > Faster than a release is to deploy SNAPSHOT version of the Invoker and >> > use >> > > it in JAR plugin and we will see again fully working Jenkins build >> > > >> > https://builds.apache.org/job/maven-box/job/maven-jar-plugin/job/MJAR-238/ >> > > The precondition is to ask the INFRA to restart all Windows or kill all >> > > Java processes. >> > > T >> > > >> > -- >> > >> > >> > -- Enrico Olivelli >> > > > -- > > > -- Enrico Olivelli - 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
Re: cannot delete workspace ... invoker-reports/BUILD-***.xml
>> which commit could have broken shared utils ? I have picked up three candidate commits: 362805fbf6341523edfdf509905812acb42f6a97 fd082c077c78f8ce83fce2a92f0265e83599a42f f2246e0653b185297451902ee278e6aec1ff470e Those devs who have Windows should run the build of maven-jar-plugin (mvn verify -P run-its) and list all Java processes after the build. This process should repeat with maven-shared-utils:3.1.0 and again list all Java processes. Logically there should not be any Java processes alive after the build has completed. Then we can decide whether we will find the commit and release a new version of maven-shared-utils or we will downgrade it in all usages/projects/branches together with testing on Jenkins. Cheers T On Sat, Jan 12, 2019 at 11:50 AM Enrico Olivelli wrote: > Il giorno sab 12 gen 2019 alle ore 11:45 Enrico Olivelli > ha scritto: > > > > > > > > Il sab 12 gen 2019, 11:39 Tibor Digana ha > scritto: > >> > >> Such a drastic change? > > > > > > If that version is buggy we should fix it or drop it. > > > > Do we have already released that buggy version to users? > > > > > > How did you see our processes on Jenkins slave? Do you have access to > slaves console? > > > > b.q. > which commit could have broken shared utils ? > https://github.com/apache/maven-shared-utils/commits/master > > > Enrico > > > > Enrico > > > > > >> First we should get the confidence using Jenkins CI for a long time run. > >> > >> On Sat, Jan 12, 2019 at 11:20 AM Enrico Olivelli > >> wrote: > >> > >> > Can't we rollback to the previous version instead of a snapshot? > >> > > >> > Enrico > >> > > >> > Il sab 12 gen 2019, 09:23 Tibor Digana ha > >> > scritto: > >> > > >> > > I think we should downgrade maven-shared-utils to 3.1.0 in the > >> > m-invoker-p > >> > > because we found the same problem in surefire:3.0.0-M1. > >> > > We did not have time to fix it and I have realized the connection > to the > >> > > Invoker just now. > >> > > Faster than a release is to deploy SNAPSHOT version of the Invoker > and > >> > use > >> > > it in JAR plugin and we will see again fully working Jenkins build > >> > > > >> > > https://builds.apache.org/job/maven-box/job/maven-jar-plugin/job/MJAR-238/ > >> > > The precondition is to ask the INFRA to restart all Windows or kill > all > >> > > Java processes. > >> > > T > >> > > > >> > -- > >> > > >> > > >> > -- Enrico Olivelli > >> > > > > > -- > > > > > > -- Enrico Olivelli > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Cheers Tibor
Re: cannot delete workspace ... invoker-reports/BUILD-***.xml
I want to do a release of the plugin very soon. Cleaning up the workspace is mostly caused by an invoker-report. I also noticed that some input/outputstreams weren't closed properly, that has been fixed already. If maven-shared-utils 3.2.1 is a likely cause too, then I'll downgrade that one. Stable jobs are much more important to me. thanks, Robert On Sat, 12 Jan 2019 09:23:20 +0100, Tibor Digana wrote: I think we should downgrade maven-shared-utils to 3.1.0 in the m-invoker-p because we found the same problem in surefire:3.0.0-M1. We did not have time to fix it and I have realized the connection to the Invoker just now. Faster than a release is to deploy SNAPSHOT version of the Invoker and use it in JAR plugin and we will see again fully working Jenkins build https://builds.apache.org/job/maven-box/job/maven-jar-plugin/job/MJAR-238/ The precondition is to ask the INFRA to restart all Windows or kill all Java processes. T - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: cannot delete workspace ... invoker-reports/BUILD-***.xml
Il giorno sab 12 gen 2019 alle ore 11:45 Enrico Olivelli ha scritto: > > > > Il sab 12 gen 2019, 11:39 Tibor Digana ha scritto: >> >> Such a drastic change? > > > If that version is buggy we should fix it or drop it. > > Do we have already released that buggy version to users? > > > How did you see our processes on Jenkins slave? Do you have access to slaves > console? > b.q. which commit could have broken shared utils ? https://github.com/apache/maven-shared-utils/commits/master Enrico > Enrico > > >> First we should get the confidence using Jenkins CI for a long time run. >> >> On Sat, Jan 12, 2019 at 11:20 AM Enrico Olivelli >> wrote: >> >> > Can't we rollback to the previous version instead of a snapshot? >> > >> > Enrico >> > >> > Il sab 12 gen 2019, 09:23 Tibor Digana ha >> > scritto: >> > >> > > I think we should downgrade maven-shared-utils to 3.1.0 in the >> > m-invoker-p >> > > because we found the same problem in surefire:3.0.0-M1. >> > > We did not have time to fix it and I have realized the connection to the >> > > Invoker just now. >> > > Faster than a release is to deploy SNAPSHOT version of the Invoker and >> > use >> > > it in JAR plugin and we will see again fully working Jenkins build >> > > >> > https://builds.apache.org/job/maven-box/job/maven-jar-plugin/job/MJAR-238/ >> > > The precondition is to ask the INFRA to restart all Windows or kill all >> > > Java processes. >> > > T >> > > >> > -- >> > >> > >> > -- Enrico Olivelli >> > > > -- > > > -- Enrico Olivelli - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: cannot delete workspace ... invoker-reports/BUILD-***.xml
Il sab 12 gen 2019, 11:39 Tibor Digana ha scritto: > Such a drastic change? > If that version is buggy we should fix it or drop it. Do we have already released that buggy version to users? How did you see our processes on Jenkins slave? Do you have access to slaves console? Enrico First we should get the confidence using Jenkins CI for a long time run. > > On Sat, Jan 12, 2019 at 11:20 AM Enrico Olivelli > wrote: > > > Can't we rollback to the previous version instead of a snapshot? > > > > Enrico > > > > Il sab 12 gen 2019, 09:23 Tibor Digana ha > > scritto: > > > > > I think we should downgrade maven-shared-utils to 3.1.0 in the > > m-invoker-p > > > because we found the same problem in surefire:3.0.0-M1. > > > We did not have time to fix it and I have realized the connection to > the > > > Invoker just now. > > > Faster than a release is to deploy SNAPSHOT version of the Invoker and > > use > > > it in JAR plugin and we will see again fully working Jenkins build > > > > > > https://builds.apache.org/job/maven-box/job/maven-jar-plugin/job/MJAR-238/ > > > The precondition is to ask the INFRA to restart all Windows or kill all > > > Java processes. > > > T > > > > > -- > > > > > > -- Enrico Olivelli > > > -- -- Enrico Olivelli
Re: cannot delete workspace ... invoker-reports/BUILD-***.xml
Such a drastic change? First we should get the confidence using Jenkins CI for a long time run. On Sat, Jan 12, 2019 at 11:20 AM Enrico Olivelli wrote: > Can't we rollback to the previous version instead of a snapshot? > > Enrico > > Il sab 12 gen 2019, 09:23 Tibor Digana ha > scritto: > > > I think we should downgrade maven-shared-utils to 3.1.0 in the > m-invoker-p > > because we found the same problem in surefire:3.0.0-M1. > > We did not have time to fix it and I have realized the connection to the > > Invoker just now. > > Faster than a release is to deploy SNAPSHOT version of the Invoker and > use > > it in JAR plugin and we will see again fully working Jenkins build > > > https://builds.apache.org/job/maven-box/job/maven-jar-plugin/job/MJAR-238/ > > The precondition is to ask the INFRA to restart all Windows or kill all > > Java processes. > > T > > > -- > > > -- Enrico Olivelli >
Re: cannot delete workspace ... invoker-reports/BUILD-***.xml
Can't we rollback to the previous version instead of a snapshot? Enrico Il sab 12 gen 2019, 09:23 Tibor Digana ha scritto: > I think we should downgrade maven-shared-utils to 3.1.0 in the m-invoker-p > because we found the same problem in surefire:3.0.0-M1. > We did not have time to fix it and I have realized the connection to the > Invoker just now. > Faster than a release is to deploy SNAPSHOT version of the Invoker and use > it in JAR plugin and we will see again fully working Jenkins build > https://builds.apache.org/job/maven-box/job/maven-jar-plugin/job/MJAR-238/ > The precondition is to ask the INFRA to restart all Windows or kill all > Java processes. > T > -- -- Enrico Olivelli
cannot delete workspace ... invoker-reports/BUILD-***.xml
I think we should downgrade maven-shared-utils to 3.1.0 in the m-invoker-p because we found the same problem in surefire:3.0.0-M1. We did not have time to fix it and I have realized the connection to the Invoker just now. Faster than a release is to deploy SNAPSHOT version of the Invoker and use it in JAR plugin and we will see again fully working Jenkins build https://builds.apache.org/job/maven-box/job/maven-jar-plugin/job/MJAR-238/ The precondition is to ask the INFRA to restart all Windows or kill all Java processes. T
