s/test/project/ ;) > nothing is urgent for updating a test dependency, security issue maybe but that's a test dependency so less important than a runtime one.
while you have no CI I agree, but sadly it is not the case - and we didn't even speak about conflicts it can bring - think guava. Romain Manni-Bucau @rmannibucau <https://x.com/rmannibucau> | .NET Blog <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> Le mer. 23 juil. 2025 à 15:42, Karl Heinz Marbaise <khmarba...@gmx.de.invalid> a écrit : > Hi, > > On 21.07.25 08:04, Slawomir Jaranowski wrote: > > Hi, > > > > For me AssertJ is more powerful than standard JUnit Assertions. > > Assertions with AssertJ are also very good readable for me in code. > > > > So as it is a test dependency I don't have any problem using it. > > Project is very well maintained and has an acceptable license. > > > > > One thing I would like to see is do not mix assertions framework in > > one test class - when we use AssertJ use it everywhere in one test > > class. > > I second that. > > Kind regards > Karl Heinz Marbaise > > > > > On Mon, 21 Jul 2025 at 06:51, Giovanni van der Schelde > > <gvdsche...@gmail.com> wrote: > >> > >> Hi all, > >> > >> In a recent PR review, the use of AssertJ assertions was raised as a > point > >> of discussion. > >> To avoid recurring debates and ensure the PR is reviewed for the changes > >> it provides, I’d like to propose that we clarify the goal regarding > this, > >> and perhaps other, dependencies. > >> > >> Specifically, should we: > >> > >> - Remove the AssertJ dependency entirely to prevent its use? > >> - State that we support the dependency and accept its use in our tests? > >> > >> Having a clear stance on this would help streamline code reviews and > avoid > >> repeated discussions on future PRs. > >> > >> Perhaps there are already some guidelines on this which I'm unaware of, > so > >> I'm looking forward to your input. > >> > >> Regards, > >> > >> Giovanni van der Schelde > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >