I’m still a +1 for mvnw….do we have a consensus here? -Rob
> On Aug 19, 2020, at 4:27 PM, John Patrick <nhoj.patr...@gmail.com> 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 <garydgreg...@gmail.com> a >> écrit : >> >>> On Wed, Aug 19, 2020 at 7:49 AM Gary Gregory <garydgreg...@gmail.com> >>> wrote: >>> >>>> -1 from me, use a set up action instead, for example: >>>> >>>> https://github.com/marketplace?type=actions&query=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 <nhoj.patr...@gmail.com> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
