I am trying to publish a Spring Boot JAR from a subproject, but it fails due to what seems to be eager instantiation within the Gradle Maven Publishing plugin. Here is what I am trying to do:
plugins {
id 'maven-publish'
}
publishing {
publications {
publishSpringBootJar(MavenPublication) {
artifact project(':application').tasks.getByName('bootJar')
}
}
While application is a Spring Boot subproject that has the Spring Boot plugins applies as usual and DOES define a bootJar task when invoked directly. When I invoke the publish task from the parent project I get:
Task with name 'bootJar' not found in project ':application'.
It seems like the Maven publish plugin tries to eagerly insantiate the publication structure without loading tasks within the individual subprojects. What can I do in this case? Could I indirectly reference the Sprint Boot JAR as an artifact without referring directly to the task that generates it and add a publish.dependsOn ':application:bootJar' dependency to the end?
Thank you!
EDIT: The subproject application which is in a subdirectory looks like this:
plugins {
id 'org.springframework.boot' version '2.5.3'
id 'io.spring.dependency-management' version '1.0.11.RELEASE'
id 'java'
}
repositories {
mavenCentral()
}
dependencies {
...
}
Related
I know this is a common issue and I'm embarrassed to be asking it but I can't work out why I cant load the main class of my multimodule Springboot app.
Full stacktrace:
Exception in thread "main" java.lang.ClassNotFoundException: space.forloop.addon.app.Main
at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:471)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:589)
at org.springframework.boot.loader.LaunchedURLClassLoader.loadClass(LaunchedURLClassLoader.java:151)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:398)
at org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:46)
at org.springframework.boot.loader.Launcher.launch(Launcher.java:107)
at org.springframework.boot.loader.Launcher.launch(Launcher.java:58)
at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:88)
A have a root-level gradle.build file
plugins {
id 'org.springframework.boot' version '2.4.1'
id 'io.spring.dependency-management' version '1.0.10.RELEASE'
id 'java'
}
repositories {
mavenCentral()
}
bootJar {
mainClass = 'space.forloop.addon.app.Main'
}
def javaProjects = [
'addon-sync-app',
// Removed, not important
]
javaProjects.each {
name ->
project(":$name") {
apply plugin: 'org.springframework.boot'
apply plugin: 'io.spring.dependency-management'
apply plugin: 'java'
repositories {
// Removed, not important
}
dependencies {
// Removed, not important
}
}
}
In the package module addon-sync-app I have another build.gradle file which just has:
apply plugin: 'org.springframework.boot'
dependencies {
// Removed, not important
}
Looking at the documentation of Configuring the Main Class I was sure adding:
bootJar {
mainClass = 'space.forloop.addon.app.Main'
}
To the root gradle.build file was the correct thing here, but seems not. Any thing else I might have missed?
You are using the Spring Boot plugin in the wrong way. It's such a common mistake that I think they need to document it better or just make it work out-of-the-box. Oh well.
In a Gradle multi-project, you typically define your support libraries and then one or more runnable or deployable applications.
One thing I can't tell from your description is whether you intend the root project to build that final application, or if it should rather be the addon-sync-app project. Given the name, I am assuming the latter, but it can be either one (but generally not both at the same time).
When you apply the Spring Boot plugin to a project (and it doesn't matter if it is the root project or a sub-project), and you rely on defaults, it will take that project and make it into a "fat jar", which requires a special classloader to run. This makes it unsuitable as a normal library. So when you try to depend on it in a normal way, your classes will not be found.
To fix it, you should only apply the Spring Boot plugin to the project that builds the final application jar. If that is addon-sync-app, then remove it from the root and all non-application sub-projects.
If instead, you want the root project to produce the final application, you need to create dependencies to all the required sub-projects and, just as before, remove the Spring Boot plugin from them as well.
One thing you lose when not applying the Spring Boot plugin is the automatic dependency to the BOM which defines default versions of dependencies. If you like to keep using that without creating fat jars of your libraries, there are a few different ways to handle that. I wrote a (little bit too long) answer on that here.
As per gradle documentation, you can try to add 'application' plugin.
https://docs.gradle.org/current/userguide/application_plugin.html
plugins {
id 'application'
}
application {
mainClass = 'space.forloop.addon.app.Main'
}
I have three module as shown below
The fete-bird-apigateway depend on common and fete-bird-product depend on both fete-bird-apigateway and common
In the fete-bird-product settings.gradle I have included the code below
rootProject.name = "fete-bird-product"
include 'fete-bird-apigateway' , 'common'
and in the build.gradle of project
dependencies {
implementation project(':common')
}
Error
Caused by: org.gradle.internal.component.NoMatchingConfigurationSelectionException: No matching configuration of project :common was found.
I don't want to create a multi-module build project describe here https://docs.gradle.org/current/userguide/multi_project_builds.html. Each project should build individually and dependent modules should load while building.
How can I achieve this?
Well I found that I had the wrong concept for different module projects.
Assuming all modules are part of the same multi-module build then in fete-bird-apigateway.gradle and service\build.gradle you add:
plugins {
id 'java'
id 'maven-publish'
}
dependencies {
implementation project(':common')
}
However if common, fete-bird-apigateway and service are separate projects and don't share the same root build.gradle you have to publish the common module into a shared repository and use it like any regular dependency. Easiest to do with Maven Local repository.
To publish to the local maven
In fete-bird-apigateway.gradle
publishing {
publications {
maven(MavenPublication) {
groupId = 'org.gradle.sample'
artifactId = 'library'
version = '1.1'
from components.java
}
}
}
Reference - https://docs.gradle.org/current/userguide/declaring_repositories.html
https://docs.gradle.org/current/userguide/publishing_maven.html#gsc.tab=0
In the dependent project add the dependency as regular
repositories {
mavenLocal()
}
implementation("fete.bird:fete-bird-apigateway:0.1")
We need to run the task or gradle command for publish. I am using Intellj so did with below task
We can run the gradle command gradle publishToMavenLocal
We are looking to migrate from Maven to Gradle, and have worked through most of the challenges you would expect for replacing the parent POM concept. There is one sticky point that we haven't figured out yet. We need to specify the version of Spring Boot we are using globally, but I run into invalid build file problems with both of the solutions I've tried:
I tried putting the plugins { id 'org.springframework.boot' version '2.1.17.RELEASE' } declaration in the common build script. Build error, "Only Project and Settings build scripts can contain plugins {} blocks."
I tried calling the common build file to specify the springBootVersion parameter and using that in the plugins declaration. Build Error, "only buildscript {} and other plugins {} script blocks are allowed before plugins {} blocks, no other statements are allowed"
All of this would be easier if I could simply apply plugin: 'org.springframework.boot' but then Gradle can't find the plugin. All but one microservice are on a single version of Spring Boot, and we want to be able to upgrade globally if possible.
Additional Information
I have ~40 microservices plus some libraries used by those services
Separate repository for each of them, so the normal parent/child approach does not work
Maven parent POMs allowed you to publish that POM as it's own resource, and there is no 1:1 equivalent feature in Gradle
Gradle pluginManagement concept also doesn't work for us because it resolves the Spring Boot plugin but the dependency management plugin now can't be found.
My common build script is included here:
repositories {
mavenLocal()
/* Removed our internal repositories */
jcenter()
mavenCentral()
}
apply plugin: 'java'
apply plugin: 'jacoco'
apply plugin: 'maven-publish'
apply plugin: 'io.spring.dependency-management'
group = 'nedl-unified-platform'
/* Required to publish Spring Boot microservices to publish to repository */
configurations {
[apiElements, runtimeElements].each {
it.outgoing.artifacts.removeIf { it.buildDependencies.getDependencies(null).contains(jar) }
it.outgoing.artifact(bootJar)
}
}
java {
sourceCompatibility = JavaVersion.VERSION_11
targetCompatibility = JavaVersion.VERSION_11
withJavadocJar()
withSourcesJar()
}
ext {
set('springBootVersion', '2.1.17.RELEASE')
set('springCloudVersion', "Greenwich.SR6")
}
dependencyManagement {
imports {
mavenBom "org.springframework.cloud:spring-cloud-dependencies:${springCloudVersion}"
}
}
jacoco {
toolVersion = "0.8.5"
reportsDir = file("$buildDir/reports/jacoco")
}
test {
finalizedBy jacocoTestReport // report is always generated after tests run
}
jacocoTestCoverageVerification {
violationRules {
rule {
limit {
minimum = 0.2
}
}
}
}
jacocoTestReport {
dependsOn test // tests are required to run before generating the report
reports {
xml.enabled true
html.destination file("${reportsDir}/jacocoHtml")
xml.destination file("${reportsDir}/jacocoReport.xml")
}
}
tasks.withType(JavaCompile) {
options.encoding = 'UTF-8'
}
publishing {
publications {
maven(MavenPublication) {
from components.java
}
}
repositories {
/* excluded for privacy and brevity's sake, our internal Maven repo */
}
}
And that is called by our project build script that I want to parameterize:
plugins {
id 'org.springframework.boot' version springBootVersion
}
apply from: "https://mycentral.repo/project-common/develop/build.gradle"
dependencies {
implementation 'org.springframework.boot:spring-boot-starter-actuator'
implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-server'
implementation 'ch.qos.logback:logback-classic'
implementation 'javax.annotation:javax.annotation-api:1.3.2'
implementation 'javax.xml.bind:jaxb-api:2.4.0-b180830.0359'
implementation 'org.glassfish.jaxb:jaxb-runtime:2.4.0-b180830.0438'
testImplementation 'org.springframework.boot:spring-boot-starter-test'
}
version = '0.0.2-SNAPSHOT'
I think the gap here is that in maven you have the concept of a parent pom, whereas in Gradle you don't. There is no 1:1 mapping to this like you say, but you can have plugins in Gradle, and apply a plugin.
The closest thing you would have is if you developed your own Gradle plugin, which each of your projects could apply. Your custom plugin would then configure Spring Boot among whatever else is common to all your projects. This plugin would define the version of Spring Boot you want all your other projects to use.
You wouldn't get much benefit to a custom plugin if it's only concern is configuring Spring Boot, it would need to do other things as well. It can be difficult to create a Gradle plugin when you don't have allot of experience in it. You lose all the familiar syntax to the build.gradle and you literally have to write code, (there are some similarities but I have found it difficult), I would avoid it if possible.
I would suggest you start off by applying the spring boot plugin directly to one of your microservices projects, get that working, then do another. After you have done a number of them you will then be able to see what is common between them, and if it is indeed worth investing into developing a global plugin. You really need to be careful though because your global plugin has the potential to be both a blessing and curse. It may take away allot of manual work for maintainers, but if you get it wrong it will cause them grief, and then they will want to go back to maven.
I'm not sure if I understand your globally defined Spring version requirement. Unless you are using SNAPSHOT dependencies/plugins (bad don't do that), (or a black magic settings.gralde outside of your repo), you will have to put some version somewhere. As an alternative you could create your own custom task which runs on the check lifecycle which will check the version of spring (or your plugin) and print a warning if it's not the latest version, and encourage the developer to upgrade.
Extra Info
Parameterizing plugins with properties can be done putting your property in gradle.properties as springBootVersion=2.1.17.RELEASE .
I'm not sure I understood your issue perfectly but you should use the Gradle way for sharing configuration : the root project config.
Instead of including the common build script in every project, create a global project and set the configuration here.
root
|
| --- projectA
| --- projectB
| --- projectC
With the according settings.gradle
include 'projectA'
include 'projectB'
include 'projectC'
In the root build.gradle, set up the version
ext.springBootVersion = '2.1.17.RELEASE'
In subprojects using springBoot, let's say projectB, apply the plugin in the sub build.gradle
buildscript {
repositories {
jcenter()
mavenCentral()
}
dependencies {
classpath "org.springframework.boot:spring-boot-gradle-plugin:$springBootVersion"
}
}
apply plugin: 'org.springframework.boot'
This example works for me, though I may not understand all of the constraints.
If we abstract the version of Spring Boot behind a fixed URI (e.g. on an internal CI/CD server), then consider this in each project/repo's build.gradle:
buildscript {
repositories {
jcenter()
}
def SPRING_BOOT_VERSION_URI = 'http://localhost:5151/api-server/spring-boot.txt'
ext.springBootVersion = new URL(SPRING_BOOT_VERSION_URI).getText().trim()
dependencies {
classpath "org.springframework.boot:spring-boot-gradle-plugin:$springBootVersion"
}
}
apply plugin: 'org.springframework.boot'
apply from: "../common/build.gradle"
I realize the original question states that the apply plugin doesn't work, but it's not clear to me if that precludes this method.
Finally, note that it is easy to expand this beyond a simple text-file to be a more formal JSON specification (tailored to the teams' needs).
If you add this to the root project, all child projects should be able to just import from the same set of Spring Boot dependencies. The magic ingredient is the allprojects block:
buildscript {
repositories {
maven { url "https://plugins.gradle.org/m2/" }
}
dependencies {
classpath("org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}")
}
}
ext {
springBootVersion = '2.3.4.RELEASE'
}
allprojects {
apply plugin: 'java'
apply plugin: 'io.spring.dependency-management'
dependencyManagement {
imports {
mavenBom("org.springframework.boot:spring-boot-dependencies:${springBootVersion}")
}
}
}
apply plugin: 'org.springframework.boot'
I am trying to exclude application.properties from the fat jar created by gradle for a Springboot application. I can do it in maven. Gradle is the preferred build tool for the project. I tried to used exclude in the 'jar' task. It is not working. Any other suggestions ?
plugins {
id 'org.springframework.boot' version '2.2.5.RELEASE'
id 'io.spring.dependency-management' version '1.0.9.RELEASE'
id 'java'}
group = 'com.prasad'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '1.8'
repositories {
mavenCentral()
}
dependencies {
implementation 'org.springframework.boot:spring-boot-starter-web'
}
jar {
exclude('application.properties')
//tried this too exclude('src/main/resources/application.properties')
}
Excluding resources is usually the wrong approach. I would simply remove it from src/main/resources. If you use it for testing purposes, put it in src/test/resources. If you use it for the local bootRun task, you can configure that particular task with a path to a application.properties file which you can put somewhere else.
However, if you really like to exclude it, the pattern is correct. You are just not excluding it from the bootJar (fat jar) but only the normal jar (which is disabled by default when using the Spring Boot plugin). Try with:
bootJar {
exclude('application.properties')
}
I am trying to build a Spring Boot/Gradle project and create a jar without a main class. My purpose is that this project is a library that will be pulled in by other projects therefore the library project does not require a main class to run. Unfortunately, no matter what kind of gradle config I write I keep getting errors when I try to build install about not having a main class or not being able to find the bootJar task.
Here's what my gradle file looks like:
plugins {
id 'org.springframework.boot' version '2.1.7.RELEASE' apply false
}
apply plugin: 'io.spring.dependency-management'
apply plugin: 'maven'
dependencyManagement {
imports {
mavenBom org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES
}
}
repositories {
mavenCentral()
}
jar {
enabled = true
}
bootJar.dependsOn fooTask
But when I run this I get the following error:
Could not get unknown property 'bootJar' for root project
'foo-library' of type org.gradle.api.Project.
What in my configuration needs to change?
Disable bootJar in your build.gradle
bootJar {
enabled = false
}