The actual difference between apply from: and apply plugin: is that the former is to be used for script plugins given a path to the local file system or a URL to a remote location, and the latter is used for binary plugins using the plugin id. You can read more about it in Gradle … Read more
I stopped all gradle daemons by running ./gradlew –stop and the error was resolved for me.
The task foo variation of the task declaration syntax is special in that it’s implemented using a Groovy compiler plugin. As far as I know, this is the only case where a compiler plugin is used to support a special syntax.
I had a closer look at your build.gradle and it seems that paths are a little bit off. You specify source as src/model, yet your project structure and Java source suggest that model is your package name, which means the source declaration should be: main { java { srcDir ‘src’ } } Same for tests: … Read more
There’s an issue in the Kotlin Gradle DSL that causes this. https://github.com/gradle/kotlin-dsl-samples/issues/1368 You will need to use the following workaround until it gets resolved. tasks.withType<org.jetbrains.kotlin.gradle.tasks.KotlinCompile> { kotlinOptions { jvmTarget = “1.8” } }
(*) – dependencies omitted (listed previously) Should be displayed under your dependency tree. The dependencies of the marked dependency are omitted for readability because they were already listed higher up in the dependency graph output. Also, (c) – dependency constraint (n) – Not resolved
The problem was that when I added the various bits to the sibling project that meant I had two projects defining the buildscript {} section. buildscript { … dependencies { classpath group:’org.jfrog.buildinfo’, name: ‘build-info-extractor-gradle’, version: ‘3.0.1’ } } Apparently that caused two different versions of the dependency to exist in the classpath, hence the error. … Read more
I would simply put the following in TopProject/settings.gradle: include ‘Project1:SubProject1’ include ‘Project1:SubProject2’ include ‘Project2:SubProject1’ … The only change required to the projects you currently have is to remove settings.gradle files from them as you can only have one setting.gradle file per project structure.
It’s all documented well, please have a look here. Especially: When you use the “must run after” ordering rule you specify that taskB must always run after taskA, whenever both taskA and taskB will be run. This is expressed as taskB.mustRunAfter(taskA). The “should run after” ordering rule is similar but less strict as it will … Read more
Hi all this is how I ended up archiving what I needed and hopefully will be useful for the rest of you. First off I would like to thanks “pczeus” and “Björn Kautler” for their answers which helped me get to this solution. So, this is how I solved my problem: Given this build.gradle: apply … Read more