Pyramids are engineering feats, Java EE people are building stuff which look like works from M. C. Escher, it bends your mind when you try to understand the code :)
Also a little anecdote to the complexity of enterprise stuff: at the company I worked before, they were writing an entire persistence framework from scratch (with annotations instead of xml) so they could get away from hibernate.
As opposed to using MyBatis or JDBI? What was their rationale for rolling their own, too many employees on the team?
The problem comes because everyone thinks their build is a special snowflake that absolutely needs to replace every instance of the number 15 in their codebase with a heart symbol. No. You don't do that. If you're doing something standard there will be a plugin for it. If there isn't, it's probably because what you want to do is a very bad idea - do it in code instead. If you absolutely insist, you're going to have to write a plugin, which at least means you'll follow coding standards, have test coverage, and all the rest of it, rather than just sticking random unreviewed crap into your build like happens in every other build system.
Before Maven, generally I remember there being Ant. And I remember that if an application needed dependencies, unless one explicitly used a dependency manager like ivy, one had to go find the jars and download them, and ensure they were on the class path. Ant was simpler, in the sense that if you wanted something to happen, you would create an ant target and instruct ant on what was going to happen.
Maven isn't simple in the same way, so it does require one to learn more about how it works in order for things to fit together, but I find it drastically simplifies working with java projects. The location of all dependencies are defined, they are downloaded, and there is default behaviour to be expected with each of the maven goals. Overridable properties enable one to have a build which works first time directly after checkout. I much prefer it to what was there before.
If we look at what has come since - sbt, gradle, and leiningen all seem to use a similar mechanism to Maven for dependencies.
The maven ecosystem is really nice compared to that of many other languages (e.g. python, javascript.) It's deep in terms of functionality, but for getting started (dependencies) it's not that complex. And a good IDE will take care of all of the boilerplate for you.
> Nothing works by default, you always have to include stuff here and there, write one or two xml files before anything would work,
I do share your dislike of enterprise Java development on the other hand. I worked a JBoss/Spring/Hibernate/Tomcat contract a while back; that thing was an unholy mess which took 4 minutes(!) to start up. However, there are much lighterweight frameworks out there; I'm currently building an app on angular -> dropwizard/guice/jdbi, which overall is quite elegant. No XML in sight (aside from the maven configs).
I'll admit I filtered out a lot of candidates becaused they mentioned stuff like "J2EE Engineer" on their resume, which seemed to imply strong incompatibilities with our coding style...
Fortunately not everyone in the Java community is modeled after JEE (or Maven, Spring, etc.).
Nothing works by default, you always have to include stuff here and there, write one or two xml files before anything would work, I'm fine with configuration but I should at least work by default. Maven is a nightmare to use, it's so complicated I would generally not use it. I would just like a package manager which is only doing packages like any other language.
The main problem with the Java community in my own opinion is they are building pyramids while other languages are building stuff out of bricks, it's the opposite of the UNIX philosophy.