I want to pre-compile sass into css.
addResources flag(true) does not solve this problem.
Spring devtools just load raw resources into build.
There are some gradle node plugin, gulp plugin.
When processResoureces task is called, bootRun task running on the server resets build directory and re-copy raw resources into build. So gulp, webpack, etc plugin can't do this...
Rene has given a solution in gradle blog
all those "internal" tasks are created within the
project.afterEvaluate closure which means that they can't be
referenced directly in the build.gradle. As a workaround you can move
the dependsOn declaration in the afterEvaluate phase too.
project.afterEvaluate{
prepareDebugDependencies.dependsOn("generateMyAssets")
}
Resource Link: How to define a preprocessing task for android build?
UPDATE#1:
Q1: Why bootRun task re-copy resources?
If devtools has been added to your project it will automatically
monitor your application for changes. Alternatively, you can also run
the application so that your static classpath resources (i.e. in
src/main/resources by default) are reloadable in the live application,
which can be helpful at development time.
bootRun {
addResources = true
}
Making static classpath resources reloadable means that bootRun does
not use the output of the processResources task, i.e., when invoked
using bootRun, your application will use the resources in their
unprocessed form.
Related
In a Gradle project I have multiple sub-projects. I need to copy the dependencies from the configuration of one sub-project to that of another. I can achieve this using the following, adapted from this answer here:
task copyDependencies(type: Copy) {
from project(":sub").configurations.compile
into "${buildDir}/libraries"
}
Unfortunately, with Gradle 5.1, this generates the following deprecation warning (truncated for brevity):
The configuration :sub:compile was resolved without accessing the project in a safe manner. ... This behaviour has been deprecated and is scheduled to be removed in Gradle 6.0.
What's the best way to do this now for Gradle 5.1 and later?
The warning appeared as reaching across project boundaries can cause issues when the build runs in parallel.
The proper way of doing this is to let Gradle know that the project declaring the copyDependencies task will need the project :sub's dependencies.
You can achieve this by doing the following:
configurations {
dependenciesToCopy
}
dependencies {
dependenciesToCopy project(':sub')
}
task copyDependencies(type: Copy) {
from configurations.dependenciesToCopy
into "${buildDir}/libraries"
}
This will cause Gradle to properly create an execution dependency between your project and the resolution of the dependencies of the sub project.
Relevant discussion on the Gradle forums.
I am trying to follow this example to do spring boot and spring boot dev tools integration to do automatic restart. The classes in the build folder are getting updated when i run build --continuous task but the application still talks to the old classes. In the example the bootRun task is as below. My project has its custom task for running the application. Right now with build -continuous when I make a change the application it is rebuilding the classes but the running application is not showing the changes. How to change my custom h2Run task so that it loads the changed classes? Thank you.
The boot run task in the example
bootRun {
classpath = sourceSets.main.runtimeClasspath + configurations.dev
}
My custom task for bootRun
class Run extends JavaExec {
Run() {
group "application"
dependsOn project.tasks.classes, project.tasks.pathingJar
classpath = project.files("$project.buildDir/classes/main", "$project.buildDir/resources/main", project.tasks.pathingJar.archivePath)
main = "com.mycompany.Application"
}
}
task h2Run(type: Run) {
classpath = sourceSets.main.runtimeClasspath + configurations.dev // this is not working
description "Start $appName using H2 database"
args "--spring.profiles.active=dev"
mustRunAfter 'cleanH2'
dependsOn copyContentTypeLibraries
}
I walked through the DZone article you linked to. I didn't add your custom Run class or task, I just grabbed the bootRun task right out of the article. Even without any of your custom code, I initially experienced the same behavior you do.
The article states:
At the first terminal, start Gradle build as a continuous task:
gradle build --continuous
At the second terminal, start the Gradle bootRun task: gradle
bootRun
If I do these things, in this order, I also see my classes recompile, but the servlet container doesn't pick the changes up. Just like you describe.
However, if I do gradle bootRun first, and gradle build --continuous second, after the application is running, the application restarts as expected whenever I edit a java file.
Have you tried executing the commands in the two terminal windows in reverse order?
I'm working on compiling python bindings using gradle.
There is a plugin by linkedin that facilitates that.
They also include a project called the pivy-importer that converts python dependencies into an ivy repository.
I've created a gradle plugin that wraps the pivy-importer so that it can run as a python task.
My repositories are declared like this:
repositories {
pyGradlePyPi()
ivy {
name 'pypi-local' //optional, but nice
url "${project.buildDir.path}/pythonIvy"
layout "pattern", {
ivy "[organisation]/[module]/[revision]/[module]-[revision].ivy"
artifact "[organisation]/[module]/[revision]/[artifact]-[revision](-[classifier]).[ext]"
m2compatible = true
}
}
}
The problem, however, is that the repositories are being loaded before the plugin executes.
The first task that the python task runs is pinRequirements so I was adding my cusom pythonImporter task before that like this:
pinRequirements.dependsOn pythonImporter
However, even when I do that, the console shows that the pythonImporter task is running before but as soon as it tries to assemble the dependencies, it can't find them even though they do exist in the file system.
If you rerun the task again, however, it passes because the first run added the repository to the file system.
TL;DR
I need a way to run a task before dependencies are looked up under using a project's configured repositories are loaded.
I moved the tasks execution to my buildSrc subproject and made the build task depend upon its execution.
This works because the buildSrc project is always evaluated before the rest of the projects so you can do "before build" logic there.
Without Gradle War Plugin, bootRepackage task depends on jar task but with Gradle War Plugin, it depends on war task.
How can I change it to depend on jar task even though I'm using Gradle War Plugin?
UPDATE:
I'm using war task to create a war file including documents to be deployed to a documentation server and I want to use bootRepackaged jar file to provide a service. My war task depends on asciidoctor task which depends on test task (I'm using Spring REST Docs.) but I don't want to run asciidoctor task or test task when using bootRepackage task.
I solved my problem with the following setup:
ext {
mainClassName = 'com.izeye.throwaway.Application'
}
task myBootRepackage(type: BootRepackage, dependsOn: jar) {
}
but I'm not sure this is a good practice.
This is a sample project having the above configuration:
https://github.com/izeye/spring-boot-throwaway-branches/tree/war
You should have been able to do this:
bootRepackage {
withJarTask jar
}
While this correctly causes the jar task's jar to be repackaged, it doesn't remove the dependency on the war task. This is another symptom of this Spring Boot issue.
Until this issue has been resolved, the approach that you've taken – declaring your own BootRepackage task and manually configuring the tasks that it depends upon – is your best option.
I am working on a project on the side of the main project. The main project used to use ivy so my side project can take advantage of the ivy.xmls and do ivy:resolve to solve all dependencies into a cache.
The main project has moved to gradle and I was wondering if there is a task in the gradle API that can populate gradle cache when I only have the gradle build files.
You can accomplish the same thing with Gradle by configuring a task to copy a configuration to a destination.
task copyDependencies(type: Copy) {
from configurations.runtime
into "$buildDir/deps"
}