Why I Moved Back from Gradle to Maven • Hacker News Board

Re: Why I Moved Back from Gradle to Maven

#91

Post by lokedhs » Wed, Apr 04, 2018, 2:05 AM UTC

tsvetkov wrote: post #41

derriz wrote: post #19

I can see the attraction in a build system based on a proper full featured programming language but I've never been tempted to try gradle because I believe the approach has a fundamental flaw. I.e. that it's impossible for IDEs to reliably extract useful project structure from the build description. Even as a 25 year vi/vim user, I've succumbed to depending on IDEs more and more and I believe that any proposed build…

I think it's not correct to say that Turing-completeness somehow prevents extracting project structure. If a build tool can extract that information, why IDE could not do that? In fact this is how Gradle projects are imported into Intellij and Eclipse: Gradle builds project model by running Groovy or Kotlin scripts, and then IDEs are working with declarative model. The real problem is working with scripts themselves:…

To answer your question as to why an IDE can't do it, the reason is that in order to do it you need to solve the halting problem.

Of course, the IDE can do it if you limit yourself to a subset that is not fully Turing complete, which is what IDEA does today.

The issue a lot of people have with Gradle is that this subset is not well defined, and it's very easy to do something that works but will get the tools to have problems, and debugging such issues is not particularly entertaining.

Re: Why I Moved Back from Gradle to Maven

#92

Post by flukus » Wed, Apr 04, 2018, 2:07 AM UTC

derriz wrote: post #19

I can see the attraction in a build system based on a proper full featured programming language but I've never been tempted to try gradle because I believe the approach has a fundamental flaw. I.e. that it's impossible for IDEs to reliably extract useful project structure from the build description. Even as a 25 year vi/vim user, I've succumbed to depending on IDEs more and more and I believe that any proposed build…

I think that's a fundamental flaw of IDE's, they don't integrate with your development environment ;)

Something I just thought of but have yet to try, could we have a build script generate the project structure that an IDE can use and get the best of both worlds? Looking through my VS project files, 50% of it is stuff the make file would be doing, the other 50% is just a list of files and dependencies.

So let's say we generated these project files from a makefile, the IDE could still treat the build process as a black box but as part of executing that black box it gets all the information it needs for intellisense and debugging.

Re: Why I Moved Back from Gradle to Maven

#93

Post by sk5t » Wed, Apr 04, 2018, 2:26 AM UTC

na85 wrote: post #66

kodablah wrote: post #62

Earlier quoted context omitted.

Not ubiquitous and missing shortcuts. How do you compile 5 JVM projects in different JVM languages, sharing different configured sets of potentially hundreds of libraries across the classpath and make sure there are no versioning conflicts? Shortcuts are required, they just don't need to hide everything.

I guess I'd compile them like anything else: using Make to invoke the compiler. Checking versions can be accomplished by using awk or another tool to compare output from $compiler --version. What am I missing?

Your makefile / build script would grow so complex so as to start reimplementing maven or gradle.

Re: Why I Moved Back from Gradle to Maven

#94

Post by dcow » Wed, Apr 04, 2018, 2:35 AM UTC

bsder wrote: post #17

wendelinsky wrote: post #10

Yo, new Gradle developer experience lead here. I fully empathize that it's much too difficult to wrap one's head around Gradle, so I want to share some things you might find interesting: * The Gradle Kotlin DSL, which is nearing production-readiness, substantially improves the assistance/docs one gets through the IDE. * However, the Kotlin DSL does not help with the large API surface and understanding of Gradle conce…

Fix the documentation! Focus on Android Studio because that's the only place people really use Gradle because they are forced to do so. You need to create a LOT of Android Studio sample projects, and they need to be kept up to date for the various versions of Android Studio. If you did nothing but create "Hello World" in a zillion various flavors (Java, Kotlin, Scala, NDK, NDK with static library on different archite…

The gradle team doesn't work on android builds. They work closely with Xavier from googles android build tools team on that.

Re: Why I Moved Back from Gradle to Maven

#95

Post by Pxtl » Wed, Apr 04, 2018, 2:45 AM UTC

freedomben wrote: post #81

kodablah wrote: post #57

Earlier quoted context omitted.

> Flexibility is not something I want in a build system. [...] "Flexibility" just means that the dumbest guy on the project will find sufficient rope to hang the whole team sooner or later. We're on opposite sides here. I can control my team wrt rope and what not. But it's very hard to wrangle a build system to perform some advanced task you need without flexibility. I'd way rather have problems with the build system…

I agree. With an inflexible build system we still end up with the nasty shell script but it's worse because it wraps the build system.

Maybe combine a generic non-language specific build system (some variant of Make without the C obsession?) as the outer wrapper around a very language-oriented and inflexible/opinionated build system?

Re: Why I Moved Back from Gradle to Maven

#96

Post by dcow » Wed, Apr 04, 2018, 2:53 AM UTC

na85 wrote: post #60

kodablah wrote: post #45

Earlier quoted context omitted.

> needs to stop the whole convention-over-configuration idea Yup, and while we're at it, realize that the declarative approach doesn't work after the first basic uses and even though your hello world build file is simple, most people need customization. Scripting the build system should be its main feature and everything else as just shortcuts (to be fair, Gradle kinda does this w/ tasks, but doesn't make it simple t…

This may be naive but doesn't GNU Make tick all these boxes in addition to being ubiquitous?

I like make, but no. Try out gradle; it really does support complex project structures in a much more natural way than make does or even can.

For example, have you ever wanted to break a large project up into subcomponents with build-time enforced dependency relationships? This is trivial with gradle but very hard/custom to do using make. gradle is aware at a domain modeling level about components of a project, their dependencies, and the implementation and interface artifacts they generate. I think this is really cool.

Their native support is still evolving, so it probably can't drop-in replace more complex native builds, but a few years ago I had it building a shared c++ codebase for macOS, android-linux, and iOS. I could test the core on macOS locally as its own project. I had google-test built locally and specified as a dependency (a sibling project) rather than prebuilt and plopped in a vendor directory. And the code was mostly free of ifdef android or macos etc. because I could not only enforce separation at a project level, but also easily provide a place for platform specific glue to live (in their own sibling projects). It was really cool and would have been a lot more work without gradle.

Re: Why I Moved Back from Gradle to Maven

#97

Post by somecoderguy » Wed, Apr 04, 2018, 2:58 AM UTC

tomohawk wrote: post #15

We moved to apache buildr years ago and never looked back. https://buildr.apache.org/

Funny that, because I spent 3 months removing buildr and adding maven on a large, complex project. After a couple of years into buildr, the build had grown so artisanal that even breaking a jar out of one of the build's modules was a multi-week task. After we moved, multiple modules were made into jars and some even wound up becoming external projects very easily.

Everything was done in scripts (predictable when you offer nothing else) and it was so misconfigured and esoteric that nobody happened to notice that it was reaching out to the wrong server for artifacts....WHOOPS!

Dependency management was awful and g'luck even getting something as simple as a dependency tree out of the system. Oh and it appears to lack any mindshare so nobody appears to be improving it and g'luck if you happen to need some help with it.

The problem with buildr is that it's a ruby based build system for Java. Why? Who wants to write their Java build code in Ruby, and why can't they just go work in a RoR company already?

Builds shouldn't be interesting, artisanal, or occupy a lot of your time. They should just produce the artifacts and move on.

Since the switch to Maven I find myself worrying about the builds a lot less and actually working on code instead.

Re: Why I Moved Back from Gradle to Maven

#98

Post by dcow » Wed, Apr 04, 2018, 3:00 AM UTC

na85 wrote: post #66

kodablah wrote: post #62

Earlier quoted context omitted.

Not ubiquitous and missing shortcuts. How do you compile 5 JVM projects in different JVM languages, sharing different configured sets of potentially hundreds of libraries across the classpath and make sure there are no versioning conflicts? Shortcuts are required, they just don't need to hide everything.

I guess I'd compile them like anything else: using Make to invoke the compiler. Checking versions can be accomplished by using awk or another tool to compare output from $compiler --version. What am I missing?

What if two things share a dependency?

Re: Why I Moved Back from Gradle to Maven

#99

Post by djsumdog » Wed, Apr 04, 2018, 3:02 AM UTC

sytse wrote: post #87

We're planning to add a Maven compatible artifact repository to GitLab. I assume that will automatically also work with Gradle, or is there more to it?

Yep, you can publish to a maven repository from Gradle pretty easily. I just setup a project to publish from gradle -> artifactory last week.

Re: Why I Moved Back from Gradle to Maven

#100

Post by djsumdog » Wed, Apr 04, 2018, 3:09 AM UTC

I've used Maven, Gradle and SBT in major commercial projects. I don't understand this Maven love honestly. Maybe everything I had to work on was just setup incorrectly, but the horrid overly verbose xml configuration files combined with the fact that maven constantly recompiled things it didn't need to and was sooo slow.

I think the only good thing from Maven was the directory structure layout (src/{main,test}/{java,scala,groovy,resources}) which has carried on to other build system. I didn't like that at first too, but I've since come around.

SBT does a lot of things really nicely if you're in the Scala world. `sbt console` is wonderful. That being said, never take up the sbt source code and try to hack on it. That's a disgusting mess under there. Also the whole task dependency/macro structure can get pretty awful when you want to run tasks with multiple configurations in one go. I don't think it's possible. The sbt-native-packager works really well, but once again, that source code will make you want to throw up. At least back in like 2014 it did. Who knows. Maybe it's gotten better.

Honestly all the build systems are kinda terrible, but I'd take groovy or sbt any day over maven. I don't see how anyone likes it. Trying to figure anything out in Maven was just miserable.