Re: Introducing Maven Wrapper
Hello John. Le mer. 19 août 2020 à 23:38, John Patrick a écrit : > > I've now closed all PR's, and deleted the source branches. > > Giles I've pushed the changes back into my commons-lang fork, so this > would recreate that branch > https://github.com/nhojpatrick/apache_commons-lang/pull/new/takari.maven-wrapper. > > The PR if raised again, would include changes needed for github > workflow, travis and Jenkinsfile, also documentation updates. > > You don't need to use mvnw if you are an advanced user with a specific > use case and know what you're doing. But for 90% of use cases just > saying use mvnw will be fine, advising mvnw won't stop you using mvn > to perform builds. > > Everytime I install a new Java 15 or 16 EA version, and update my > toolchains.xml, I normally delete both ~/.m2/wrapper and > ~/.m2/repository at the same time so regularly spring clean. So I'll > only have an old version of maven if I've needed to build an older > branch which was designed to be used on an older maven. Most modern > new CI's are creating slaves on demand per execution, so it won't > slowly build up older maven wrapper versions like the old style > jenkins slave. Thanks for the explanations. The [Math] component could be used as guinea pig. Best regards, Gilles > > John > > On Wed, 19 Aug 2020 at 22:23, Gilles Sadowski wrote: > > > > Le mer. 19 août 2020 à 22:49, Gary Gregory a écrit > > : > > > > > > The consensus is do nothing IMO. > > > > "Those who do the work" etc. (see below). > > > > > > > > What I really dislike is that if I have 20 components that over time end > > > up > > > containing 20 different versions of these > > > Cmd/Sh/JavaSource/PropertiesFiles > > > that point to 20 different versions of Maven, and I build everything, I'll > > > end up with 20 different versions of Maven downloaded on my machine that I > > > did not ask. > > > > That seems like "business as usual" for maven-based development... > > But I'd tend to agree that it must at least be optional. > > Is someone willing to demonstrate that it is so, i.e. make the > > needed changes (for a single component)? > > > > Regards, > > Gilles > > > > >>> [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Introducing Maven Wrapper
I've now closed all PR's, and deleted the source branches. Giles I've pushed the changes back into my commons-lang fork, so this would recreate that branch https://github.com/nhojpatrick/apache_commons-lang/pull/new/takari.maven-wrapper. The PR if raised again, would include changes needed for github workflow, travis and Jenkinsfile, also documentation updates. You don't need to use mvnw if you are an advanced user with a specific use case and know what you're doing. But for 90% of use cases just saying use mvnw will be fine, advising mvnw won't stop you using mvn to perform builds. Everytime I install a new Java 15 or 16 EA version, and update my toolchains.xml, I normally delete both ~/.m2/wrapper and ~/.m2/repository at the same time so regularly spring clean. So I'll only have an old version of maven if I've needed to build an older branch which was designed to be used on an older maven. Most modern new CI's are creating slaves on demand per execution, so it won't slowly build up older maven wrapper versions like the old style jenkins slave. John On Wed, 19 Aug 2020 at 22:23, Gilles Sadowski wrote: > > Le mer. 19 août 2020 à 22:49, Gary Gregory a écrit : > > > > The consensus is do nothing IMO. > > "Those who do the work" etc. (see below). > > > > > What I really dislike is that if I have 20 components that over time end up > > containing 20 different versions of these Cmd/Sh/JavaSource/PropertiesFiles > > that point to 20 different versions of Maven, and I build everything, I'll > > end up with 20 different versions of Maven downloaded on my machine that I > > did not ask. > > That seems like "business as usual" for maven-based development... > But I'd tend to agree that it must at least be optional. > Is someone willing to demonstrate that it is so, i.e. make the > needed changes (for a single component)? > > Regards, > Gilles > > >>> [...] > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Introducing Maven Wrapper
Le mer. 19 août 2020 à 22:49, Gary Gregory a écrit : > > The consensus is do nothing IMO. "Those who do the work" etc. (see below). > > What I really dislike is that if I have 20 components that over time end up > containing 20 different versions of these Cmd/Sh/JavaSource/PropertiesFiles > that point to 20 different versions of Maven, and I build everything, I'll > end up with 20 different versions of Maven downloaded on my machine that I > did not ask. That seems like "business as usual" for maven-based development... But I'd tend to agree that it must at least be optional. Is someone willing to demonstrate that it is so, i.e. make the needed changes (for a single component)? Regards, Gilles >>> [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Introducing Maven Wrapper
The consensus is do nothing IMO. What I really dislike is that if I have 20 components that over time end up containing 20 different versions of these Cmd/Sh/JavaSource/PropertiesFiles that point to 20 different versions of Maven, and I build everything, I'll end up with 20 different versions of Maven downloaded on my machine that I did not ask. Gary On Wed, Aug 19, 2020 at 4:39 PM Xeno Amess wrote: > me +0 for mvnw. > I don't hate it and it is well implemented. > But I have no idea whether we need it. > > Rob Tompkins 于2020年8月20日周四 上午4:36写道： > > > I’m still a +1 for mvnw….do we have a consensus here? > > > > -Rob > > > > > On Aug 19, 2020, at 4:27 PM, John Patrick > > wrote: > > > > > > All the suggestions I'm seeing appear to be hard code solutions to > > > specific implementations, require defining things in multiple places, > > > or needing developers to select the correct version. > > > > > > https://github.com/marketplace/actions/setup-maven won't work on my > > laptop > > > https://github.com/marketplace/actions/setup-maven won't work on > travis > > > https://github.com/marketplace/actions/setup-maven won't work on > jenkins > > > https://github.com/marketplace/actions/setup-maven will work for > github > > actions > > > > > > mvnw will work on my laptop > > > mvnw will work on your laptop > > > mvnw will work on the machine of a new contributor that has never > > > installed maven before > > > mvnw will work on travis > > > mvnw will work on jenkins > > > mvnw will work on github > > > mvnw puts control into each commons-* project as to what maven version > > > is needed and specific for each branch > > > > > > Anyway, I'll be closing my PR's. > > > > > > I'll take the hint and stop trying to contribute and help out. > > > > > > I tried helping with early testing of java 9 early access releases, > > > and the response I received was basically "it's not out yet we don't > > > care". > > > I tried attempting getting multi release jars working so newer feature > > > for Java 11 LTS can be started to added, and got similar feedback, " > > > well we are still using java 1.6, 1.7 or 1.8, we don't care if people > > > want to use java 11 or newer, they will have to wait" > > > I tried help adding junit 5 jupiter to clean up so we can use > > > assertAll or assertThrows, some project accepted but I think others > > > are still outstanding. > > > > > > John > > > > > > On Wed, 19 Aug 2020 at 13:48, Romain Manni-Bucau < > rmannibu...@gmail.com> > > wrote: > > >> > > >> Le mer. 19 août 2020 à 14:33, Gary Gregory a > > >> écrit : > > >> > > >>> On Wed, Aug 19, 2020 at 7:49 AM Gary Gregory > > > >>> wrote: > > >>> > > -1 from me, use a set up action instead, for example: > > > > https://github.com/marketplace?type=actions=maven > > > > In particular: > > > > https://github.com/marketplace/actions/setup-maven > > > > As recommended here: > > > > https://github.com/actions/setup-java/issues/40#issuecomment-675817329 > > > > Gary > > > > >>> > > >>> Looking at https://github.com/marketplace/actions/setup-maven > > >>> > > >>> I am wondering why this is not done as a "simple" wget and tar call > > instead > > >>> of some big old node project. > > >>> > > >> > > >> Not sure what you have in mind with the "big old" (guess it was a > "plain > > >> old" ?) but think the rationale is generally to use the GH Action SDK > > which > > >> is mainly js/ts. > > >> You can indeed replace it by whatever sh you want but you will have to > > >> reimplement the caching, assume about the running VM and reimplement a > > >> config strategy + maintain it if gh action strategy about it changes - > > or > > >> do something fully custom which is IMHO a bad idea. > > >> Nothing not doable but it is surely saner for a widely used OS project > > to > > >> stick to "standard" for things outside the scope of the project > itself. > > >> That said a java GH Action SDK can be nice - but would likely still > call > > >> node as of today :s. > > >> > > >> > > >>> I am leaning toward having our own Apache Commons setup action. Any > > >>> thoughts or volunteers? > > >>> > > >>> Gary > > >>> > > >>> PS: For Windows node, we could use Powershell if available to use > wget. > > >>> > > >>> > > > > On Sat, Aug 15, 2020, 09:46 John Patrick > > wrote: > > > > > I've raised some pull requests to add the Takari maven wrapper. > > > > > > The Takari maven wrapper is EOL and will be replaced with the Maven > > > Wrapper when Maven v3.7.0 is released. > > > > > > I've added the Takari version as maven v3.7.0 is not yet out. I've > > > been using the Takari maven wrapper for about 4 years now and it > has > > > reduced a lot of maintenance and setup tasks. > > > > > > - Maven Wrapper is Maven-As-Code > > > - CI/CD, your docker images or Jenkins slaves no longer need maven > > pre > > > installed, so less maintenance
Re: Introducing Maven Wrapper
me +0 for mvnw. I don't hate it and it is well implemented. But I have no idea whether we need it. Rob Tompkins 于2020年8月20日周四 上午4:36写道： > I’m still a +1 for mvnw….do we have a consensus here? > > -Rob > > > On Aug 19, 2020, at 4:27 PM, John Patrick > wrote: > > > > All the suggestions I'm seeing appear to be hard code solutions to > > specific implementations, require defining things in multiple places, > > or needing developers to select the correct version. > > > > https://github.com/marketplace/actions/setup-maven won't work on my > laptop > > https://github.com/marketplace/actions/setup-maven won't work on travis > > https://github.com/marketplace/actions/setup-maven won't work on jenkins > > https://github.com/marketplace/actions/setup-maven will work for github > actions > > > > mvnw will work on my laptop > > mvnw will work on your laptop > > mvnw will work on the machine of a new contributor that has never > > installed maven before > > mvnw will work on travis > > mvnw will work on jenkins > > mvnw will work on github > > mvnw puts control into each commons-* project as to what maven version > > is needed and specific for each branch > > > > Anyway, I'll be closing my PR's. > > > > I'll take the hint and stop trying to contribute and help out. > > > > I tried helping with early testing of java 9 early access releases, > > and the response I received was basically "it's not out yet we don't > > care". > > I tried attempting getting multi release jars working so newer feature > > for Java 11 LTS can be started to added, and got similar feedback, " > > well we are still using java 1.6, 1.7 or 1.8, we don't care if people > > want to use java 11 or newer, they will have to wait" > > I tried help adding junit 5 jupiter to clean up so we can use > > assertAll or assertThrows, some project accepted but I think others > > are still outstanding. > > > > John > > > > On Wed, 19 Aug 2020 at 13:48, Romain Manni-Bucau > wrote: > >> > >> Le mer. 19 août 2020 à 14:33, Gary Gregory a > >> écrit : > >> > >>> On Wed, Aug 19, 2020 at 7:49 AM Gary Gregory > >>> wrote: > >>> > -1 from me, use a set up action instead, for example: > > https://github.com/marketplace?type=actions=maven > > In particular: > > https://github.com/marketplace/actions/setup-maven > > As recommended here: > > https://github.com/actions/setup-java/issues/40#issuecomment-675817329 > > Gary > > >>> > >>> Looking at https://github.com/marketplace/actions/setup-maven > >>> > >>> I am wondering why this is not done as a "simple" wget and tar call > instead > >>> of some big old node project. > >>> > >> > >> Not sure what you have in mind with the "big old" (guess it was a "plain > >> old" ?) but think the rationale is generally to use the GH Action SDK > which > >> is mainly js/ts. > >> You can indeed replace it by whatever sh you want but you will have to > >> reimplement the caching, assume about the running VM and reimplement a > >> config strategy + maintain it if gh action strategy about it changes - > or > >> do something fully custom which is IMHO a bad idea. > >> Nothing not doable but it is surely saner for a widely used OS project > to > >> stick to "standard" for things outside the scope of the project itself. > >> That said a java GH Action SDK can be nice - but would likely still call > >> node as of today :s. > >> > >> > >>> I am leaning toward having our own Apache Commons setup action. Any > >>> thoughts or volunteers? > >>> > >>> Gary > >>> > >>> PS: For Windows node, we could use Powershell if available to use wget. > >>> > >>> > > On Sat, Aug 15, 2020, 09:46 John Patrick > wrote: > > > I've raised some pull requests to add the Takari maven wrapper. > > > > The Takari maven wrapper is EOL and will be replaced with the Maven > > Wrapper when Maven v3.7.0 is released. > > > > I've added the Takari version as maven v3.7.0 is not yet out. I've > > been using the Takari maven wrapper for about 4 years now and it has > > reduced a lot of maintenance and setup tasks. > > > > - Maven Wrapper is Maven-As-Code > > - CI/CD, your docker images or Jenkins slaves no longer need maven > pre > > installed, so less maintenance tasks > > - Developers don't need to pre install maven > > - Projects control what version of maven to use, maybe a legacy > > project needs v3.3.1 and a newer project needs v3.6.3. A developer > > doesn't need to keep changing their PATH, they just use ./mvnw. > > - Want to check a new version of maven, just change the properties, > > then it can undergo the standard pull request build checks to make > > sure the project works with that version. > > > > The first PR I raised was for commons-code and can be found here > > https://github.com/apache/commons-codec/pull/58 > > > > I've also done similar or; > > commons-collections > >
Re: Introducing Maven Wrapper
I’m still a +1 for mvnw….do we have a consensus here? -Rob > On Aug 19, 2020, at 4:27 PM, John Patrick wrote: > > All the suggestions I'm seeing appear to be hard code solutions to > specific implementations, require defining things in multiple places, > or needing developers to select the correct version. > > https://github.com/marketplace/actions/setup-maven won't work on my laptop > https://github.com/marketplace/actions/setup-maven won't work on travis > https://github.com/marketplace/actions/setup-maven won't work on jenkins > https://github.com/marketplace/actions/setup-maven will work for github > actions > > mvnw will work on my laptop > mvnw will work on your laptop > mvnw will work on the machine of a new contributor that has never > installed maven before > mvnw will work on travis > mvnw will work on jenkins > mvnw will work on github > mvnw puts control into each commons-* project as to what maven version > is needed and specific for each branch > > Anyway, I'll be closing my PR's. > > I'll take the hint and stop trying to contribute and help out. > > I tried helping with early testing of java 9 early access releases, > and the response I received was basically "it's not out yet we don't > care". > I tried attempting getting multi release jars working so newer feature > for Java 11 LTS can be started to added, and got similar feedback, " > well we are still using java 1.6, 1.7 or 1.8, we don't care if people > want to use java 11 or newer, they will have to wait" > I tried help adding junit 5 jupiter to clean up so we can use > assertAll or assertThrows, some project accepted but I think others > are still outstanding. > > John > > On Wed, 19 Aug 2020 at 13:48, Romain Manni-Bucau > wrote: >> >> Le mer. 19 août 2020 à 14:33, Gary Gregory a >> écrit : >> >>> On Wed, Aug 19, 2020 at 7:49 AM Gary Gregory >>> wrote: >>> -1 from me, use a set up action instead, for example: https://github.com/marketplace?type=actions=maven In particular: https://github.com/marketplace/actions/setup-maven As recommended here: https://github.com/actions/setup-java/issues/40#issuecomment-675817329 Gary >>> >>> Looking at https://github.com/marketplace/actions/setup-maven >>> >>> I am wondering why this is not done as a "simple" wget and tar call instead >>> of some big old node project. >>> >> >> Not sure what you have in mind with the "big old" (guess it was a "plain >> old" ?) but think the rationale is generally to use the GH Action SDK which >> is mainly js/ts. >> You can indeed replace it by whatever sh you want but you will have to >> reimplement the caching, assume about the running VM and reimplement a >> config strategy + maintain it if gh action strategy about it changes - or >> do something fully custom which is IMHO a bad idea. >> Nothing not doable but it is surely saner for a widely used OS project to >> stick to "standard" for things outside the scope of the project itself. >> That said a java GH Action SDK can be nice - but would likely still call >> node as of today :s. >> >> >>> I am leaning toward having our own Apache Commons setup action. Any >>> thoughts or volunteers? >>> >>> Gary >>> >>> PS: For Windows node, we could use Powershell if available to use wget. >>> >>> On Sat, Aug 15, 2020, 09:46 John Patrick wrote: > I've raised some pull requests to add the Takari maven wrapper. > > The Takari maven wrapper is EOL and will be replaced with the Maven > Wrapper when Maven v3.7.0 is released. > > I've added the Takari version as maven v3.7.0 is not yet out. I've > been using the Takari maven wrapper for about 4 years now and it has > reduced a lot of maintenance and setup tasks. > > - Maven Wrapper is Maven-As-Code > - CI/CD, your docker images or Jenkins slaves no longer need maven pre > installed, so less maintenance tasks > - Developers don't need to pre install maven > - Projects control what version of maven to use, maybe a legacy > project needs v3.3.1 and a newer project needs v3.6.3. A developer > doesn't need to keep changing their PATH, they just use ./mvnw. > - Want to check a new version of maven, just change the properties, > then it can undergo the standard pull request build checks to make > sure the project works with that version. > > The first PR I raised was for commons-code and can be found here > https://github.com/apache/commons-codec/pull/58 > > I've also done similar or; > commons-collections > commons-configuration > commons-io > commons-lang > commons-parent > httpcomponent-client > httpcomponent-core > httpcomponent-parent > > John > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail:
Re: Introducing Maven Wrapper
All the suggestions I'm seeing appear to be hard code solutions to specific implementations, require defining things in multiple places, or needing developers to select the correct version. https://github.com/marketplace/actions/setup-maven won't work on my laptop https://github.com/marketplace/actions/setup-maven won't work on travis https://github.com/marketplace/actions/setup-maven won't work on jenkins https://github.com/marketplace/actions/setup-maven will work for github actions mvnw will work on my laptop mvnw will work on your laptop mvnw will work on the machine of a new contributor that has never installed maven before mvnw will work on travis mvnw will work on jenkins mvnw will work on github mvnw puts control into each commons-* project as to what maven version is needed and specific for each branch Anyway, I'll be closing my PR's. I'll take the hint and stop trying to contribute and help out. I tried helping with early testing of java 9 early access releases, and the response I received was basically "it's not out yet we don't care". I tried attempting getting multi release jars working so newer feature for Java 11 LTS can be started to added, and got similar feedback, " well we are still using java 1.6, 1.7 or 1.8, we don't care if people want to use java 11 or newer, they will have to wait" I tried help adding junit 5 jupiter to clean up so we can use assertAll or assertThrows, some project accepted but I think others are still outstanding. John On Wed, 19 Aug 2020 at 13:48, Romain Manni-Bucau wrote: > > Le mer. 19 août 2020 à 14:33, Gary Gregory a > écrit : > > > On Wed, Aug 19, 2020 at 7:49 AM Gary Gregory > > wrote: > > > > > -1 from me, use a set up action instead, for example: > > > > > > https://github.com/marketplace?type=actions=maven > > > > > > In particular: > > > > > > https://github.com/marketplace/actions/setup-maven > > > > > > As recommended here: > > > https://github.com/actions/setup-java/issues/40#issuecomment-675817329 > > > > > > Gary > > > > > > > Looking at https://github.com/marketplace/actions/setup-maven > > > > I am wondering why this is not done as a "simple" wget and tar call instead > > of some big old node project. > > > > Not sure what you have in mind with the "big old" (guess it was a "plain > old" ?) but think the rationale is generally to use the GH Action SDK which > is mainly js/ts. > You can indeed replace it by whatever sh you want but you will have to > reimplement the caching, assume about the running VM and reimplement a > config strategy + maintain it if gh action strategy about it changes - or > do something fully custom which is IMHO a bad idea. > Nothing not doable but it is surely saner for a widely used OS project to > stick to "standard" for things outside the scope of the project itself. > That said a java GH Action SDK can be nice - but would likely still call > node as of today :s. > > > > I am leaning toward having our own Apache Commons setup action. Any > > thoughts or volunteers? > > > > Gary > > > > PS: For Windows node, we could use Powershell if available to use wget. > > > > > > > > > > On Sat, Aug 15, 2020, 09:46 John Patrick wrote: > > > > > >> I've raised some pull requests to add the Takari maven wrapper. > > >> > > >> The Takari maven wrapper is EOL and will be replaced with the Maven > > >> Wrapper when Maven v3.7.0 is released. > > >> > > >> I've added the Takari version as maven v3.7.0 is not yet out. I've > > >> been using the Takari maven wrapper for about 4 years now and it has > > >> reduced a lot of maintenance and setup tasks. > > >> > > >> - Maven Wrapper is Maven-As-Code > > >> - CI/CD, your docker images or Jenkins slaves no longer need maven pre > > >> installed, so less maintenance tasks > > >> - Developers don't need to pre install maven > > >> - Projects control what version of maven to use, maybe a legacy > > >> project needs v3.3.1 and a newer project needs v3.6.3. A developer > > >> doesn't need to keep changing their PATH, they just use ./mvnw. > > >> - Want to check a new version of maven, just change the properties, > > >> then it can undergo the standard pull request build checks to make > > >> sure the project works with that version. > > >> > > >> The first PR I raised was for commons-code and can be found here > > >> https://github.com/apache/commons-codec/pull/58 > > >> > > >> I've also done similar or; > > >> commons-collections > > >> commons-configuration > > >> commons-io > > >> commons-lang > > >> commons-parent > > >> httpcomponent-client > > >> httpcomponent-core > > >> httpcomponent-parent > > >> > > >> John > > >> > > >> - > > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >> For additional commands, e-mail: dev-h...@commons.apache.org > > >> > > >> > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For
Re: Introducing Maven Wrapper
Le mer. 19 août 2020 à 14:33, Gary Gregory a écrit : > On Wed, Aug 19, 2020 at 7:49 AM Gary Gregory > wrote: > > > -1 from me, use a set up action instead, for example: > > > > https://github.com/marketplace?type=actions=maven > > > > In particular: > > > > https://github.com/marketplace/actions/setup-maven > > > > As recommended here: > > https://github.com/actions/setup-java/issues/40#issuecomment-675817329 > > > > Gary > > > > Looking at https://github.com/marketplace/actions/setup-maven > > I am wondering why this is not done as a "simple" wget and tar call instead > of some big old node project. > Not sure what you have in mind with the "big old" (guess it was a "plain old" ?) but think the rationale is generally to use the GH Action SDK which is mainly js/ts. You can indeed replace it by whatever sh you want but you will have to reimplement the caching, assume about the running VM and reimplement a config strategy + maintain it if gh action strategy about it changes - or do something fully custom which is IMHO a bad idea. Nothing not doable but it is surely saner for a widely used OS project to stick to "standard" for things outside the scope of the project itself. That said a java GH Action SDK can be nice - but would likely still call node as of today :s. > I am leaning toward having our own Apache Commons setup action. Any > thoughts or volunteers? > > Gary > > PS: For Windows node, we could use Powershell if available to use wget. > > > > > > On Sat, Aug 15, 2020, 09:46 John Patrick wrote: > > > >> I've raised some pull requests to add the Takari maven wrapper. > >> > >> The Takari maven wrapper is EOL and will be replaced with the Maven > >> Wrapper when Maven v3.7.0 is released. > >> > >> I've added the Takari version as maven v3.7.0 is not yet out. I've > >> been using the Takari maven wrapper for about 4 years now and it has > >> reduced a lot of maintenance and setup tasks. > >> > >> - Maven Wrapper is Maven-As-Code > >> - CI/CD, your docker images or Jenkins slaves no longer need maven pre > >> installed, so less maintenance tasks > >> - Developers don't need to pre install maven > >> - Projects control what version of maven to use, maybe a legacy > >> project needs v3.3.1 and a newer project needs v3.6.3. A developer > >> doesn't need to keep changing their PATH, they just use ./mvnw. > >> - Want to check a new version of maven, just change the properties, > >> then it can undergo the standard pull request build checks to make > >> sure the project works with that version. > >> > >> The first PR I raised was for commons-code and can be found here > >> https://github.com/apache/commons-codec/pull/58 > >> > >> I've also done similar or; > >> commons-collections > >> commons-configuration > >> commons-io > >> commons-lang > >> commons-parent > >> httpcomponent-client > >> httpcomponent-core > >> httpcomponent-parent > >> > >> John > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> >
Re: Introducing Maven Wrapper
On Wed, Aug 19, 2020 at 7:49 AM Gary Gregory wrote: > -1 from me, use a set up action instead, for example: > > https://github.com/marketplace?type=actions=maven > > In particular: > > https://github.com/marketplace/actions/setup-maven > > As recommended here: > https://github.com/actions/setup-java/issues/40#issuecomment-675817329 > > Gary > Looking at https://github.com/marketplace/actions/setup-maven I am wondering why this is not done as a "simple" wget and tar call instead of some big old node project. I am leaning toward having our own Apache Commons setup action. Any thoughts or volunteers? Gary PS: For Windows node, we could use Powershell if available to use wget. > > On Sat, Aug 15, 2020, 09:46 John Patrick wrote: > >> I've raised some pull requests to add the Takari maven wrapper. >> >> The Takari maven wrapper is EOL and will be replaced with the Maven >> Wrapper when Maven v3.7.0 is released. >> >> I've added the Takari version as maven v3.7.0 is not yet out. I've >> been using the Takari maven wrapper for about 4 years now and it has >> reduced a lot of maintenance and setup tasks. >> >> - Maven Wrapper is Maven-As-Code >> - CI/CD, your docker images or Jenkins slaves no longer need maven pre >> installed, so less maintenance tasks >> - Developers don't need to pre install maven >> - Projects control what version of maven to use, maybe a legacy >> project needs v3.3.1 and a newer project needs v3.6.3. A developer >> doesn't need to keep changing their PATH, they just use ./mvnw. >> - Want to check a new version of maven, just change the properties, >> then it can undergo the standard pull request build checks to make >> sure the project works with that version. >> >> The first PR I raised was for commons-code and can be found here >> https://github.com/apache/commons-codec/pull/58 >> >> I've also done similar or; >> commons-collections >> commons-configuration >> commons-io >> commons-lang >> commons-parent >> httpcomponent-client >> httpcomponent-core >> httpcomponent-parent >> >> John >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >>
Re: Introducing Maven Wrapper
-1 from me, use a set up action instead, for example: https://github.com/marketplace?type=actions=maven In particular: https://github.com/marketplace/actions/setup-maven As recommended here: https://github.com/actions/setup-java/issues/40#issuecomment-675817329 Gary On Sat, Aug 15, 2020, 09:46 John Patrick wrote: > I've raised some pull requests to add the Takari maven wrapper. > > The Takari maven wrapper is EOL and will be replaced with the Maven > Wrapper when Maven v3.7.0 is released. > > I've added the Takari version as maven v3.7.0 is not yet out. I've > been using the Takari maven wrapper for about 4 years now and it has > reduced a lot of maintenance and setup tasks. > > - Maven Wrapper is Maven-As-Code > - CI/CD, your docker images or Jenkins slaves no longer need maven pre > installed, so less maintenance tasks > - Developers don't need to pre install maven > - Projects control what version of maven to use, maybe a legacy > project needs v3.3.1 and a newer project needs v3.6.3. A developer > doesn't need to keep changing their PATH, they just use ./mvnw. > - Want to check a new version of maven, just change the properties, > then it can undergo the standard pull request build checks to make > sure the project works with that version. > > The first PR I raised was for commons-code and can be found here > https://github.com/apache/commons-codec/pull/58 > > I've also done similar or; > commons-collections > commons-configuration > commons-io > commons-lang > commons-parent > httpcomponent-client > httpcomponent-core > httpcomponent-parent > > John > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [all] cicd philosophy (was: Re: Introducing Maven Wrapper)
I personally only use mvnw as a tool to force maven versions, or on situations where we must use some machines without maven installed. It is quite like gradlew in usage, but notice that maven have far less major versions and far better backward compatibility than gradle, so in most repos we do not actually need mvnw. For commons repos, I tend to suggest only add it when needed. And I havn't see any repos really need it(I played with only several commons repos). Or do you really got a problem, like, some of our ancient repos can only be built on a special maven version? If so then I do agree add mvnw. otherwise not. Gary Gregory 于 2020年8月16日周日 上午2:20写道： > Hi All, > > I would really prefer we do not do this. > > Note that there is no blocking issue to fix here. When you build in a CI, > you know what OS you get and Maven is pre-configured, no mystery. > > My view here is that it would be the CI's job to toggle the Maven version > just like a CI does for Java, the OS, and everything else a CI build uses. > > What I can see us doing is going to GitHub and asking for a > actions/setup-maven just like there is a actions/setup-java. If we do > anything we should create our own actions/setup-maven. > > I personally do not want to see or maintain copies of these files in 20+ > repositories; it seems like a giant maintenance headache to me. I don't > want to consider why this component does it this way and this other one > that way. I've been aiming for GitHub CI builds to be as consistent as > possible FWIW. > > Gary > > On Sat, Aug 15, 2020 at 1:22 PM Rob Tompkins wrote: > > > Hello all, > > > > I first want to thank John for bringing these points to light as I think > > we can have quite a healthy discussion about the CI/CD philosophy > employed > > by the project (Apache Commons) generally. Furthermore, I hope to set > > precedent with intent and direction with the following comments. Note, > > these are merely ideas yet to be set in stone. I would propose that we > > draft the ideas using this thread and potentially have a PMC > > level/committer/user level [POLL] (to be handled on the dev@ list) on > > direction following debate and drafting. I quite enjoy suggestions and > > ideas from all areas and take quite seriously the suggestions of any user > > of the project. :-) > > > > Having worked with ./mvnw extensively during $work over the last 5 years, > > I’m quite hesitant to use it in CI. Note, we intentionally have NO > > continuous deployment as we GPG sign all of our artifacts locally, and we > > intentionally do not publish snapshots as we don’t want people actively > > consuming our inflight development work. We use beta releases instead for > > this purpose. Furthermore, all of our CI processes have explicit > > declarations for a various array of different java versions (open to > > varying across maven versions here). But do note that they are indeed all > > quite hard coded in our github actions files, towards which we are > > migrating. > > > > All that said, I do indeed see quite a good argument for including ./mvnw > > in the project and that is to expedite developer productivity by helping > to > > install the latest version of Apache Maven, and I want to be clear here > > that we only want to install the latest version of Apache Maven as we > very > > much do not want to be prescriptive with our java versioning. We, in > fact, > > work quite hard to maintain backwards compatibility to the oldest freely > > available supported (long-term-support) version of java. > > > > I also wonder, but am unsure of the potential here with either GitHub’s > > actions or GitHubs dependabot, if we can automate upversioning maven to > > it’s latest version in said .properties files. > > > > Thoughts? > > > > Cheers, > > -Rob > > > > > On Aug 15, 2020, at 9:45 AM, John Patrick > > wrote: > > > > > > I've raised some pull requests to add the Takari maven wrapper. > > > > > > The Takari maven wrapper is EOL and will be replaced with the Maven > > > Wrapper when Maven v3.7.0 is released. > > > > > > I've added the Takari version as maven v3.7.0 is not yet out. I've > > > been using the Takari maven wrapper for about 4 years now and it has > > > reduced a lot of maintenance and setup tasks. > > > > > > - Maven Wrapper is Maven-As-Code > > > - CI/CD, your docker images or Jenkins slaves no longer need maven pre > > > installed, so less maintenance tasks > > > - Developers don't need to pre install maven > > > - Projects control what version of maven to use, maybe a legacy > > > project needs v3.3.1 and a newer project needs v3.6.3. A developer > > > doesn't need to keep changing their PATH, they just use ./mvnw. > > > - Want to check a new version of maven, just change the properties, > > > then it can undergo the standard pull request build checks to make > > > sure the project works with that version. > > > > > > The first PR I raised was for commons-code and can be found here > > >
Re: [all] cicd philosophy (was: Re: Introducing Maven Wrapper)
Hi All, I would really prefer we do not do this. Note that there is no blocking issue to fix here. When you build in a CI, you know what OS you get and Maven is pre-configured, no mystery. My view here is that it would be the CI's job to toggle the Maven version just like a CI does for Java, the OS, and everything else a CI build uses. What I can see us doing is going to GitHub and asking for a actions/setup-maven just like there is a actions/setup-java. If we do anything we should create our own actions/setup-maven. I personally do not want to see or maintain copies of these files in 20+ repositories; it seems like a giant maintenance headache to me. I don't want to consider why this component does it this way and this other one that way. I've been aiming for GitHub CI builds to be as consistent as possible FWIW. Gary On Sat, Aug 15, 2020 at 1:22 PM Rob Tompkins wrote: > Hello all, > > I first want to thank John for bringing these points to light as I think > we can have quite a healthy discussion about the CI/CD philosophy employed > by the project (Apache Commons) generally. Furthermore, I hope to set > precedent with intent and direction with the following comments. Note, > these are merely ideas yet to be set in stone. I would propose that we > draft the ideas using this thread and potentially have a PMC > level/committer/user level [POLL] (to be handled on the dev@ list) on > direction following debate and drafting. I quite enjoy suggestions and > ideas from all areas and take quite seriously the suggestions of any user > of the project. :-) > > Having worked with ./mvnw extensively during $work over the last 5 years, > I’m quite hesitant to use it in CI. Note, we intentionally have NO > continuous deployment as we GPG sign all of our artifacts locally, and we > intentionally do not publish snapshots as we don’t want people actively > consuming our inflight development work. We use beta releases instead for > this purpose. Furthermore, all of our CI processes have explicit > declarations for a various array of different java versions (open to > varying across maven versions here). But do note that they are indeed all > quite hard coded in our github actions files, towards which we are > migrating. > > All that said, I do indeed see quite a good argument for including ./mvnw > in the project and that is to expedite developer productivity by helping to > install the latest version of Apache Maven, and I want to be clear here > that we only want to install the latest version of Apache Maven as we very > much do not want to be prescriptive with our java versioning. We, in fact, > work quite hard to maintain backwards compatibility to the oldest freely > available supported (long-term-support) version of java. > > I also wonder, but am unsure of the potential here with either GitHub’s > actions or GitHubs dependabot, if we can automate upversioning maven to > it’s latest version in said .properties files. > > Thoughts? > > Cheers, > -Rob > > > On Aug 15, 2020, at 9:45 AM, John Patrick > wrote: > > > > I've raised some pull requests to add the Takari maven wrapper. > > > > The Takari maven wrapper is EOL and will be replaced with the Maven > > Wrapper when Maven v3.7.0 is released. > > > > I've added the Takari version as maven v3.7.0 is not yet out. I've > > been using the Takari maven wrapper for about 4 years now and it has > > reduced a lot of maintenance and setup tasks. > > > > - Maven Wrapper is Maven-As-Code > > - CI/CD, your docker images or Jenkins slaves no longer need maven pre > > installed, so less maintenance tasks > > - Developers don't need to pre install maven > > - Projects control what version of maven to use, maybe a legacy > > project needs v3.3.1 and a newer project needs v3.6.3. A developer > > doesn't need to keep changing their PATH, they just use ./mvnw. > > - Want to check a new version of maven, just change the properties, > > then it can undergo the standard pull request build checks to make > > sure the project works with that version. > > > > The first PR I raised was for commons-code and can be found here > > https://github.com/apache/commons-codec/pull/58 > > > > I've also done similar or; > > commons-collections > > commons-configuration > > commons-io > > commons-lang > > commons-parent > > httpcomponent-client > > httpcomponent-core > > httpcomponent-parent > > > > John > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [all] cicd philosophy (was: Re: Introducing Maven Wrapper)
Hello. Le sam. 15 août 2020 à 19:22, Rob Tompkins a écrit : > > Hello all, > > I first want to thank John for bringing these points to light as I think we > can have quite a healthy discussion about the CI/CD philosophy employed by > the project (Apache Commons) generally. Furthermore, I hope to set precedent > with intent and direction with the following comments. Note, these are merely > ideas yet to be set in stone. I would propose that we draft the ideas using > this thread and potentially have a PMC level/committer/user level [POLL] (to > be handled on the dev@ list) on direction following debate and drafting. I > quite enjoy suggestions and ideas from all areas and take quite seriously the > suggestions of any user of the project. :-) > > Having worked with ./mvnw extensively during $work over the last 5 years, I’m > quite hesitant to use it in CI. I didn't know about "mvnw" until today, and it still doesn't strike me as necessary (but I could be convinced by more concrete examples). Just trusting your experience, I'd be reluctant to change yet another aspect of our handling of projects (unless it is part of a rationalization effort). > Note, we intentionally have NO continuous deployment as we GPG sign all of > our artifacts locally, and we intentionally do not publish snapshots as we > don’t want people actively consuming our inflight development work. Not entirely correct: Some projects do publish snapshots. And they were sometimes proposed as a way to check that some bug had been fixed. > We use beta releases instead for this purpose. Unless I'm mistaken, the purpose is different: a release (beta or otherwise) comes with certain checks which snapshots do not have (possibly making the latter unacceptable in some environments). > Furthermore, all of our CI processes have explicit declarations for a various > array of different java versions (open to varying across maven versions > here). But do note that they are indeed all quite hard coded in our github > actions files, towards which we are migrating. When was this decided? > All that said, I do indeed see quite a good argument for including ./mvnw in > the project and that is to expedite developer productivity by helping to > install the latest version of Apache Maven, and I want to be clear here that > we only want to install the latest version of Apache Maven as we very much do > not want to be prescriptive with our java versioning. We, in fact, work quite > hard to maintain backwards compatibility to the oldest freely available > supported (long-term-support) version of java. I'm a bit lost (wrt what you wrote above): Is "mvnw" good or not? IIUC (?), it allows specifying (bundle?) a specific version of maven. How is it better than just note somewhere the known issues (and fix them ASAP)? > > I also wonder, but am unsure of the potential here with either GitHub’s > actions or GitHubs dependabot, if we can automate upversioning maven to it’s > latest version in said .properties files. Completely lost now. Either people who want (for all the good reasons) to move to an all-GitHub solution should lay out their plan, or we should vote, component-wise, on the new sets of requirements, a.o. having a GitHub account in order to be able to manage said component. Regards, Gilles > > Thoughts? > > Cheers, > -Rob > > > On Aug 15, 2020, at 9:45 AM, John Patrick wrote: > > > > I've raised some pull requests to add the Takari maven wrapper. > > > > The Takari maven wrapper is EOL and will be replaced with the Maven > > Wrapper when Maven v3.7.0 is released. > > > > I've added the Takari version as maven v3.7.0 is not yet out. I've > > been using the Takari maven wrapper for about 4 years now and it has > > reduced a lot of maintenance and setup tasks. > > > > - Maven Wrapper is Maven-As-Code > > - CI/CD, your docker images or Jenkins slaves no longer need maven pre > > installed, so less maintenance tasks > > - Developers don't need to pre install maven > > - Projects control what version of maven to use, maybe a legacy > > project needs v3.3.1 and a newer project needs v3.6.3. A developer > > doesn't need to keep changing their PATH, they just use ./mvnw. > > - Want to check a new version of maven, just change the properties, > > then it can undergo the standard pull request build checks to make > > sure the project works with that version. > > > > The first PR I raised was for commons-code and can be found here > > https://github.com/apache/commons-codec/pull/58 > > > > I've also done similar or; > > commons-collections > > commons-configuration > > commons-io > > commons-lang > > commons-parent > > httpcomponent-client > > httpcomponent-core > > httpcomponent-parent > > > > John - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] cicd philosophy (was: Re: Introducing Maven Wrapper)
I'll note that at least from a Jenkins point of view (probably similar with GitHub Actions), it's easier to set up your CI config to use the Maven wrapper script instead of configuring a Maven tool (Jenkins) or using a specific Docker image or similar extra config. We've had a wrapper script in Log4j for a while which is used in our GitHub Actions workflow: https://github.com/apache/logging-log4j2/blob/master/.github/workflows/maven.yml Compare to the more complicated configuration for Maven without the wrapper (I hard-coded known paths here instead of using the "tool" DSL, but it's the same idea): https://github.com/apache/logging-pipelines/blob/master/vars/mvn.groovy On Sat, 15 Aug 2020 at 12:22, Rob Tompkins wrote: > > Hello all, > > I first want to thank John for bringing these points to light as I think we > can have quite a healthy discussion about the CI/CD philosophy employed by > the project (Apache Commons) generally. Furthermore, I hope to set precedent > with intent and direction with the following comments. Note, these are merely > ideas yet to be set in stone. I would propose that we draft the ideas using > this thread and potentially have a PMC level/committer/user level [POLL] (to > be handled on the dev@ list) on direction following debate and drafting. I > quite enjoy suggestions and ideas from all areas and take quite seriously the > suggestions of any user of the project. :-) > > Having worked with ./mvnw extensively during $work over the last 5 years, I’m > quite hesitant to use it in CI. Note, we intentionally have NO continuous > deployment as we GPG sign all of our artifacts locally, and we intentionally > do not publish snapshots as we don’t want people actively consuming our > inflight development work. We use beta releases instead for this purpose. > Furthermore, all of our CI processes have explicit declarations for a various > array of different java versions (open to varying across maven versions > here). But do note that they are indeed all quite hard coded in our github > actions files, towards which we are migrating. > > All that said, I do indeed see quite a good argument for including ./mvnw in > the project and that is to expedite developer productivity by helping to > install the latest version of Apache Maven, and I want to be clear here that > we only want to install the latest version of Apache Maven as we very much do > not want to be prescriptive with our java versioning. We, in fact, work quite > hard to maintain backwards compatibility to the oldest freely available > supported (long-term-support) version of java. > > I also wonder, but am unsure of the potential here with either GitHub’s > actions or GitHubs dependabot, if we can automate upversioning maven to it’s > latest version in said .properties files. > > Thoughts? > > Cheers, > -Rob > > > On Aug 15, 2020, at 9:45 AM, John Patrick wrote: > > > > I've raised some pull requests to add the Takari maven wrapper. > > > > The Takari maven wrapper is EOL and will be replaced with the Maven > > Wrapper when Maven v3.7.0 is released. > > > > I've added the Takari version as maven v3.7.0 is not yet out. I've > > been using the Takari maven wrapper for about 4 years now and it has > > reduced a lot of maintenance and setup tasks. > > > > - Maven Wrapper is Maven-As-Code > > - CI/CD, your docker images or Jenkins slaves no longer need maven pre > > installed, so less maintenance tasks > > - Developers don't need to pre install maven > > - Projects control what version of maven to use, maybe a legacy > > project needs v3.3.1 and a newer project needs v3.6.3. A developer > > doesn't need to keep changing their PATH, they just use ./mvnw. > > - Want to check a new version of maven, just change the properties, > > then it can undergo the standard pull request build checks to make > > sure the project works with that version. > > > > The first PR I raised was for commons-code and can be found here > > https://github.com/apache/commons-codec/pull/58 > > > > I've also done similar or; > > commons-collections > > commons-configuration > > commons-io > > commons-lang > > commons-parent > > httpcomponent-client > > httpcomponent-core > > httpcomponent-parent > > > > John > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[all] cicd philosophy (was: Re: Introducing Maven Wrapper)
Hello all, I first want to thank John for bringing these points to light as I think we can have quite a healthy discussion about the CI/CD philosophy employed by the project (Apache Commons) generally. Furthermore, I hope to set precedent with intent and direction with the following comments. Note, these are merely ideas yet to be set in stone. I would propose that we draft the ideas using this thread and potentially have a PMC level/committer/user level [POLL] (to be handled on the dev@ list) on direction following debate and drafting. I quite enjoy suggestions and ideas from all areas and take quite seriously the suggestions of any user of the project. :-) Having worked with ./mvnw extensively during $work over the last 5 years, I’m quite hesitant to use it in CI. Note, we intentionally have NO continuous deployment as we GPG sign all of our artifacts locally, and we intentionally do not publish snapshots as we don’t want people actively consuming our inflight development work. We use beta releases instead for this purpose. Furthermore, all of our CI processes have explicit declarations for a various array of different java versions (open to varying across maven versions here). But do note that they are indeed all quite hard coded in our github actions files, towards which we are migrating. All that said, I do indeed see quite a good argument for including ./mvnw in the project and that is to expedite developer productivity by helping to install the latest version of Apache Maven, and I want to be clear here that we only want to install the latest version of Apache Maven as we very much do not want to be prescriptive with our java versioning. We, in fact, work quite hard to maintain backwards compatibility to the oldest freely available supported (long-term-support) version of java. I also wonder, but am unsure of the potential here with either GitHub’s actions or GitHubs dependabot, if we can automate upversioning maven to it’s latest version in said .properties files. Thoughts? Cheers, -Rob > On Aug 15, 2020, at 9:45 AM, John Patrick wrote: > > I've raised some pull requests to add the Takari maven wrapper. > > The Takari maven wrapper is EOL and will be replaced with the Maven > Wrapper when Maven v3.7.0 is released. > > I've added the Takari version as maven v3.7.0 is not yet out. I've > been using the Takari maven wrapper for about 4 years now and it has > reduced a lot of maintenance and setup tasks. > > - Maven Wrapper is Maven-As-Code > - CI/CD, your docker images or Jenkins slaves no longer need maven pre > installed, so less maintenance tasks > - Developers don't need to pre install maven > - Projects control what version of maven to use, maybe a legacy > project needs v3.3.1 and a newer project needs v3.6.3. A developer > doesn't need to keep changing their PATH, they just use ./mvnw. > - Want to check a new version of maven, just change the properties, > then it can undergo the standard pull request build checks to make > sure the project works with that version. > > The first PR I raised was for commons-code and can be found here > https://github.com/apache/commons-codec/pull/58 > > I've also done similar or; > commons-collections > commons-configuration > commons-io > commons-lang > commons-parent > httpcomponent-client > httpcomponent-core > httpcomponent-parent > > John > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Introducing Maven Wrapper
I've raised some pull requests to add the Takari maven wrapper. The Takari maven wrapper is EOL and will be replaced with the Maven Wrapper when Maven v3.7.0 is released. I've added the Takari version as maven v3.7.0 is not yet out. I've been using the Takari maven wrapper for about 4 years now and it has reduced a lot of maintenance and setup tasks. - Maven Wrapper is Maven-As-Code - CI/CD, your docker images or Jenkins slaves no longer need maven pre installed, so less maintenance tasks - Developers don't need to pre install maven - Projects control what version of maven to use, maybe a legacy project needs v3.3.1 and a newer project needs v3.6.3. A developer doesn't need to keep changing their PATH, they just use ./mvnw. - Want to check a new version of maven, just change the properties, then it can undergo the standard pull request build checks to make sure the project works with that version. The first PR I raised was for commons-code and can be found here https://github.com/apache/commons-codec/pull/58 I've also done similar or; commons-collections commons-configuration commons-io commons-lang commons-parent httpcomponent-client httpcomponent-core httpcomponent-parent John - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
