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')
}
Related
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'
Spring boot makes it really easy to setup a simple app.
But it takes me longer to actually get a jar file which I can upload to a remote server.
I am using IntelliJ, no command line, and I use gradle. The application is running somehow out of Intellij. But where are the created files? Where is my jar from Bootjar?
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath("org.springframework.boot:spring-boot-gradle-plugin:2.0.0.RELEASE")
}
}
apply plugin: 'java'
apply plugin: 'eclipse'
apply plugin: 'idea'
apply plugin: 'org.springframework.boot'
apply plugin: 'io.spring.dependency-management'
bootJar {
baseName = 'gs-spring-boot'
version = '0.1.0'
}
repositories {
mavenCentral()
}
sourceCompatibility = 1.8
targetCompatibility = 1.8
dependencies {
compile("org.springframework.boot:spring-boot-starter-web")
compile("org.springframework.boot:spring-boot-starter-actuator")
testCompile("org.springframework.boot:spring-boot-starter-test")
// add spring data repos
compile("org.springframework.boot:spring-boot-starter-data-jpa")
compile("org.postgresql:postgresql:42.2.4")
// REST interface
compile("org.springframework.boot:spring-boot-starter-data-rest")
// Security
compile("org.springframework.boot:spring-boot-starter-security")
}
Update: Added a picture of the project structure:
Update 2: Folder structure:
There will not be a jar created if you are just running this in your IDE. In order to do that, you need to run the gradle build (in your case) either from your IDE or the command line to get it to build it into a jar.
From the command line, go to your project directory and type this:
./gradlew build
This executes the gradle wrapper, which should download everything you need to run the build, and then executes the build.
You will then find your jar in build/lib
build/libs (if you've ran build to build the jar file)
I am trying to get the Gradle Maven Publish Plugin to publish a snapshot version of my Java library to my local Maven repo such that:
The version of the jar is 1.0.0.SNAPSHOT-<timestamp>, where <timestamp> is the current system time in millis (similar to something like System.currentTimeInMillis()); and
I log to STDOUT/console the full name of the jar being published, including the version above; and
A properly-formatted pom.xml is published to Maven local alongside the jar, so that any other Gradle/Maven projects can "pull it down" locally and fetch its transitive dependencies properly
My best attempt so far:
plugins {
id 'java-library'
id 'maven-publish'
}
dependencies {
compile(
'org.hibernate:hibernate-core:5.0.12.Final'
,'com.fasterxml.jackson.core:jackson-core:2.8.10'
,'com.fasterxml.jackson.core:jackson-databind:2.8.10'
,'com.fasterxml.jackson.core:jackson-annotations:2.8.0'
)
testCompile(
'junit:junit:4.12'
)
}
repositories {
jcenter()
mavenCentral()
}
sourceCompatibility = 1.8
targetCompatibility = 1.8
group 'com.me'
jar {
baseName = 'my-lib'
version = '1.0.0-SNAPSHOT'
}
publishing {
publications {
mavenJava(MavenPublication) {
from components.java
}
}
}
However, with this setup, when I run ./gradlew publishToMavenLocal:
I do see the jar being deployed to ~/.m2/repository/com/me/my-lib/ but without a pom.xml and no 1.0.0.SNAPSHOT version appended to it
I don't even know how/where I would append the timestamp onto the version
I don't even know how/where I would do a println(...) to report the full name of the jar being published
Any ideas?
Regarding #3, To install your artifact to a local repository you do not need the maven-publish plugin, rather the maven plugin
See The Maven plugin documentation, specifically the Tasks section and the Installing to the local repository section with it, you can run gradle clean build install
It works for me with a build.gradle file as simple as this
version '1.0-SNAPSHOT'
apply plugin: 'java'
apply plugin: 'maven'
Note, if you need to publish something other then the default generated jar then you need to change the archives configuration
Regarding #1 appending the timestamp, move the version line outside the jar clause and change it from
version = '1.0.0-SNAPSHOT'
to
version = "1.0-SNAPSHOT-${System.currentTimeMillis()}"
This is using Groovy GString (AKA string interpolation - note the change from single quotes to double quotes) to append the current time in millis to the version
Last but not least, regarding #2 printing the jar full name append the following to the build.gradle file
install.doLast {
println jar.archiveName
}
Essentially we're appending to the install task (the one executed in the top of my answer) a println of the jar configuration's archiveName (see here if you want something else)
So all in all my build.gradle file looks like this:
group 'com.boazj'
version "1.0-SNAPSHOT-${System.currentTimeMillis()}"
apply plugin: 'java'
apply plugin: 'maven'
install.doLast {
println jar.archiveName
}
I've got a basic Java application in which I would like to use WebJars. I use Gradle as my build system. I would like to use the WebJars for Bootstrap and JQuery so I can easily reference and update them in my Spring-Boot/ThymeLeaf application. The application is basically the one from the form tutorial located here
As I understand it Gradle should place all the files from the WebJars into the META-INF folder in my Jar file. If I understand everything correctly the Spring-Boot resource handler will then load resource from META-INF/ when I reference something in my html page that starts with /webjars/
Unfortunately this doesn't work (yet). Since I see in Tomcat's log output that the resource handler is correctly installed. I decided to check if the files are actually in my Jar file.
When I extract my Jar file the META-INF folder only has a file called MANIFEST.MF with some information about Spring Boot. There is a BootStrap-3.3.7.Jar and a JQuery-3.2-1.Jar file in BOOT-INF/lib but I don't think that is where they are supposed to end up. (Or am I wrong and is there error somewhere in the resource handler?).
How do I tell gradle to do the right thing with these files when I run gradle build?
My gradle.build file looks like this:
buildscript {
ext {
springBootVersion = '1.5.8.RELEASE'
}
repositories {
mavenCentral()
}
dependencies {
classpath("org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}")
}
}
apply plugin: 'java'
apply plugin: 'eclipse'
apply plugin: 'org.springframework.boot'
apply plugin: "jacoco"
jar {
baseName = 'gs-serving-web-content'
version = '0.0.1'
}
bootRun {
addResources = true
}
repositories {
mavenCentral()
}
sourceCompatibility = 1.8
targetCompatibility = 1.8
dependencies {
compile("org.springframework.boot:spring-boot-starter-thymeleaf")
compile("org.webjars:jquery:3.2.1")
compile("org.webjars:bootstrap:3.3.7")
testCompile("org.springframework.boot:spring-boot-starter-test")
}
Gradle is doing the right thing as the jars should be packaged in BOOT-INF/lib. The root of each jar in BOOT-INF/lib is then added to the classpath from where each its webjar related content in META-INF content should be found.
I'd recommend asking another question that focuses on what your application's doing at runtime. As far as I can tell, everything's working as it should at build time.
I have created a project in Spring Tool Suite with Spring Boot and Gradle, and I really don't know how to export to make it work.
I don't know much about gradle, just the basics to add dependencies from the maven repository. So in some articles says to apply the application plugin to do the task, but I don't know how to set up the configuration file and how to create the executable.
If anyone could write or link a step by step detailed explanation on how to do it, it would be very much appreciated.
This is my build.gradle file:
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath("org.springframework.boot:spring-boot-gradle-plugin:1.3.1.RELEASE")
}
}
apply plugin: 'java'
apply plugin: 'eclipse'
apply plugin: 'spring-boot'
springBoot {
mainClass = "com.rodamientosbulnes.objetivosventa.Application"
executable = true
}
jar {
baseName = 'objetivosventa'
version = '0.1.0'
}
repositories {
mavenCentral()
}
sourceCompatibility = 1.8
targetCompatibility = 1.8
dependencies {
compile('org.springframework.boot:spring-boot-starter')
compile('org.springframework:spring-jdbc')
compile('net.sourceforge.jtds:jtds:1.3.1')
compile('org.apache.poi:poi-ooxml:3.13')
compile('com.miglayout:miglayout-swing:4.2')
}
task wrapper(type: Wrapper) {
gradleVersion = '2.3'
}
Build file looks fine, you only need to run gradle build (or Run As -> Gradle -> Gradle build in the STS) to create the runnable jar.
More details about configuration of the gradle plugin are available on spring boot documentation site.
Gradle's application plugin doesn't make a single execitable for you, but it can create a distribution, which includes all the dependencies, jar-artifact for your project and 2 scripts to run it (one batch-file and linex executable).
The main thing you need to know, is that spring-boot plugin already provide all the task from application plugin you may need. All the task you can find here. You need distZip or installDist to package your project to the distribution. This task will create a ready project distribution under your project-folder/build folder. One more task you may find usefull is buildRun which will run you spring-boot application without package it into distribution.