Alternative to Gradle DSL..?

Since when are experiments counterproductive?

I am developing software for nearly 20 years and I seldom saw more clueless users of a tool in forums (as is the case with gradle). Judging from my own experience people have wasted centuries diddling with gradle script until it worked (or they gave up). Just read forums like this one, stackoverflow, etc.

The only sane advice for beginners is to skip the docu and directly dive into understanding Groovy code and looking at the Gradle sources.

I absolutely believe the makers of Gradle had good intentions with Groovy and using a super-short DSL, but you know what they say about good intentions.

The crazy thing is, once you have gone through this meat thresher of hell and your builds work you start kinda loving Gradle :wink:

1 Like

Yet it is absolutely necessary to give a use case when asking for a feature. If you can’t provide a reason why the single-line workaround doesn’t work for you, then I can’t help you.

Even if you developed your own Java-based version of the script language extension point, it just wouldn’t work. IDEs don’t support scripting in Java. The IDE wouldn’t know what classpath that Java file should have. That’s what Kotlin solves, by providing first class scripting support in IntelliJ and Eclipse.

That’s really not how it works. Once you understand that the Project object is implicit (eg project.dependencies { ... } is equivalent to dependencies { ... } you can just use the javadoc to figure it out yourself.

In my opinion this is a breath of fresh air coming from Maven where I relied on random snippets of xml from stack overflow rather than working it out myself

:smile:

You can’t or you won’t :wink:
Well, maybe Gradle is badly designed (surprise!) where the scripting part invades the actual program logic like cancer. Instantiating Settings and Project and populating them via setters should be possible if separation is done well and testing has priority.

But well, I bite. The most simple to explain use case: direct execution and debugging of “straight-Java” without the scripting hook.

You had me at ‘first class’…you lost me at ‘scripting’ and 'Eclipse :wink:
I am holding my breath when it comes to Eclipse and Gradle/Kotlin. Is there even syntax highlighting with Buildship and Gradle build files by now? Last time I checked Eclipse treated my build.gradle like a text file.

And while we are at it: why Kotlin? Maybe finally the last person started to realize what massive mistake it was to use Groovy? Even worse, they used the ugliest flavor of Groovy with all kinds of crazy hidden implicit magic voodoo crap that confuses the hell out of users for the sake of shortening your build script by 1-2 less characters.

Gradle/Groovy violates about everything decent people hold dear. It constantly fights the way about 99% of developers out there think and operate.

Exactly. Everything is implicit. Everything is magic. You are looking at a black box.

Speaking about debuging (which is a good use-case), I feel like brushing up this old presentation (or if you are in a hurry just go straight to the happy ending.)

To which I say remote debugging is more cumbersome, more error-prone and in effect you just do it less often. They whole development cycle is disturbed and you never get in “the zone” to focus on your code - instead there all these little breaks where you waste time to set up something like remote debugging or wait every time for the config phase to finish.

With every release of Gradle I have to read that it is no x times faster then before and 100 times faster then Maven and so on. But the truth is that the config phase is still annoyingly long (I hoped doing things in Java explicitly would reduce this to zero). This was also the impression I got with other parts of Gradle. For example the application plugin. Why does it insist to build all artifacts (e.g. jars) before executing code? This takes 10-20 secs in a complex multi-project. It just needs to recompile a single class! My hacked solution using Gradle script/plugin (very painful to achieve this) now executes without any delay by bypassing the application plugin’s way to do it.

And debugging was just an example. There are huge parts in the legacy build that just naturally fit or enforce Java and the script approach makes it somewhere from inconvenient, to unflexible, to impossible without rewriting huge chunks of code.

I was hoping for example to skip the config phase because I set up everything explicitly in pure Java. For some projects this extra effort would really pay off. But maybe I am too naive and separation in Gradle is like separating butter, eggs and flower after you baked the cake.

What good separation would look like: a set of dumb state objects (e.g. POJOs with getters and setters but WITHOUT any logic) that can be set up and populated by settings.gradle & build.gradle OR by any other way including unmarshalling serialized state from a database or state-objects set up in “straight Java”. Then you take this state and hand it over to ANOTHER separate part of Gradle that knows how to execute a build based solely on this state and doesn’t know or care how the state was created.

From your replies it seems this is not already possible and I get the feeling many parts that should be separate are actually baked together and it has the smell of bad code.

This discussion would have not been necessary if proper separation was in place. There should be at least the following separate parts: 1. state (a.k.a. dumb config data objects), 2. setting up the state, 3. scripting (as ONE way to set up the state), 4. building (using ONLY the state).
I left out some optional parts like state-verification but you get the gist I hope.

Either it is easily possible to set up a dumb state in “straight-Java” and also execute it or Gradle has huge conceptual problems that have everything to do with code separation. My problems and struggle with Gradle are just a symptom.

I’m closing this topic because this discussion is completely unproductive. Insulting our work in every post doesn’t help either.

You made it clear that your build is facing some issues and I would love to discuss solutions to those. Feel free to open topics that address these actual issues like “slow config time” or “trouble with application plugin”. Please choose your tone more carefully in those.

Below are a few pointers to get you started and to give others an idea why discussing the script language is not useful in these scenarios:

The only way to get a long configuration phase is to do expensive things in this phase, like file or network IO. Otherwise even a 500 module project will take <1s to configure. Writing that expensive code in Java won’t fix it. You need to find and remove that expensive code.

It’ll build only what’s necessary and it will only rebuild something if it’s out of date. If that doesn’t happen, then you’ve broken incremental builds somewhere, e.g. by introducing a timestamp as an input. Instead of building your own version of the application plugin, it would have been more productive to ask on the forum right away about that problem. This is not solved by moving everything to Java, but by fixing your task’s inputs.

3 Likes