- cross-posted to:
- kotlin@programming.dev
- cross-posted to:
- kotlin@programming.dev
Will Amper kill Maven and Gradle?
You must log in or register to comment.
Will Amper kill Maven and Gradle?
If it works and it is free then maybe, but probably still not. Also it is a Gradle plugin, so it will not touch Maven at all. And it uses yaml configs… I do not like this at all 😀
Maven is very good for small projects and Gradle take a niche of Ant on steroids. Nobody in his sane mind will migrate from one build system to other until benefits of migration outweighs the burden of redoing all pipelines from scratch.
The problem with JB products that they are barely working now. If you step one iota outside of mainstream functionality then it will break.
Both Maven and Gradle integration are very very brittle. And also not really optimized for big projects with big amount of modules/sources.
And I love JB products. It saddens me to see every year I drops in quality of IntelliJ. And New fancy interface transition is just the mess.
Migration to the subscription based allowed JB to release more products but overral quality dropped.
Since I can remember IntelliJ frequently fails to detect changes in
pom.xml. Changed dependency? Manually clean the project and click 2 buttons to let IJ discover it. Added new code without having the right dependency? Download dependencies manually first, try rebuilding the project, but you’re likely to have to restart the IDE anyway. That’s why I moved to VSCode.😱 Never had this problems whith IJ and Gradle project
I think JetBrains has fully bought into Gradle. I think Maven support has been less and less over time, which shouldn’t be a surprise. Gradle supports native Kotlin build scripts (i.e.
build.gradle.kts), as well as putting a lot of work into ensuring their tools fit well within the Gradle ecosystem (exhibit A: https://github.com/JetBrains/intellij-platform-plugin-template). I think it only natural for the creator/owner/maintainer of Kotlin to go full in on the build system that supports the language!controversial take: who still uses maven? who would prefer xml files over build scripts? (ok… fine, big timers like RedHat definitely do, or at least, have never taken/don’t want to take the time to upgrade lol)
who still uses maven? who would prefer xml files over build scripts? (ok… fine, big timers like RedHat definitely do, or at least, have never taken/don’t want to take the time to upgrade lol)
Simple: Gradle doesn’t work well with inherited projects. If you have a family tree of projects, maven always wins. Lowers complexity, integrations are easier, bom are better integrated, smaller size of
~/.m2(by literally gigabytes) and no surprises with classpath loading order. It’s not about stupid xml or stupid groovy, it’s about complexity of managing single parent project, 200 children and 150 more grandchildren and having them working out of box. More than 12 years of using Gradle, I’ve never it seen working well outside of Android projects (and it still needs Java7 right?).End users for gradle are corporations: Google and IntelliJ. Maven has been developed for developers and technical project managers.
Interesting perspective I hadn’t considered before, thanks for sharing. Also, not sure where the Java 7 thing comes from, but I run Java 17 with gradle/kotlin non-android, works very well in IntelliJ, outside of consuming a million gigs of ram lol
Also, not sure where the Java 7 thing comes from, but I run Java 17 with gradle/kotlin non-android
Yes, this seems to have improved, just successfully made a project with gradle and it works with java 18. About 2 years ago it wasn’t possible to use Flutter with Java 9, at all.
Doesn’t IntelliJ has some kind of Gradle wrapper built-in it that integrates with internals of IJ? They developed it to have more powers in Gradle and Kotlin, but didn’t care to provide feature parity with Maven. Then they cried when people started leaving IJ for VSC.
