> > For implementing this in practice, we could also extend our CI pipeline a > bit, and count the number of deprecation warnings while compiling Flink. > We would hard-code the current number of deprecations and fail the build if > that number increases.
Maybe we could leverage sonar cloud infrastructure for this. They already have built in rules for deprecation warnings [1]. Also they have a free offering for public open-source repositories [2]. [1] https://rules.sonarsource.com/java/RSPEC-1874 [2] https://sonarcloud.io/pricing On Wed, Jul 14, 2021 at 5:38 PM Chesnay Schepler <ches...@apache.org> wrote: > If someone started preparing a junit5 migration PR they will run into > merge conflicts if everyone now starts replacing these instances at will. > > There are also some options on the table on how to actually do the > migration; we can use hamcrest of course, or create a small wrapper in > our test utils that retains the signature junit signature (then we'd > just have to adjust imports). > > On 14/07/2021 16:33, Stephan Ewen wrote: > > @Chesnay - can you elaborate on this? In the classes I worked with so > far, > > it was a 1:1 replacement of "org.junit.Assert.assertThat()" to > > "org.hamcrest.MatcherAssert.assertThat()". > > What other migration should happen there? > > > > On Wed, Jul 14, 2021 at 11:13 AM Chesnay Schepler <ches...@apache.org> > > wrote: > > > >> It may be better to not do that to ease the migration to junit5, where > >> we have to address exactly these usages. > >> > >> On 14/07/2021 09:57, Till Rohrmann wrote: > >>> I actually found > >>> myself recently, whenever touching a test class, replacing Junit's > >>> assertThat with Hamcrest's version which felt quite tedious. > >> > >> > >
