Maven sucks. It's evil. It makes me want to scream! Why? Three big reasons: it hides problems, it promotes the dysfunctional organization of your team and it stains to your code like blood on cotton.
I know, I know, I shouldn't be quick to judge. Any tool can be misused. Maybe if people learned to use the tool better.
Uh, no!
After spending several months working extensively on fixing (or introducing) continuous integration across industries, team sizes, geographies and levels of complexity, I have no doubt in my mind that Maven is the problem. And I swear I went into each engagement with an open mind - even towards Maven.
The first thing that hit me is that it hides all kinds of problems. I get a jar from someone else's code. Great! I keep working, everything is great. Now I want him to add a new feature. I need to upgrade to the latest version! Oh no! The two code bases have deviated too much! Lets make a rule. We need things to be backwards compatible. Lets not change API. Lets only add new methods. Oh, and maybe if I depend on a SNAPSHOT of the other person's code. But now, he can't change his code willy-nilly. We need a change manager to coordinate changes between teams.
Then the next problem hits. Hey, why are you touching that code? Its my team's code. If you want it to do that, you need to come through the change manager. Lets meet and discuss why you need to upgrade your JDK.
Then a consultant comes along and says "WTF?" - you can do all this by not having artificial divisions in teams and code bases. Lets collectively own the code. If different things need to behave differently at different times, then lets refactor the code to meet these needs. But, uh, fixing it within Maven's world is cheaper and takes less time than combining all the code. Oh, and refactor - that sounds risky! Lets just keep going with what works for now even if we're a little less efficient.
Little does anyone see that their development velocity is excruciatingly low and the incremental investment in maven over time is a lot larger than following a simpler path. And they are completely missing what they really need to be doing: communicating more, gelling as a team, and getting into a flow.
AAARRGGGHHHH!!!!
ok, i'm over-generalizing, but i think you are very much off base, as detailed by other commenters.
Maven is a tool to force you into an established project and deployment structure. Some teams don't do well with structure, and their product usually shows.
1) Problems that I find are pervasive with transitive dependencies via ANY tool that implements them (even ones like macports for simple things like... curl, wget and pandoc)
2) Problems that are masked with Ant because transitive dependencies are highly static by the fact they are bundled with source code in the SCC project/repo. We actually pull in 3Ps less frequently, for good or for bad, when we use Ant. This is because the update dance is more of a pain with Ant than with a simple Maven tag change + download over the network. Using Ant (without Ivy), I have to find that project's homepage, then their custom download page, view the sourceforge banner ad, then finally get my updated binary. Save it into my downloads folder, then copy it and possibly rename it when putting it into my lib/ dir.
Thinking about the concepts of how to fix some of your issues you list, here are some ideas:
1) "Freezable" builds that essentially keep the Convention Over Configuration, but turn it into a static artifact once you want to cut a release. Not something that reaches across the network except during dev cycles.
2) Higher quality transitive dependencies with a better battery of unit tests so that teams don't rev as often.
3) Treat enabling-3Ps, like log4j, as 3Ps, but internal libraries inside a given project as part of that project's code base -- not as some thing to lock down hard so that everyone can magically reuse it for all eternity.
4) Great APIs are stable, but are also hard to come by. We have to figure out the right place for API boundaries. Not everything need to "implements IPervasiveInterface". We do a terrible job of that right now as an industry. Internals should get refactored. Fine. Interfaces should try to stay stable. I'm worried that isn't what I am hearing espoused about interfaces.
I don't hear you describing the proper flow you want here in terms of code modules. I'm willing to listen, but for each "sucks" I need an abstract description of the right flow.
Working with multiple teams producing multiple modules that must integrate together is complex, whatever build tool you decide to use.
That's why we use CI, to constantly get feedback on the integration.
An, yes, an API is a commitment. If you regularly break the API you establish, you regularly break this commitment. Backwards compatibility is fairness to the others, deprecation allows you to move forward, branches can isolate you for a little while but if API have been evolved carelessly, pain is down the road.
A build tool has nothing to do with this.
An yes, I have worked with Maven on multi-sites multi-teams multi-modules projects.