Apply from gotchas

Help/Discuss
1

Refactoring of large gralde.kts file such as

plugins {
    id("java")
    id("info.solidsoft.pitest") version ("1.9.11")
}

group = "com.tejasoft.dsa.bbraces"
version = "2.3.9-SNAPSHOT"

repositories {
    mavenCentral()
}

pitest {
    junit5PluginVersion.set("1.2.0")
    mutators.addAll("ALL")
    outputFormats.addAll("HTML")
    targetClasses.addAll("com.tejasoft.**")

    //targetTests.addAll("com.tejasoft.dsa.bbraces.test.TestBBRandom","com.tejasoft.dsa.bbraces.test.TestBBOrdered")
    verbose.set(true)
}

dependencies {
    implementation("com.groupcdg:pitest-annotations:1.0.11")
    implementation("org.pitest:pitest:1.14.1")
}

to two files one the main build.gradel.kts and other pitest.gradle.kts

plugins {
    id("java")
}

group = "com.tejasoft.dsa.bbraces"
version = "2.3.9-SNAPSHOT"

repositories {
    mavenCentral()
}

apply {
    from("pitest.gradle.kts")
}

and

plugins {
    id("info.solidsoft.pitest") version ("1.9.11")
}

pitest {
    junit5PluginVersion.set("1.2.0")
    mutators.addAll("ALL")
    outputFormats.addAll("HTML")
    targetClasses.addAll("com.tejasoft.**")
    //targetTests.addAll("com.tejasoft.dsa.bbraces.test.TestBBRandom","com.tejasoft.dsa.bbraces.test.TestBBOrdered")
    verbose.set(true)
}

dependencies {
    implementation("com.groupcdg:pitest-annotations:1.0.11")
    implementation("org.pitest:pitest:1.14.1")
}

not working… I tried with this too

apply(plugin = "info.solidsoft.pitest")

dependencies {
    add("implementation", "com.groupcdg:pitest-annotations:1.0.11")
    add("implementation", "org.pitest:pitest:1.14.1")
}

not sure why I should it this… as it is more unfriendly… still plugin is not recognised and pitest config blog gives error…

Is it possible to move config and plugins related one to separate file and use apply from

2

Besides that

apply {
    from("pitest.gradle.kts")
}

is not the correct syntax, but should be

apply(from = "pitest.gradle.kts")

you should practically never use “apply from”.
This is legacy script plugins that have many drawbacks and quirks, especially when using Kotlin DSL.
For example you cannot use a plugins { ... } block in them, you do not get type-safe accessors generated to e.g. use pitest { ... }, there are classloader quirks with them that can easily bite you in unexpected and hard to diagnose ways, …

Instead you should use precompiled script plugins to write your convention plugins.
Those work as expected.
Those are the ones you have in a separate build you includeBuild then or that you have in buildSrc if you prefer.

3

Would the apply work well with gradle groovy DSLs

Also, I just want to partition the script code to manage it… rather than going with plugins …

something similar to ant…where

 <project>
     <import file="AntXTasks.xml"/>
     <import file="AntInst.xml"/>
 </project>

is a similar thing possible either in gradle or gradle.kts

4

Would the apply work well with gradle groovy DSLs

It still has some of the drawbacks like classloader problems.
And it is still not recommended to do it.
The recommended way are precompiled script plugins, whether you use Groovy DSL or Kotlin DSL doesn’ matter.

Precompiled script plugins are what you want.
They are looking basically the same as build scripts and do exactly what you want.

1 Like
5

Tried plugin approach, it looks like a overkill as need is not have any plugin ID etc…more so it is not a plugin that is so much reusable…

As gradle script is quite huge, I wish to put them in n number of relevant places so that the final script is included at runt time but easy to maintain as there are many script files.

Gradle should consider simple import like ant…plugin approach seem to be a overkill

6

If it seems overkill, you probably did something wrong.
Again, the precompiled script plugins are like the Ant functionality you ask about.
They are looking 98% like normal build scripts.

7

Can you pl refer me to any simple example?

Does the pre-compile plugin approach needs publishing to gradlePortal as a plugin?

8

Of course not, that would be complete non-sense.
Well, you can also publish precompiled script plugins to plugin central if you wish to.
But the main reason behind precompiled script plugins is to be able to write convention plugins for a build easily and without much ceremony / boilerplate.
You just put them into an included build that can live in the same repository for example in gradle/build-logic, or in the special buildSrc.
Did you at all have a look at the documentation?

Here the official documentation: Developing Custom Gradle Plugins

Examples are many out there, every other build uses them. Even the init task today produces builds that use convention plugins as precompiled script plugins in an included build.

If you like video tutorials, this one gives a nice introduction: Understanding Gradle #03 – Plugins - YouTube

1 Like