How to build a WAR file with gradle? - gradle

I want to build a WAR file (and then deploy it to Tomcat). So, as an exercise, I've started a new Spring Boot Project using Gradle in IDEA IntelliJ. Afterwards, I've apply the plugin in the build.gradle file, like this apply plugin: 'war'
.
The problem is that when I try to run gradle war in the terminal, I get no war file! The only thing that happens is that it will generate a \build with 3 subsolders classes, resources and tmp, but there's no WAR in these.
What should I do to get a WAR file? I've watched this video, but this guy uses Maven and doesn't do advanced stuff and gets the war. I think there's got to be a way to keep it simple.
When I run gradle war --info
Initialized native services in: C:\Users\...\.gradle\native The client
...
Task :compileJava UP-TO-DATE
Resolving global dependency management for project 'deleteme'
Excluding [org.apache.tomcat:tomcat-annotations-api]
Excluding []
Skipping task ':compileJava' as it is up-to-date.
:compileJava (Thread[Task worker for ':',5,main]) completed. Took 0.753 secs.
:processResources (Thread[Task worker for ':',5,main]) started.
Task :processResources UP-TO-DATE
Skipping task ':processResources' as it is up-to-date.
:processResources (Thread[Task worker for ':',5,main]) completed. Took 0.003 secs.
:classes (Thread[Task worker for ':',5,main]) started.
Task :classes UP-TO-DATE
Skipping task ':classes' as it has no actions.
:classes (Thread[Task worker for ':',5,main]) completed. Took 0.0 secs.
:war (Thread[Task worker for ':',5,main]) started.
Task :war SKIPPED
Skipping task ':war' as task onlyIf is false.
:war (Thread[Task worker for ':',5,main]) completed. Took 0.0 secs.

I guess that you have applied the spring boot gradle plugin to your project, in addition to the war plugin ? then this behaviour is normal, since the Spring Boot plugin will disable jar and war tasks and replace these with bootWar and bootJar tasks .
With both spring boot and war plugin applied:
./gradlew war
15:35:09: Executing task 'war'...
> Task :compileJava UP-TO-DATE
> Task :processResources UP-TO-DATE
> Task :classes UP-TO-DATE
> Task :war SKIPPED
BUILD SUCCESSFUL in 0s
2 actionable tasks: 2 up-to-date
15:35:10: Task execution finished 'war'.
Note the SKIPPED message
$ ./gradlew bootWar
15:36:35: Executing task 'bootWar'...
> Task :compileJava UP-TO-DATE
> Task :processResources UP-TO-DATE
> Task :classes UP-TO-DATE
> Task :bootWar
BUILD SUCCESSFUL in 1s
3 actionable tasks: 1 executed, 2 up-to-date
15:36:37: Task execution finished 'bootWar'.
Then you will get the expected war file under build/libs.
You can still re-enable the standard jar/war tasks as explained here : https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/html/#packaging-executable-wars-deployable (if you need to produce normal archives and not executable archives)
Regarding the Tomcat issue: install Tomcat 8.5.

Please read: https://docs.gradle.org/current/userguide/war_plugin.html
If using Gradle with IntelliJ, goto build.gradle (or build.gradle.kts for Kotlin) and add
id 'war'
(or just
war
for Kotlin ) under Plugins
Reload Gradle Project and then use gradlew bootWar on the Intellij Terminal.
Add --info or --stackTrace for debugging

As rightly said by #M.Ricciuti, the spring boot gradle plugin will disable the jar/war tasks and would only work with bootJar/bootWar tasks. But if you still want your project to be packaged with jar/war tasks just add the below to your build.gradle file
war {
enabled=true
}
This would enable the gradle war command to generate the war for your project.

I was also facing the same issue.
After a lot of struggle, I figured out that I needed to extend SpringBootServletInitializer in my application. So my effective code looks like
public class SyncApplication extends SpringBootServletInitializer {
#Override
protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
return application.sources(SyncApplication.class);
}
public static void main(String[] args) {
SpringApplication.run(SyncApplication.class, args);
}
}
Looks like this SpringBootServletInitializer directs war plugins generate bootstrapping code while building the war, and thus spring context is initialized while deploying the app.

If you are using spring boot with gradle, you should follow the steps below:
Edit your build.gradle file adding apply plugin:'war' and then rebuild gradle.
With gradle built two (2) files will be created on your root directory:
gradlew (for Linux) and gradlew.bat (for windows)
Open your terminal on your current project and run
./gradlew war
Your project will build and generate a .war file in build/libs/

Related

gradle: Task :jar SKIPPED while I get my jar with gradlew build

My Question is: Why does the jar-creation work with gradlew build, while I see "Task :jar SKIPPED" when I click on jar in intellij's gradle window ? And how can I fix it in IntelliJ ?
Just created something with spring initializer and loaded the project in intellij as it is.
( it is org.springframework.boot, .. 'org.springframework.boot:spring-boot-starter-web')
I wonder about Task :jar SKIPPED ( nor jar created )
and than I discovered that I get the jar when I start from console.
( and the jar runs fine, it finds the main class - even without jar manifest attribute in build.gradle)
( yesterday I failed in maven with "no main manifest attribute in .... .jar )
This is because Springboot Gradle plugin will create a bootJar task and by default will disable jar and war tasks, as described here: https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/html/#packaging-executable-and-normal
So you need to execute bootJar task , from the IDE. When executing gradlew build, the tasks bootJar gets automatically executed, due to tasks dependencies created by the plugin.
When running task build (from console or IDE), you can see the tasks executed by Gradle depending on tasks dependencies, e.g.:
> Task :backend:compileJava
> Task :backend:processResources
> Task :backend:classes
> Task :backend:bootJar ## <== this is the task register by Springboot plugin, which produces the "Fat/executable" jar
> Task :backend:jar SKIPPED ## <== task disabled by Springboot plugin
> Task :backend:assemble
> Task :backend:processTestResources
> Task :backend:testClasses
> Task :backend:test
> Task :backend:check
> Task :backend:build
For your remark
the jar runs fine, it finds the main class - even without jar manifest
attribute in build.gradle
The Springboot plugin will automatically configure this for you, see : https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/html/#packaging-executable-configuring-main-class
EDIT 27-05-2021
Starting from Springboot 2.5, the jaris not disabled by default anymore. see more details in release notes here
You can enble this, with add code below in projectName.gradle
it works for me :
spring-boot : 2.0.8.RELEASE
Gradle : 4.5 or >
jar {
baseName = 'projectName'
enabled=true
manifest {
....
}
}

Grails 4 - Gradle 'assemble' task not generating .war.original archive

I just upgraded my Grails web-app from version 3.2 to 4.0.
I have a provided dependency in build.gradle (fairly common configuration):
dependencies {
...
compile "org.springframework.boot:spring-boot-starter-logging"
compile "org.springframework.boot:spring-boot-autoconfigure"
compile "org.springframework.boot:spring-boot-starter-actuator"
provided "org.springframework.boot:spring-boot-starter-tomcat"
...
}
I’ve just noticed that by executing Gradle assemble task I don’t get the myApp.war.original archive anymore (which used to be build without all provided libs), but only the one including provided dependencies.
Am I missing something here? I'd really like to spare those ~4MB of jars in lib-provided folder.
Thanks in advance!
Update 1
Following #ck1's advice i changed provided dependency to providedCompile, but the result is the same.
Though I already use the war plugin, I noticed that the sequence of tasks initiated by assemble task is:
> Task :assetCompile
Finished Precompiling Assets
> Task :compileJava
> Task :compileGroovy
> Task :buildProperties
> Task :processResources
> Task :classes
> Task :compileWebappGroovyPages NO-SOURCE
> Task :compileGroovyPages
> Task :compileGsonViews
> Task :findMainClass
> Task :bootWar
> Task :war SKIPPED
> Task :assemble
So the war task is skipped in favor of the new bootWar task (not available in Gradle 3, used by Grails 3).
Any way to force it? Or is it something the plugin should already support?
Update 2
After some research, I added to build.gradle
war {
enabled = true
}
and was able to get the war task to execute:
> Task :assetCompile
Finished Precompiling Assets
> Task :compileJava
> Task :compileGroovy
> Task :buildProperties
> Task :processResources
> Task :classes
> Task :compileWebappGroovyPages NO-SOURCE
> Task :compileGroovyPages
> Task :compileGsonViews
> Task :findMainClass
> Task :bootWar
> Task :war // not skipped
> Task :assemble
I basically got to where I wanted to, i.e. get a .war archive without all the provided dependencies; differently from before though, not a pair of .war archives (myApp.war and myApp.war.original) but a single one named myApp.war not including the unneeded stuff.
But I'm still pretty much confused, as
Spring Boot's Gradle plugin documentation states bootWar is an extension of war.
The bootRepackage task has been replaced with bootJar and bootWar tasks for building executable jars and wars respectively. Both tasks extend their equivalent standard Gradle jar or war task, giving you access to all of the usual configuration options and behaviour.
But then Spring Boot 2.0 Migration Guide states war task is expected to be skipped:
The bootRepackage task has been replaced with bootJar and bootWar tasks for building executable jars and wars respectively. The jar and war tasks are no longer involved.
So again, what am I missing out?
You should replace provided with either the providedCompile or providedRuntime dependency configuration from the war plugin.
These two configurations have the same scope as the respective compile
and runtime configurations, except that they are not added to the WAR
archive.
Reference:
https://docs.gradle.org/4.10.2/userguide/war_plugin.html

Gradle does not import groovy class when running task

I have a gradle (1.8) project with 2 classes A and B where B import A. Both files are under /foo/bar/ package (myProjectFolder/test/foo/bar folder).
A.groovy class
package foo.bar
import org.junit.Test;
public class ATest{
#Test
public void run() {
System.out.println("CLASS A");
}
}
B.groovy class
package foo.bar
import org.junit.Test;
public class BTest{
#Test
public void run() {
ATest a = new ATest();
a.run();
System.out.println("CLASS B");
}
}
build.gradle
apply plugin: "groovy"
apply plugin: "java"
repositories {
mavenCentral()
}
dependencies {
groovy group: "org.codehaus.groovy", name:"groovy-all", version: "1.8.6"
testCompile "junit:junit:4.10"
}
test {
testLogging.showStandardStreams = true
}
sourceSets {
test { groovy {
srcDir 'test/foo/bar'
} }
}
buildscript {
repositories { mavenCentral() }
}
configurations{
addToClassLoader
}
dependencies {
addToClassLoader "junit:junit:4.10"
}
URLClassLoader loader = GroovyObject.class.classLoader
configurations.addToClassLoader.each {File file ->
loader.addURL(file.toURL())
}
task runA << {
new GroovyShell().run(file('test/foo/bar/ATest.groovy'));
}
task runB << {
new GroovyShell().run(file('test/foo/bar/BTest.groovy'));
}
Output console for gradle clean -Dtest.single=A test
[root#vm1]# gradle clean -Dtest.single=A test
The groovy configuration has been deprecated and is scheduled to be removed in Gradle 2.0. Typically, usages of 'groovy' can simply be replaced with 'compile'. In some cases, it may be necessary to additionally configure the 'groovyClasspath' property of GroovyCompile and Groovydoc tasks.
:clean
:compileJava UP-TO-DATE
:compileGroovy UP-TO-DATE
:processResources
:classes
:compileTestJava UP-TO-DATE
:compileTestGroovy
:processTestResources UP-TO-DATE
:testClasses
:test
foo.bar.ATest > run STANDARD_OUT
CLASS A
BUILD SUCCESSFUL
Total time: 13.205 secs
Output console for gradle clean -Dtest.single=B test
[root#vm1]# gradle clean -Dtest.single=B test
The groovy configuration has been deprecated and is scheduled to be removed in Gradle 2.0. Typically, usages of 'groovy' can simply be replaced with 'compile'. In some cases, it may be necessary to additionally configure the 'groovyClasspath' property of GroovyCompile and Groovydoc tasks.
:clean
:compileJava UP-TO-DATE
:compileGroovy UP-TO-DATE
:processResources
:classes
:compileTestJava UP-TO-DATE
:compileTestGroovy
:processTestResources UP-TO-DATE
:testClasses
:test
foo.bar.BTest > run STANDARD_OUT
CLASS A
CLASS B
BUILD SUCCESSFUL
Total time: 12.218 secs
Output console for gradle -q runA -i
[root#vm1]# gradle -q runA -i
Starting Build
Settings evaluated using empty settings script.
Projects loaded. Root project using build file '/opt/myProject/build.gradle'.
Included projects: [root project 'myProject']
Evaluating root project 'myProject' using build file '/opt/myProject/build.gradle'.
Starting file lock listener thread.
The groovy configuration has been deprecated and is scheduled to be removed in Gradle 2.0. Typically, usages of 'groovy' can simply be replaced with 'compile'. In some cases, it may be necessary to additionally configure the 'groovyClasspath' property of GroovyCompile and Groovydoc tasks.
All projects evaluated.
Selected primary task 'runA'
Tasks to be executed: [task ':runA']
:runA (Thread[main,5,main]) started.
:runA
Executing task ':runA' (up-to-date check took 0.001 secs) due to:
Task has not declared any outputs.
CLASS A
JUnit 4 Runner, Tests: 1, Failures: 0, Time: 63
:runA (Thread[main,5,main]) completed. Took 0.739 secs.
BUILD SUCCESSFUL
Total time: 7.826 secs
Output console for gradle -q runB -i <-- THIS EXECUTION FAILS and I don't know why.
[root#vm1]# gradle -q runB -i
Starting Build
Settings evaluated using empty settings script.
Projects loaded. Root project using build file '/opt/myProject/build.gradle'.
Included projects: [root project 'myProject']
Evaluating root project 'myProject' using build file '/opt/myProject/build.gradle'.
Starting file lock listener thread.
The groovy configuration has been deprecated and is scheduled to be removed in Gradle 2.0. Typically, usages of 'groovy' can simply be replaced with 'compile'. In some cases, it may be necessary to additionally configure the 'groovyClasspath' property of GroovyCompile and Groovydoc tasks.
All projects evaluated.
Selected primary task 'runB'
Tasks to be executed: [task ':runB']
:runB (Thread[main,5,main]) started.
:runB
Executing task ':runB' (up-to-date check took 0.001 secs) due to:
Task has not declared any outputs.
:runB FAILED
:runB (Thread[main,5,main]) completed. Took 0.237 secs.
FAILURE: Build failed with an exception.
* Where:
Build file '/opt/myProject/build.gradle' line: 46
* What went wrong:
Execution failed for task ':runB'.
> startup failed:
/opt/myProject/test/foo/bar/BTest.groovy: 8: unable to resolve class ATest
# line 8, column 9.
ATest a = new ATest();
^
/opt/myProject/test/foo/bar/BTest.groovy: 8: unable to resolve class ATest
# line 8, column 13.
ATest a = new ATest();
^
2 errors
* Try:
Run with --stacktrace option to get the stack trace. Run with --debug option to get more log output.
BUILD FAILED
Total time: 7.872 secs
So, what am I missing to run the task runB correctly?
Note: the premise of the question is based on a truly unorthodox use-case, which should be corrected. That said, I can explain the behaviour that is observed.
When the command-line specifies the test task, then ~/build/classes/test is added to the classpath. In the case of running the runB task, it is not. So BTest.groovy can't find ATest.
To correct it (only as an illustration, not as a suggestion for 'real' code), consider:
// don't do this in a real project!
task runB(dependsOn: 'compileTestGroovy') << {
def testDirURL = new File("${projectDir}/build/classes/test").toURL()
loader.addURL(testDirURL)
new GroovyShell(loader).run(file('test/foo/bar/BTest.groovy'))
}
Now, runB requires that the Groovy test code is compiled, and then manually (!?) adds it to the classloader used by GroovyShell.

Gradle : Copy different properties file depending on the environment and create jar

I am evaluating gradle for my spring boot project. Everything seems to work but here is where I am stuck. I have 2 properties file. One for prod i.e.:
application_prod.properties
and another for qa i.e.:
application_qa.properties
My requirement is such that while I build (create jar file) the project from gradle, I've to rename the properties file to
application.properties
and then build the jar file. As far as I know, gradle has a default build task. So here I've to override it such that it considers only the required properties file and rename it and then build depending on the environment.
How can I achieve this?
What you need to do is to override processResources configuration:
processResources {
def profile = (project.hasProperty('profile') ? project.profile : 'qa').toLowerCase()
include "**/application_${profile}.properties"
rename {
'application.properties'
}
}
With the following piece of code changed you will get the output below:
$ ./gradlew run -Pprofile=PROD
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:run
LOL
Profile: PROD
BUILD SUCCESSFUL
Total time: 3.63 secs
$ ./gradlew run -Pprofile=QA
:compileJava UP-TO-DATE
:processResources
:classes
:run
LOL
Profile: QA
BUILD SUCCESSFUL
Total time: 3.686 secs
$ ./gradlew run
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:run
LOL
Profile: QA
BUILD SUCCESSFUL
Total time: 3.701 secs
Demo is here.

Handle gradle tasks dependencies

Using gradle with its spring-boot plugin (1.5.1) and a first spirit plugin together raises an error:
D:\Coden\WS\STS\fs-db-import>gradle build
:genJaxb
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:jar UP-TO-DATE
:fsm UP-TO-DATE
:bootRepackage FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':bootRepackage'.
> Unable to deduce layout for 'D:\Coden\WS\STS\fs-db-import\build\fsm\fs-db-import-0.0.1.fsm'
It seems that bootRepackage from the spring boot plugin can't handle or package the fsm file.
a) how can I exclude it?
Another approach would be to switch the 'fsm' and the 'bootRepackage' task, but adding the following lines to build.gradle
bootRepackage.dependsOn -= fsm
tasks.bootRepackage.dependsOn -= fsm
fsm.dependsOn bootRepackage
results in
Circular dependency between the following tasks:
:bootRepackage
\--- :fsm
\--- :bootRepackage (*)
(*) - details omitted (listed previously)
b) how do I remove 'fsm'`s dependency from 'bootRepackage'?
c) is it possible to show a gradle task dependency graph? (not project dependencies)
By default the Spring Boot plugin attempts to repackage all tasks of type Jar. Sine the FSM task extends from Jar the plugin attempts to repackage them both. You can explicitly tell the plugin which Jar task to use.
bootRepackage {
withJarTask jar
}
More information can be found in the Spring Documentation.

Resources