3 ms·

Practically speaking, Maven (the executable tool) and pom.xml (the language) create a hot dependency mess when projects get past the toy stage. Maven makes mos

Practically speaking, Maven (the executable tool) and pom.xml (the language) create a hot dependency mess when projects get past the toy stage. Maven makes most simple things impossible and a few challenges trivial. "Hamstrung" is the word that comes to mind. Coupling a declarative, own-the-world, XML programming language with innumerable slap-dash/poorly maintained plugins is the pits. All that said, maven repositories and the groupId:artifactId:version:type:classifier organization of modules are really genius. As you say, this genius shines in IDE's where, as just one example, you get nice binary/source .jar distributions automatically downloaded to your local repo. Having an IDE's debugger be able to seamlessly and accurately step through 1st party java sources and 3rd party source .jar sources is always so impressive to me. Gradle (and Ivy before it) help paper over the pain and expose the good parts of the maven ecosystem. I have some gripes with Gradle, but after seeing it in action (and now that IDE's can grok its project configs) I'm so happy to be ditching maven/plugins and hand-written pom's for the most part. Java needs a holistic dependency management/dependency injection/artifact repository/publishing workflow rethink where well-defined concepts like semver are enforced in the version numbering scheme, making it easier to express "safe" legal version ranges in transitive dependencies.

vorg 11y ago
Because Maven (the tool) offers XML as the language, we can put any other language atop it, e.g. with https://github.com/takari/polyglot-maven https://github.com/takari/polyglot-maven we can use Clojure, Groovy, Ruby, or Scala as the language. Gradle offers only Groovy, nothing else, so we don't have any choice over how to interact with the build API.
LoneWolf 11y ago
I admit that maven on large projects can lead to some dependency problems, while not the final solution I found that Maven Enforcer Plugin[1] helps to reduce this mess, makes it harder to keep the dependencies because sometimes you have to exclude them everywhere and add your own by hand, but I don't see any better alternative, APIs change. [1] http://maven.apache.org/enforcer/maven-enforcer-plugin/ http://maven.apache.org/enforcer/maven-enforcer-plugin/
dj-wonk 11y ago
After I first read your last paragraph, I wondered "how might you want to see semantic versioning get enforced?" ... but I think you are instead referring to the lack of version number ranges in Maven?

vorg 11y ago

Because Maven (the tool) offers XML as the language, we can put any other language atop it, e.g. with https://github.com/takari/polyglot-maven https://github.com/takari/polyglot-maven we can use Clojure, Groovy, Ruby, or Scala as the language. Gradle offers only Groovy, nothing else, so we don't have any choice over how to interact with the build API.

LoneWolf 11y ago

I admit that maven on large projects can lead to some dependency problems, while not the final solution I found that Maven Enforcer Plugin[1] helps to reduce this mess, makes it harder to keep the dependencies because sometimes you have to exclude them everywhere and add your own by hand, but I don't see any better alternative, APIs change. [1] http://maven.apache.org/enforcer/maven-enforcer-plugin/ http://maven.apache.org/enforcer/maven-enforcer-plugin/

dj-wonk 11y ago

After I first read your last paragraph, I wondered "how might you want to see semantic versioning get enforced?" ... but I think you are instead referring to the lack of version number ranges in Maven?