16

I've started using Gradle several months ago and I sometimes bump into a problem with my build.gradle files. For example if I add something like this to my file:

apply plugin: 'kotlin'

I can't tell what that will expand to. In my case I figured out that it pulls in the java plugin as well and the java plugin itself sets up some configuration. How do I know what these statements will expand to? Do Gradle has something like an effective build.gradle ?

Clarification: what I really wish to know is what each apply plugin X statement does behind the scenes without looking up documentations etc.

Adam Arold
  • 29,285
  • 22
  • 112
  • 207
  • Define what you exactly mean by "expand to". I have soley used Gradle for many years by now and also developed many Gradle plugins myself. What is important about Gradle plugins to understand is that they are essentially just premade groovy code that gets executed by the apply statement. Gradle Plugins can pretty much do anything you can do in groovy which is what makes them so powerful. They configure the project in whatever way so you don't have to do it in your build.gradle manually. – Xaver Kapeller Dec 12 '16 at 18:52
  • For example you could take the source code of a Gradle Plugin and put it directly in your build.gradle and it would work the same way. – Xaver Kapeller Dec 12 '16 at 18:52
  • In contrast to maven Gradle is not so much about listing and configuring settings and plugins, but much like Grunt or Gulp (I don't know if you are familiar with these Javascript build systems) you write code which gets executed at compile time to build your project. I am not that familiar with Kotlin, but is it possible that Kotlin code compiles to Java jar files? In that case the Java Plugin is applied so that the Kotlin Plugin can use it generate Java byte code. It would add additional tasks before the Java compile task to prepare the Kotlin code in a way the Java Plugin can understand. – Xaver Kapeller Dec 12 '16 at 18:58
  • A similar thing happens for Groovy which is the language Gradle uses itself. The Groovy code is preprocessed and turned into valid Java code which the Java Plugin than compiles. – Xaver Kapeller Dec 12 '16 at 19:00
  • I guess "expand to" in this case simply means the transitive dependencies of the plugin. – sschuberth Dec 12 '16 at 20:17
  • With *expand to* here I tried to give name to the process of discovering what `apply`ing a plugin does without looking up its source code. This is the equivalent of the effective pom in Maven when I can see what will be the result of flattening the pom hierarchy. I used the term *expand to* because this resembles to macroexpansion in lisp languages. – Adam Arold Dec 13 '16 at 00:43
  • @AdamArold That's the thing, Your gradle scripts and gradle plugins are just compiled source code. That is what I was trying to allude to with my comparison to Grunt or Gulp. There are a few predefined things like tasks, dependencies etc - and these are all things you can inspect - but the rest is just compiled source code. A plugin could do anything from creating a file and writing something into it, to reading all the source code and counting the empty lines. If you want to know what a plugin does, you have to look at the documentation. – Xaver Kapeller Dec 13 '16 at 03:29
  • I am not familiar with the JS ecosystem so I don't know the aforementioned tools (apart from knowing their names). Is there some easy way to see the source code of these plugins without digging into - possibly non-existent - documentations? – Adam Arold Dec 13 '16 at 09:21
  • If a gradle plugin lacks documentation, it isn't worth using. Choosing a plugin for your build is a major project decision with far-reaching consequences, so you need to be damn sure of what it does and how to use it. Most plugin developers are cognizant of this, so a google search will generally get you your docs. – Brandon McKenzie Dec 13 '16 at 19:55

4 Answers4

4

Try gradle dependencies. The output is similar to Maven's mvn dependency:tree.

See docs here: https://docs.gradle.org/current/userguide/inspecting_dependencies.html#example_rendering_the_dependency_report_for_a_custom_configuration

David Good
  • 486
  • 5
  • 8
3

Since Gradle 2.10 you could try using gradle buildEnvironment. Also see this answer, this blog article, or the official docs.

Community
  • 1
  • 1
sschuberth
  • 28,386
  • 6
  • 101
  • 146
1

You could probably list the plugins with a custom task

task pluginReport {
    doLast {
        allprojects.each { Project p ->
            PluginContainer plugins = p.plugins
            println "Project: ${p.name} has ${plugins.size()} plugins
            plugins.each { Plugin plugin ->
                println "   - ${plugin.class.name}"
            }
        }
    }
}
lance-java
  • 25,497
  • 4
  • 59
  • 101
0

Gradle plugins, while they can exist in the form of gradle scripts, a great many of them are binary plugins: java code that happens to be executed by the jvm at build time. This means that "build.gradle" is the effective build.gradle, unless you really want to go looking at bytecode/plugin source code.

The best way to know what a plugin is bringing into your project is to read the documentation, or if insufficient documentation exists, try to reach out to the Kotlin devs/a Kotlin specific support forum.

Edit in response to clarification: No, there is no way know what a plugin is doing without looking at documentation; plugins are frequently Groovy/Java programs that run with your build. It'd be like asking your computer to surmise what "xyz.exe" does without googling or running it.

Choosing gradle plugins is a very big and deliberate choice for your build procedure, and it needs to be done carefully and with consideration for what functionality they bring and what settings to use for each plugin to ensure your build delivers to results you need. Even if we had SciFi computers that could magically say what a random binary does in plain English, you'd be better served by doing your legwork, reading the docs, and figuring out what your plugins do and how to actually use your plugins effectively anyway.

Brandon McKenzie
  • 1,655
  • 11
  • 26
  • Kotlin was just an example. I don't know what the java plugin does either. – Adam Arold Dec 13 '16 at 00:43
  • Which takes me to my second paragraph: the Java plugin documentation lives [here](https://docs.gradle.org/current/userguide/java_plugin.html) if you need details, to summarize it effectively adds a bunch of java lifecycle tasks (and under the hood, everything, script or binary, needed for those tasks to function). – Brandon McKenzie Dec 13 '16 at 15:10