Live data from Hacker News

Why I Moved Back from Gradle to Maven

blog.philipphauer.de

171–172 of 172 posts

Re: Why I Moved Back from Gradle to Maven

#171
post #162

Earlier quoted context omitted.

Both Maven and Gradle have plugins that will generate Eclipse and IntelliJ project files. But also, both Maven and Gradle work by first building up a model of what the build will look like, then executing it. Gradle is complicated by the fact that it's much easier to run custom code that modifies the build during the build (which is why I don't like it so much), but IDEs can still inspect the build model to work out…

> Both Maven and Gradle have plugins that will generate Eclipse and IntelliJ project files. So does this work as I suggested? Can you do whatever you want in you're build script and output something usable for eclipse? > But also, both Maven and Gradle work by first building up a model of what the build will look like, then executing it Isn't that pretty much what make has always done? You define outputs and what dep…

Make works on a files in -> one file out basis, and the IDE has no visibility of any other side-effects. That works for build systems with that property, but some of the interesting bits of builds touch multiple files. It's also why I like Make and Maven and don't think Bash and Ant make suitable build tools.

Maven and Gradle plugins also have the advantage that the IDE can be taught to understand what they do -- a Makefile can run a compiler, but the IDE can decide to use incremental compilation and update a debug target on-the-fly, as it can see what the project build is doing and replicate the results.

On the subject of generating project files, pretty much everyone I know prefers to use the IDE's tooling for importing build files rather than the build tool's tooling for generating IDE files. And that's probably a self-reinforcing behaviour as far as tooling quality goes.

Re: Why I Moved Back from Gradle to Maven

#172
post #91

Earlier quoted context omitted.

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…

IDE does not try to analyze Gradle scripts directly, it works with declarative model that is created by executing Gradle scripts. Gradle works in two stages: 1. Configuration: scripts execute and produce software model (DAG of tasks essentially). 2. Execution of necessary tasks in the graph.

IDE cannot get the graph by analyzing scripts, but it does not need to: instead it can ask Gradle for the model. The model itself has nothing to do with Turing completeness.

Post reply on HN