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
>
>

Reply via email to