I'll note that at least from a Jenkins point of view (probably similar with GitHub Actions), it's easier to set up your CI config to use the Maven wrapper script instead of configuring a Maven tool (Jenkins) or using a specific Docker image or similar extra config. We've had a wrapper script in Log4j for a while which is used in our GitHub Actions workflow: https://github.com/apache/logging-log4j2/blob/master/.github/workflows/maven.yml
Compare to the more complicated configuration for Maven without the wrapper (I hard-coded known paths here instead of using the "tool" DSL, but it's the same idea): https://github.com/apache/logging-pipelines/blob/master/vars/mvn.groovy On Sat, 15 Aug 2020 at 12:22, 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 > -- Matt Sicker <boa...@gmail.com> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
