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