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
[Compress] SevenZOutputFile vs ArchiveOutputStream
Hi All, Why does SevenZOutputFile NOT extend ArchiveOutputStream? Thank you, Gary
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 > >
