Does the dependabot see difference between test and runtime
dependencies? If it doesn't is there any other tool which does?
While I agree with Elliotte that each dependency requires some care and
comes at the cost, I tend to stay reasonable about junit (and other test
deps) versions. While the
It doesn't change the effort. It even adds one more project to update -
the one of the parent on top of the projects wher the partent needs to
get updated...
Am 21.07.2025 um 19:47 schrieb Andy Law:
As more of a wider question, why would this not be specified in the Parent POM
if it were adop
As more of a wider question, why would this not be specified in the Parent POM
if it were adopted as an “approved” dependency?
Later,
Andy
From: Matthias Bünger
Date: Monday, 21 July 2025 at 18:40
To: dev@maven.apache.org
Subject: Re: The use of AssertJ assertions
Hi all,
while I really lik
Hi all,
while I really like the AssertJ assertions, e.g. for readibility and
expandability (custom assertions), I'm slighty against using it in a big
project like Maven (thinking of core, plugins, components) cause of the
time it takes to keep the dependncy up to date - we have about 100
rep
On Mon, Jul 21, 2025 at 11:13 AM Delany wrote:
>
> If I'm not mistaken Guava's Preconditions is for runtime argument
> validation and should not be used in test code.
It's been a while since I used it. s/Guava/Truth
I just think of them as all part of the same Google Java stack but I
guess that'
As a rare contributor, I hope I won't be asked to use AssertJ or Hamcrest
instead of JUnit assertion APIs (IMO), I find the style unbearable.
Gary
On Mon, Jul 21, 2025, 08:02 Romain Manni-Bucau
wrote:
> The thing is that technically it obviously doesn't enable any new use case
> but it starts t
The thing is that technically it obviously doesn't enable any new use case
but it starts to bring the question of which additional library you want to
support (in terms of code, upgrades, documentations, newcomer learning
curve etc).
JUnit assertions are there and quite do the job well.
Adding asse
If I'm not mistaken Guava's Preconditions is for runtime argument
validation and should not be used in test code.
I replaced Hamcrest with AssertJ in my own projects and I don't miss it.
Its the natural thing to do, and I'll gladly do so for Maven if it means
supporting AssertJ officially.
So that
Every dependency is a liability, even in test code. I strongly prefer
to stick to the standard assertions in JUnit. I also prefer not to
have decode idiosyncratic test libraries with slightly varying
conventions and arguments. AssertJ is not the only one, not even the
only one used in the Maven cod
