Hello. Le sam. 15 août 2020 à 19:22, Rob Tompkins <chtom...@gmail.com> a écrit : > > 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.
I didn't know about "mvnw" until today, and it still doesn't strike me as necessary (but I could be convinced by more concrete examples). Just trusting your experience, I'd be reluctant to change yet another aspect of our handling of projects (unless it is part of a rationalization effort). > 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. Not entirely correct: Some projects do publish snapshots. And they were sometimes proposed as a way to check that some bug had been fixed. > We use beta releases instead for this purpose. Unless I'm mistaken, the purpose is different: a release (beta or otherwise) comes with certain checks which snapshots do not have (possibly making the latter unacceptable in some environments). > 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. When was this decided? > 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'm a bit lost (wrt what you wrote above): Is "mvnw" good or not? IIUC (?), it allows specifying (bundle?) a specific version of maven. How is it better than just note somewhere the known issues (and fix them ASAP)? > > 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. Completely lost now. Either people who want (for all the good reasons) to move to an all-GitHub solution should lay out their plan, or we should vote, component-wise, on the new sets of requirements, a.o. having a GitHub account in order to be able to manage said component. Regards, Gilles > > 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
