I can understand where you are coming from, and I often follow a rather similar approach where I will implement things myself if the alternative is depending on some unwieldy beast of a dependency.
(I did write my own Servlet engine for a project once, and it was faster than Jetty, and had better GC characteristics at the time, but in the end I ditched it for Jetty as I didn't want to maintain a complete HTTP implementation - that wasn't key to the project. The extra performance and the dependencies I got rid of were just not worth the extra effort).
However the reason I always chose to use JUnit was because I wanted the unit tests to be familiar to other developers since this is often where people go to understand how a piece of code works. In a sense it was a part of Java at the time. And I chose Maven for similar reasons. Plus the fact that Maven wasn't something you could really escape from in Java. Sooner or later it rears its head and I thought I would cause less pain if I just accepted that.
I like the idea behind Maven: convention over configuration, but I've never been a fan of how that idea has been executed. It could have been better if someone more experienced (and obsessive) had designed it way back when.
I still think Gradle is worse than Maven though. I'm not a fan of scriptable build systems, they should be declarative (and most of the time when people think they need to script things they just haven't bothered to learn how to use the tools). And even if you use Gradle, you can't really escape dealing with Maven.
(I ditched Java a couple of years back, so I haven't done Java for a while. I'm not overly fond of Oracle, so I had promised myself that I would stop using Java as soon as I found a replacement language that suited me. It took a few years, but I eventually found a different language I liked even better: Go)