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 > >
