I have very simple structure of project that uses Spring-boot. It is web application that uses some lib that uses jdbc.
So my root setting.gradle is following:
include ':app:myWeb', 'components:myBackend'
application's standalone build.gradle compiles reusable lib with:
...
compile(project(":components:myBackend"))
...
But during compilation of myBackend I can get 2 types of errors:
1) no main class (but remember it is a lib), so I can fix it by turning off apply plugin: 'spring-boot'
2) Or error is following:
Could not resolve all dependencies for configuration ':components:myBackend:compile'
Could not resolve org.springframework:spring-jdbc:. Required by:SBSServer.components:myBackend:unspecified
So my question is: how to create reusable library that uses spring-jdbc?
The text of myBackend build.gradle is there http://codepad.org/Xg3Kys73
Instead if removing the spring-boot plugin completely you probably just need to switch off the repackage task:
bootRepackage {
enabled = false
}
Related
I'm using Gradle 6.6 to build my Spring Boot app. According to this post, the io.spring.dependency-management plugin is no longer needed since Gradle 5+ supports BOM files.
However, I receive the following error if I remove the plugin:
Could not run phased build action using connection to Gradle distribution 'https://services.gradle.org/distributions/gradle-6.6.1-bin.zip'.
Build file 'C:\my-app\build.gradle' line: 14
A problem occurred evaluating root project 'my-app'.
Could not find method dependencyManagement() for arguments [build_6e8ejdhnd2no2m9jw221sctmn3$_run_closure2#432e46e2] on root project 'my-app' of type org.gradle.api.Project.
Line 14 of my build.gradle file is referenced in the above error. Here are lines 14-18:
dependencyManagement {
imports {
mavenBom "org.springframework.cloud:spring-cloud-dependencies:Hoxton.SR8"
}
}
Is there another way to specify the required dependencies for Spring Cloud without using io.spring.dependency-management plugin?
dependencyManagement() is provided exclusively by the io.spring.dependency-management plugin. Which means you cannot use it if you don't use the plugin.
And in that case you have to use the gradle's platform capability.
In the post you linked there's an example of that.
To fix your build, remove the dependencyManagement part and add
implementation platform("org.springframework.cloud:spring-cloud-dependencies:Hoxton.SR8")
to your dependencies { }
Reference: https://docs.spring.io/dependency-management-plugin/docs/current/reference/html/#dependency-management-configuration-dsl
We have a Gradle project with a bunch of modules. One of those modules is a custom code generator, written as a Gradle plugin. We want to run that code-generator plugin in another module later in the same overall multi-module build, in order to test the code generator.
We know how to create a separate project on the fly and run the code generator in that, but we need to run the code generator in the main project, not in a temporary test project.
Nothing we have tried works, and the Gradle documentation doesn't appear to address this. It seems to be fundamental to Gradle's design, because the entire set of plugins used in a build is basically a single program, assembled at the start. Trying to add a just-now-built plugin after the fact seems unsupported, or we're missing something.
The best we've been able to come up with so far is to implement the plugin in Java (Kotlin would also have worked), so the Gradle plugin is just a thin Gradle skin over the implementation, and call the Java implementation directly when running the code generator in the other module. This works, but it means we aren't actually testing the Gradle portion of the code generator.
This is natively supported in Maven (maven multi-module project with one plugin module, and https://maven.apache.org/guides/mini/guide-multiple-modules.html), which is not surprising because every plugin in Maven runs in a separate class loader. If it's not possible in Gradle, that would be one of the few cases where Gradle doesn't have feature parity.
A hacky way to do this is to run the newly-compiled plugin via Gradle's test kit runner.
A cleaner way to do this is to write plugins as thin shells of code written to Gradle's API that delegate the real work to plain old Java (or Kotlin) utility methods. This has a number of advantages:
You can unit test the utility methods.
You can use the utility methods for other purposes unrelated to the plugin.
You can call the utility methods directly from other modules in the project, thereby accomplishing what the plugin would have done if you could have built it and then called it in the same build.
To expand on the above answer.
Instead of calling the plugin like a plugin, add a main method that accepts the same parameters that Gradle plugin configuration passed to the plugin.
Then call the plugin's main using Gradle's Java exec task:
task(generateFoo, type: JavaExec) {
main = 'com.bar.Foo'
classpath = configurations.runtimeClasspath
args = ["arg1", "${projectDir}/src/generated/java"]
}
Note the args: those are the same pieces of information that used to be passed in via Gradle configuration:
apply plugin: 'foo-plugin'
generateFoo {
theArg "arg1"
outputDir "${projectDir}/src/generated/java"
}
Because the runtime classpath used by Java exec is the one for the calling module, you may encounter runtime classloader problems.
If that happens, it's easily fixed. Just change the rewritten plugin to a fat jar:
task fatJar(type: Jar) {
manifest {
attributes 'Implementation-Title': 'Foo Fat JAR', 'Main-Class': 'com.bar.Foo'
}
baseName = project.name + '-exec'
from { configurations.runtimeClasspath.collect { it.isDirectory() ? it : zipTree(it) } }
with jar
}
artifacts {
archives fatJar
}
And then execute the fat jar with Java exec:
def fooGenerate = task(generateFoo, type: JavaExec) {
main = 'com.bar.Foo'
classpath = files("${projectDir}/../foo-plugin-module/build/libs/foo-plugin-module-exec.jar")
args = ["arg1", "${projectDir}/src/generated/java"]
}
Finally, make the dependent module's compile task depend on the code generation:
compileJava.mustRunAfter fooGenerate
If you use the fatJar approach, you don't even need to declare implementation project(":foo") in the dependent modules.
It might be also be possible to use Gradle's composite builds for this (https://docs.gradle.org/current/userguide/composite_builds.html).
I have created a custom Kotlin compiler plugin for Gradle. It was inspired by kotlin-allopen (2) and sample-kotlin-compiler-plugin, and is supposed to make all Kotlin classes non-final.
The problem is, I'm unable to use it in my projects, I only get the following:
Caused by: org.gradle.api.plugins.UnknownPluginException: Plugin with id 'no.synth.kotlin.plugins.kotlin-really-allopen' not found.
at org.gradle.api.internal.plugins.DefaultPluginManager.apply(DefaultPluginManager.java:131)
I have tried both the "new" plugin syntax:
plugins {
id "no.synth.kotlin.plugins.kotlin-really-allopen" version "0.1"
}
.. and the old one:
buildscript {
repositories {
mavenLocal()
}
dependencies {
classpath "no.synth.kotlin.plugins:kotlin-really-allopen:0.1"
}
}
apply plugin: "kotlin-really-allopen" // I've tried "no.synth.kotlin.plugins.kotlin-really-allopen" as well
So what am I doing wrong? Here's the plugin: https://github.com/henrik242/kotlin-really-allopen
EDIT: I have updated the repository with an example app and a README.md to easily reproduce the problem.
Your Gradle plugin doesn't seem to contain any entry under META-INF/gradle-plugins.
Gradle requires that every plugin ID is mapped to the implementation class, and this mapping is stored in META-INF/gradle-plugins resources.
To map the plugin ID kotlin-really-allopen, you would need a resource file
src/main/resources/META-INF/gradle-plugins/kotlin-really-allopen.properties.
See: Wiring for a custom plugin
You can also use the Gradle Plugin Development Plugin, which automatically generates these entries from the build script DSL.
Also, your repository doesn't seem to contain an actual Gradle plugin implementation, there's only the part that the compiler needs to load. For an example that contains the Gradle part too, take a look at kevinmost/debuglog.
Move apply plugin: "kotlin-really-allopen" in your build.gradle module app on top
I have a gradle 4.1 multiproject containing a "projectA" containing 2 subfolders "api" and "implementation".
The multiproject uses kotlin and java-library plugins defined in the subprojects section of the main build.gradle.
The implementation project avec a API dependency to :projectA:api
In the api folder I have kotlin and java files inside 'src/main/java' and in the implementation project I'm creating a new instance of a kotlin class from the API.
Inside Intellij Idea, I don't have any compilation errors ; but when I compile the whole project using gradle I have an error: cannot find symbol. It is as if the compileJava doesn't have access to the folder kotlin-classes.
Inside the build/kotlin-classes, I see my file.class
The class file is on build/classes dir also
Details of the error :
Task :projectA:api:compileKotlin
Using kotlin incremental compilation
Task :projectA:implementation:compileJava
(...) error: cannot find symbol (the import fails)
Update 1 : removing java-library solved my problem
This is a known issue of the java-library plugin: when used in a project with another JVM language (Kotlin, Scala, Groovy etc.) , it does not register the classes of the other language so that the dependent projects get them as they consume the classes.
Fortunately, it has a workaround as well. Adapted to Kotlin, it would look like:
configurations {
apiElements {
outgoing.variants.getByName('classes').artifact(
file: compileKotlin.destinationDir,
type: ArtifactTypeDefinition.JVM_CLASS_DIRECTORY,
builtBy: compileKotlin)
}
}
If you use Kapt1, it's file: compileKotlinAfterJava.destinationDir, and for Gradle versions lower than 4.0 use builtBy: copyMainKotlinClasses instead.
This issue is also tracked in the Kotlin issue tracker: KT-18497, follow that issue to see when it's fixed on the Kotlin Gradle plugin side, so that the above workaround will be no more necessary.
Is it possible to make one custom plugin in Grails 3 dependent on another custom plugin? Here's my project structure:
grails3-home
myApp
customPlugin1
build.gradle
settings.gradle
customPlugin2 ...
I would like to make customPlugin1 dependent on customPlugin2. Everything I've read says this possible with multi-project builds between apps and plugins in Grails 3. And I'm able to declare both plugins as dependencies in myApp with no issues. However, I have not been successful in getting this to work between the two plugins.
I have added the following line to customPlugin1 > settings.gradle
include "customPlugin2"
And to customPlugin1 > build.gradle
grails {
plugins {
compile project(':customPlugin2')
}
}
However when I try to build customPlugin1, I get the following error:
FAILURE: Build failed with an exception.
What went wrong:
A problem occurred configuring root project 'customPlugin1'.
Could not resolve all dependencies for configuration ':runtime'.
Project : declares a dependency from configuration 'compile' to configuration 'default' which is not declared in the descriptor for project :customPlugin2.
Is anyone aware if what I'm trying to do is possible, and if so, what I might be missing?
Update:
If I change my configuration to
include "../customPlugin2"
and
grails {
plugins {
compile project(':../customPlugin2')
}
}
the plugin builds successfully, but I am no longer able to import domains classes from customPlugin2 into customPlugin1 domains classes
You should do the include in the root settings.gradle
include 'myApp', 'customPlugin1', 'customPlugin2'
Then in plugin 1:
grails {
plugins {
compile project(':customPlugin2')
}
}
Note that this simply defines a dependency. If you need plugin 2 to load before or after plugin 1 you need to define that as well in the plugin descriptor.