Amper – Improving the Build Tooling User Experience | The JetBrains Blog
Amper – Improving the Build Tooling User Experience | The JetBrains Blog
Introducing Amper, a new experimental project configuration tool focused on usability, onboarding, and IDE support.
Will Amper kill Maven and Gradle?
You're viewing a single thread.
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
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.
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. My projects from ~2000s developed in Ant still compile and work, Maven projects from 2010s still work and compile... can't say that about an Android project from 2014. It doesn't even compile and there's no backwards compatible way to use or upgrade Gradle (from 2.4). To me, gradle is worse than npm ecosystem and we did it all to ourselves.
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.