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 <xenoam...@gmail.com> 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 <chtom...@gmail.com> 于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 <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 > > > > >
