Alternative to Gradle DSL..?

Help/Discuss
1

Hi,

I know Gradle/Groovy quite well after a painful learning curve. There is sadly no substitute to learning Groovy inside out and looking at the Gradle code. The documentation is not enough if you want more then a black box, stupidly learning by heart and copy pasting snippets you never touch once they work from Stackoverflow.

By now I am one of the few people who likes to high-five himself for how well he knows Gradle, although I still feel the calluses. It shouldn’t be this way :frowning:

I wonder if there is an alternative to the normal way one writes Gradle scripts? I wouldn’t mind something very verbose as long as it is more intuitive than the status quo.

For example: could one write “scripts” in Java and execute them directly or convert them to the Gradle DSL? Basically the Gradle build is just a bunch of Objects that need to be configured and in principle I am not forced to use the Gradle DSL to do that.

Any alternatives?

1 Like
2

I think there are several aspects contributing to this problem:

  • no IDE support
  • too little documentation on best practices
  • some unnecessary flexibility

The first one will be fixed by the Gradle Kotlin DSL. We are also actively improving our documentation, e.g. with the new Gradle Guides. Last but not least, we will make Gradle stricter in a few corners to give earlier feedback on misconfiguration.

3

Please allow people to directly write their build scripts in Java. If something is not working as I like I can dig down in the source code, use the debugger and has Class-A IDE support out of the box. Most syntax errors and typos are catched by the compiler for free.

Is there a technical reason why one could not use Java? Please write a minimal tutorial for a simple build written in 100% Java. I think once we can play around with it we can decide on our own if it has more or less merit then a DSL.

Or are you afraid that people could like using Java?

1 Like
4

The same is true for Kotlin and (with some constraints) Groovy.

You always write against the same API, no matter if Java, Groovy or Kotlin. The difference is just that Groovy and Kotlin provide more syntax sugar, so it actually looks concise. No one will stop you from writing Java-style code in your build scripts, e.g. project.getDependencies().add(configurations.getByName("compile"), "com.google.guava:guava:21.0")

Also, when you are at the point where you want to debug your build scripts, then they are too complex. In that case I highly recommend writing a plugin in the buildSrc directory instead. You can write that in any JVM language you want, including Java of course.

No, most people would hate it - just look at how much code adding a dependency would take above. Plus, IDEs don’t support scripting with Java.

Even the few people who’d like it would be worse off, because all the samples would look so different from what they are doing. They’d have a hard time getting help.

5

I guess you could write down a dummy multi-project build in Java in a few minutes. Maybe with the build-files seperate from the multi-project. Could you do that and push it on Github or something?

6

Not that I recommend it, but you can write a single line of groovy and the rest as Java if you like

build.gradle

apply plugin: foo.MyJavaGradlePlugin

buildSrc/src/main/java/foo/MyJavaGradlePlugin.java

package foo
import org.gradle.api.*;
public class MyJavaGradlePlugin implements Plugin<Project> {
   public void apply(Project project) {
      // code goes here
      project.getDependencies().add(project.getConfigurations().getByName("compile"), "com.google.guava:guava:21.0")
   }
}

I think you’ll find the equivalent java code to be verbose and hard to read / maintain and not worth the effort

2 Likes
7

I would also like to tinker with a Gradle build written fully in Java. The foo.MyJavaGradlePluginNot is neat but I think the OT meant something entirely different. The Github project suggestion is a great idea. The code snippets you posted @st_oehme is far too trivial. What is necessary is a project with nested subprojects, a few real dependencies both for deploy, debug and testing, copying of resources, execution, etc. - ALL the most basic and most frequent Gradle parts used in building multiproject Java software.
Thousands of real world Java-Gradle projects exist on Github to choose from. I think you (@st_oehme) are in the unique position to transform such a Gradle build file into pure Java using the Gradle API in under an hour while using the API correctly. But please not the suggested plugin solution. The OT was talking - and I think rightfully so - about a standalone Java project that instantiates Project, Settings, etc. and configures those objects and then triggers the build.

I would do it myself but it would take me a days or weeks and I probably wouldn’t know if I used everything correctly. I don’t know the API very well - only Gradle script so far.

Please @st_oehme do this. I think there are many people out there who would love to experiment with pure Java Gradle builds but lack a good stating point.

8

There is no bootstrapper for gradle builds written in java. Lance’s suggestion gives you everything you wanted - ide support, debugging, etc. That plugin is essentially your gradle build, with a but of boilerplate (and yes, syntactically valid java requires boilerplate)

One curious tidbit, if I recall correctly, the gradle build scripts are in fact plugins - just the bootstrapper applies them to the right domain object without you having to type the apply() command.

9

You are already using the Gradle API. Every script is nothing more than a plugin that executes against the Project API. You can go as verbose as you want, the Groovy compiler will accept plain Java syntax.

There aren’t, we get about 2 people per year asking for this, out of millions of users. If you want to experiment with Java scripting, go ahead. But I won’t spend my time on that.

10

I think - after some years of occasionally hard experiences - this is the real point where Gradle suffers. Starting with Gradle is quite easy and very understandable with the help of the Gradle User guide. But then, if your job is to do something variant, deviating, the real problems bubble up.

Excact, this is what I am missing. If one has a hard problem to solve, until to day you have nothing else then searching in the community. Mostly you will find a solution, at least nice hints. The API docs, well, I myself find it somewhat hard to understand. (BTW: the given link to Guides only gives an empty page.)

One thing, in Gradle User Guide, I find very confusing, is the examples used for explaining the new Model DSL. Why, the hell, do you try to explain it with “Person” classes instead of classes from the build domain?!

So, this said, I do not believe Java written scripts won’t help; they would only lead to noisy code

1 Like
11

We’ll fix the reference manual and use better examples.

It links to the new Gradle guides (getting started and in depth best practices guides). The link works for me. Can you try again?

12

Clicking on the link gives: https://discuss.gradle.org/clicks/track?url=https%3A%2F%2Fguides.gradle.org%2F%3F_ga%3D2.246305542.385279496.1498851776-763055185.1462908134&post_id=66813&topic_id=23144

this works: https://gradle.org/guides/

13

No doubt the Groovy compiler will. But I want to be as far away from Groovy as possible. I want standalone debuggable Java code which does not need some build.gradle bootstrap. Is it technically impossible to do that? I always assumed the settings.gradle and build.gradle are just there to ‘populate’ Java objects. Is it impossible to create all those objects in Java code and populate them in Java code?

14

The closest you can get is what @Lance suggested. It’s a single line of Groovy and the whole rest can be in Java. I highly discourage this as the declarative bits of your build will get lost in the noise. But if that’s what you want, nobody will stop you :wink:

15

Thanks for the info. That means it is impossible to build it entirely in Java. I hoped the script-handling side of the code would be separated better from the actual functionality. Seems not. Sadly I need 100% Java and the single-line-of-Groovy workaround won’t do.

16

Just give it a quick attempt with the single line of groovy and the rest in java. I’m sure you’ll soon realise that it’s a bad idea for even the simplest of build scripts. The resultant java code will be verbose and much harder to understand compared to the equivalent groovy script

I suggest you try the kotlin dsl and / or use intellij idea instead of eclipse for better ide support of build scripts

1 Like
17

Hi Karsten,

As you appear a bit annoyed by everybody trying to steer you away from the wall you are headed into, I’ll answer your questions directly:

You want to write your builds in “straight Java” - I assume then that you want a class with main method you can execute. This way you also you cut therough the shell cr@p and retain control over the classpath and all options that the JVM exposes to you.

Gradle can be bootstrapped by using GradleConnector.connect(). Then you would use model(class) to lookup the Gradle, Settings and Project domain objects which all have well documented API entirely at your disposal.

Despite the Javadoc quality being above average and the User Guide explaining the concepts, as in any larger project you will probably need to look around at usages to fully grasp how to do things. I assume you are well versed in your IDE of choice, so this should be no problem.

Feel free to ask in this forum, but a word of caution - the people that may be able to help you are far and few in between.

Good luck!

19

@ddimitrov GradleConnector is the entry point to the Tooling API which allows you to execute a build and get information from it. It does not allow you to write a build (which is what the OP asked for). You don’t get access to Project/Settings/Gradle through the Tooling API. Only Gradle plugins/build scrips can access those objects.

20

Obviously it is more verbose. But verbosity is not a quality metric of good code. Actually it often goes against quality and understandability. Even without knowing the constraints of my use case the arguments against “straight-Java” I heard so far are very weak.

Thank you. Yes! Actually it goes even beyond that and is dictated by the build process of a huge legacy project. Why it has to be “straight Java” and why the script workaround-hack is no alternative has many reasons and would fill about a dozen pages of text.

Thank you! I will look into it asap. I don’t mind going spelunking in the bowels of the Gradle code base. Still I always have a bad feeling when I only “hear my own echo” in a cave and don’t know if I am going the optimal route. That’s the annoying part. Many Gradle-ninjas (who probably wrote most of the code) are in this thread and could supply a best use-case mini-project in less time it took so far to discourage me using “straight-Java” :wink:

We don’t know if people would use it before we have at least a non-trivial multi-project example in “straight-Java” on Github people can start tinkering with. Most trivial problems I faced with Gradle scripts took hours to solve or not at all and would have taken minutes with proper IDE support and the Java debugger instead of tedious guessing, googeling and stupid println-debugging.

The consensus in most Gradle problem replies you find in the web is that people use it wrong if they want to do something a little more complicated. This can be something as simple as non-trivial copying of resources or executing an application where you have to establish the classpath on your own.
Most huge legacy projects are very very complicated to build and don’t care about the way Gradle does things. Heck, they were often created before Gradle was even born. Yes, if I need to setup a brand new project I just adhere to some rules and have no beef with Gradle.

Please Gadle-makers, set up some Github non-trivial multiproject example that uses all the standard Gradle features to build a project in “straight Java” using something like GradleConnector.connect() etc.

I think you will be very surprised how many people would like to tinker with such an solution. Or does this endanger selling the KotlinDSL?

21

My bad, I was trying to be helpful with the limited knowledge I had.

Could you point Karsten to the code that instantiates the project and applies the build script? This way he would know where to hook his stuff. Even if it is completely counterproductive, it would be a datapoint that may come useful.