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
