I have a maven project that I am migrating to gradle. In the maven project I use the jetty plugin and provide an overrideDescriptor like this:
<webAppConfig>
<overrideDescriptor>override.xml</overrideDescriptor>
</webAppConfig>
Using this, I can override some context parameters from my web.xml with parameters from the override.xml, but any parameters not in the override.xml will revert to the value in the web.xml. This all works as expected.
Now that I am moving to gradle, I am trying to replicate this using the gradle jetty plugin. I tried providing a webXml value, but it replaces the entire web.xml file:
jettyRun {
webXml file('override.xml')
}
Is there any way I can provide the same override functionality via gradle, or am I stuck reworking my override file to be a complete replacement for my default web.xml.
Try overrideWebXml, e.g.:
jettyRun {
overrideWebXml file('override.xml')
}
This is a property on AbstractJettyRunTask, and worked for me.
This would be entirely within the gradle plugin so best to check the documentation for the plugin to see if there is an override option. If not it ought to be relatively easy to add it and contribute back to that project.
Related
So we are using Spring boot to deliver our application. We use the Jib plugin to monitor create docker images and run them.
We use gradle to build the project and there dev tools is identified as a developmentOnly dependency.
Just as mentioned in the spring docs at https://docs.spring.io/spring-boot/docs/current/reference/html/using-spring-boot.html#using-boot-devtools .
However when it runs in the container in prod I still see it getting restarted now and then.
My question is does the gradle configuration not really exlude it from packaging.
Do i need to explicitly set the -Dspring.devtools.restart.enabled=false parameter ?
Solution :
So turns out it was the gradle jib plugin playing games.
While the spring documentation is spot on about how to go about removing the dependency from gradle spring boot project. The technique of specifying a developmentOnly only helps in telling gradle to ignore the dev tools. The jib gradle plugin has a mind of its own.
It includes all jars when building a docker image and there is no way to exclude any jar. The only reasonable way is to customize the gradle jib plugin in build.gradle to write this ,
jib {
from {
image 'gcr.io/distroless/java:11'
}
container {
jvmFlags = ['-Xms1G', '-Xmx1G', '-Dspring.devtools.restart.enabled = false']
}
}
This will make sure that even if the jar is included the container environment has the restart taken care of.
Reference : https://github.com/spring-projects/spring-boot/issues/15382
There's really a few problems here:
Springboot has its own custom definitions instead of using what would be the equivalent of profiles. Their approach is best for springboot users, but rather hard to integrate with given all their custom logic.
Jib can't know all the custom implementation of each framework.
I really think what you should be doing is something like this:
dependencies {
if (System.getProperty("development") == true) {
// include the springboot devtool dependency
}
}
When you want to run or build in dev mode, just do
./gradlew whateverTask -Ddevelopment=true
You can achieve that by setting spring.devtools.restart.enabled=false in your application.properties or your specific profile properties ex. application-cloud.properties. Let me know if this works.
Well, just faced the same problem recently and it seems there's already a very straight-forward way to solve it.
The problem
Jib is actually considering spring-boot-devtools as a runtime dependency and so, adding it to the image. In my case, this is also true for h2 database jar which is used only locally for development.
Also, I wouldn't like to deal with any extra custom parameter in my build, neither turn-off features by configuration if I don't really wanna them available at production.
Solution
GoogleContainerTools' team has released a jib-extension to deal with devtools problem directly. There's a Gradle and Maven version and it works flawlessly.
However, to my needs (also exclude h2) I've decided to use jib layer filter extension so I can keep my image as close to bootJar as possible.
Here goes the code snippet in gradle:
// should be at the top of build.gradle
buildscript {
dependencies {
classpath('com.google.cloud.tools:jib-layer-filter-extension-gradle:0.1.0')
}
}
jib {
// ...
pluginExtensions {
pluginExtension {
implementation = 'com.google.cloud.tools.jib.gradle.extension.layerfilter.JibLayerFilterExtension'
configuration {
filters {
filter {
glob = '**/h2-*.jar'
}
filter {
glob = '**/spring-boot-devtools-*.jar'
}
}
}
}
}
}
Check here the Gradle and Maven version for this extension.
In my Vaadin application, I have my own widgetset specified like below in web.xml
<init-param>
<param-name>widgetset</param-name>
<param-value>com.foo.bar.AppWidgetSet</param-value>
</init-param>
And, I had placed my AppWidgetSet.gwt.xml file in src/main/java/com/foo/bar/AppWidgetSet.gwt.xml
This setup worked fine until I upgraded to vaadin 7.7.0 (from 7.6.8). After upgrade, I got following error, when I try to access the app through a browser.
INFO: Requested resource [/VAADIN/widgetsets/AppWidgetset/AppWidgetset.nocache.js] not found from filesystem or through class loader. Add widgetset and/or theme JAR to your classpath or add files to WebContent/VAADIN folder.
It seems like vaadin is looking for a different location for the widgetset, so I placed my AppWidgetSet.gwt.xml in the root of the classpath (src/main/java/AppWidgetSet.gwt.xml) and re-built the app.
Then it worked again.
Is specifying the widgetset as an init param no longer available? Do I have to place the widgetset xml in the root of the classpath itself?
I have similar issues after upgrading my Vaadin application from 7.6.8 to 7.7.2. I've noticed that package under src/main/resources started to multiply recursively :
Below was the state with version 7.6.8, prior updating POM to 7.7.7 :
src/main/resources
myPackage
MyAppWidgetset.gwt.xml
After updating POM to 7.7.7, under "myPackage" appeared new "myPackage" with xml file ! Just to emphasize that after every rebuild, those folders constantly creating and creating, so after 4th build there are more than 10 subfolders !
src/main/resources
....myPackage
........myPackage
................MyAppWidgetset.gwt.xml
................................myPackage
................................................MyAppWidgetset.gwt.xml
...
MyAppWidgetset.gwt.xml
It seems as if there is a bug in 7.7.2 as regards custom widgetsets. First, check if you really need them. With no client side custom widgets, just forget any widgetset annotations or any related web.xml parametrization and let Vaadin make use of its new default AppWidgetset. If not, consider refactoring and converting custom client stuff into separate projects, installed in local Maven repo and then used via dependency, still not putting any own gwt.xml anywhere in main project's path. Finally, if none of above may be used (as in my case, too), just wait for bug fix in 7.7.3.
See: https://dev.vaadin.com/ticket/20320
As I noticed, new 7.7.2 plugin does not put anything into source (i.e. /VAADIN/widgetsets), but stores compiled JS directly in output artifact and war archive. So, the workaround for #Lahiru Chandima could be not rely entirely on new, ascetic 7.7.2 plugin and make use of some old elements like <webappDirectory> and/or <hostedWebapp>, mentioning ${basedir}/src... locations.
For #dobrivoje I'd recommend doing compilation as needed, then remove surprisingly created unnecessary (nested) packages and xml file and forget client compilation for some time (is it really needed in every build?) by commenting out Maven goals:
<!-- goal>update-widgetset</goal>
<goal>compile</goal -->
I'm evaluating Spring MVC & Boot and AngularJs for building web applications. I've run into the problem that when I make modifications to my static content (html, js, css), I have to restart the application every time. I hope there is a some way of solving that because restarting the whole application for static content changes is not efficient. Every other web app framework I've tried allows updating static content files on the fly(even just Spring MVC and plain old WAR application).
I've setup my project from "Building a RESTful Web Service with Spring Boot Actuator" guide (http://spring.io/guides/gs/actuator-service/). Basically it uses Spring Boot and MVC controllers to create a REST service. In addition, I've used "Consuming a RESTful Web Service with AngularJS" guide (http://spring.io/guides/gs/consuming-rest-angularjs/) to build a frontend with AngularJS. It creates a web page that displays the response from the REST service. The only change I've made is that the requests are made to my application instead of "http://rest-service.guides.spring.io/greeting". My static content is stored in "src/main/resources/public" folder. This setup works correctly except it doesn't reload static content.
A recap of the original problem
I've run into the problem that when I make modifications to my static content (html, js, css), I have to restart the application every time
I had the same problem and finally solved it by adding
<configuration>
<addResources>true</addResources>
</configuration>
to spring-boot-maven-plugin in the pom.xml
I got confused by this spring-boot-devtools thing, but it had no effect whatever I did.
My static content is stored in "src/main/resources/public" folder.
Your path is just fine. src/main/resources/static is also fine.
Ah ... I came across this issue too.
Instead of putting your static content in the classpath src/main/resources/public folder, put them in src/main/webapp, the same as you would any other Java web app. The embedded Tomcat will automatically reload them whenever they change.
As mentioned in the comments, the default configuration will not include the resources that are in src\main\webapp. To get around this issue, you can just add the following to your pom.xml <build> node:
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<id>copy-resources</id>
<phase>validate</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>${basedir}/target/classes/static</outputDirectory>
<resources>
<resource>
<directory>src/main/webapp</directory>
<filtering>true</filtering>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
By using the resources plugin, you are able to do your local development by running the executable JAR:
java -jar target/.jar
While that is running you can use Chrome Dev Tools or whatever IDE you like for modifying the files, without restarts. However, whenever you run your build, then the package generated will include all of the files under src\main\webapp in src\main\resources\static.
The docs say "all modern IDEs allow reloading of static resources and usually also hot-swapping of Java class changes" (https://docs.spring.io/spring-boot/docs/current-SNAPSHOT/reference/html/howto.html#howto-hotswapping). It's true. Eclipse does it more or less by default, and I'm not an IntelliJ user, but from what I understand you can configure it to build automatically as well.
A colleague and I came across this issue as well. We found the answer in the IntelliJ documentation...
On the main menu, choose Run | Reload Changed Classes
My solution (written in Kotlin but is quite obvious):
#Controller
class WebController : WebMvcConfigurerAdapter() {
override fun addResourceHandlers(registry: ResourceHandlerRegistry) {
System.getProperty("resources.local.path")?.let {
registry.addResourceHandler("/**").addResourceLocations(it)
}
}
...
}
Main idea is you can add your own resource handler conditionally. E.g. if some system property is set (resources.local.path) then add resource location with value from the property. Then you set this property in development with some reasonable value like '-Dresources.local.path=file:/Users/andrey/Projects/gsp-test/src/main/resources/static/'.
Do not forget trailing slash.
I am using 1.5.8.RELEASE.
It instantly updates my changes especially static files or jsp files.
If you are using Maven. You need to add this in pom.xml
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-devtools</artifactId>
<optional>true</optional>
</dependency>
And you have to start Spring Boot with this:
mvn clean spring-boot:run
Full example and more detail here https://www.surasint.com/spring-boot-with-auto-update-changed-files-example/
#eigil metioned addResources config for maven build. I'm using spring-boot-gradle-plugin in a gradle build, and I found this Spring Boot github issue
, and the Spring Boot doc mentioned this option too. Just add this directive to build.gradle and run Gradle task bootRun, then resource file refreshes immediately when saved. FYI.
I had the same issue , the solution proposed here seems logical and worked for me
in breif :
1- ctrl+shift+A
2- search for registry
3- in the opened dialogue search for "compiler.automake.allow.when.app.running"
and check it
http://garywaddell.com/2015/11/20/spring-boot-intellij-idea-not-reloading-static-content/
For eclipse you have to activate the Project -> "Build Automatically" option as a minimum configuration.
What I ended up using was Browsersync with grunt. browsersync and grunt watches your static resources on disk and updates the browser when you edit the files. It acts as a kind of proxy. This way you can see changes in UI immediately without building or restarting anything.
Grunt, browsersync, spring boot and angularjs are configured for you if you use JHipster which I used to setup my project.
Granted this requires a lot more tools than just an IDE and is a lot more complicated so I wouldn't recommend this for every project.
spring-boot-devtools is not the solution to "hot deploy" of edited static htm/js
I configured a web facet inside intellij so that when I use it to edit html/js file inside resources/static, intellij then knows to copy the updated file to ./target and the spring boot application I have launched inside the automatically displays that content
see
https://www.jetbrains.com/help/idea/2016.2/configuring-static-content-resources.html
The Java version of #viator 's answer:
#Configuration
class WebMvcConfigurer extends WebMvcConfigurerAdapter {
#Override
public void addResourceHandlers(ResourceHandlerRegistry registry) {
registry.addResourceHandler("/dist/*.js").addResourceLocations(
"file:src/main/typescript/dist/"
);
}
}
You can do it by just adding one more dependency
you Gradle
compile group: 'org.springframework.boot', name: 'spring-boot-devtools', version: '1.3.0.RELEASE'
In you Pom.xml
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-devtools</artifactId>
<version>1.3.0.RELEASE</version>
</dependency>
You have two possebilities how to serve static webcontent
From the classpath (per default src/main/resources/static
or src/main/resources/public or META-INF/resources/)
From the file system (per default src/main/webapp)
If you pick solution 1) - you can safely copy the jar around as the static web content is within that jar. If you want that the server picks up changes, you need to do (auto)hotswapping.
If you pick solution 2) - everything will work out of the box, every change will be automatically picked up. HOWEVER - if you copy the final jar to a different location - things will stop working. That is unless you specify an absolute path in application.properties. For example:
spring.resources.static-locations=file:///C:/myspringbootapp/src/main/webapp
So solution 2) is easier but less portable. Solution 1) is portable but more difficult to use(ide config).
For Spring Boot 2+ with gradle Kotlin dsl:
tasks.bootRun {
sourceResources(sourceSets.getAt(SourceSet.MAIN_SOURCE_SET_NAME))
}
thanks to #briskr's answer for the gradle dsl version :)
I had the same problem with live reloading of static contents in my SpringBoot porject: Now from various solutions posted in StackOverflow, I am able to get the solution. Following are the tools I used for development: IntelliJ Idea & Google Chrome in Ubuntu 18.04
I did the following:
Kept the templates folder in resourses folder itself. (Some solutions I found it to be kept in webapp folder under the main, but I did not get the result)
Add this configuration
<addResources>true</addResources>
</configuration>
to spring-maven-plugin in your POM file.
3.Please don't forget to add this dependency to POM file
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-devtools</artifactId>
<scope>runtime</scope>
<optional>true</optional>
</dependency>
Add the Live Reload extension to your web browser.
Restart the server using ' mvn clean spring-boot:run ' (only then the changes will be reflected in the build). During server startup you can see the message Live Server started at ....
Load the page using localhost:8080/... and click the LiveReload extension to connect it with the server.
Make any change to your static HTML file in the resources/ templates folder. Save it and check the webbrowser again, it will be reflected there...
I've read some questions here about how to set a property (most of them talked about the version number for an application) from a maven plugin.
It seems there's no easy way of doing this and the best solution I found is to have a filter.properties file which is updated from the plugin and used by the main pom file to filter the desired resources.
I tried another solution after I read this from the Maven documentation (Maven filter plugin):
Variables can be included in your resources. These variables, denoted
by the ${...} delimiters, can come from the system properties, your
project properties, from your filter resources and from the command
line.
I found interesting that variabled can be read from system properties. So, I modified my plugin to set a system property like this:
System.setProperty("currentVersion", appCurrentVersion);
However, filtered resources don't seem to read this value.
Could anybody tell me what's wrong with this approach?
UPDATE: I'm running my plugin in the validate phase.
Thanks a lot.
Don't set it as System Property, set it as Maven Project property
// inject the project
#Parameter(defaultValue = "${project}")
private org.apache.maven.project.MavenProject project;
// and in execute(), use it:
project.getProperties().setProperty("currentVersion", appCurrentVersion);
See:
Mojo Developer Cookbook
MavenProject javadoc
An edit suggested using Properties.put() instead of Properties.setProperty(). While technically, Properties implements Map, this usage is discouraged explicitly in the Properties javadoc.
Maven sets properties in initialize phase. I assume that in that phase maven loads system properties. And after that maven doesn't load system properties again. If you try to add a system property after this phase than it's not loaded.
Try to run your plugin in validate phase.
I'm trying to set up integration tests for a Maven project that produces a war file. (As seen here http://docs.codehaus.org/display/JETTY/Maven+Jetty+Plugin/.) However I the war file requires a bunch of .properties files on the classpath, that I don't want to bundle in the war.
Is there a way (preferably through plugin configuration) to add a folder to the classpath used by jetty?
I Googled this and found http://markmail.org/message/awtqrgxxttra3uxx but this, as far as I can tell, does not actually work at all. The .properties files are not found.
This should be possible using the webAppConfig configuration element (sample below taken from this thread):
<webAppConfig>
<contextPath>/nportal</contextPath>
<!-- All I want to do here is add in the /etc/jetty/classes for runtime files. For some reason I have to also add back in the /target/classes directory -->
<extraClasspath>${basedir}/target/classes/;${basedir}/etc/jetty/classes/</extraClasspath>
</webAppConfig>
If you find that the above solution doesn't work for you, consider including the test classpath into your Jetty configuration.
<configuration>
<useTestClasspath>true</useTestClasspath>
...
</configuration>
This will then allow you to place all manner of resources/classes on the test classpath and have them visible to the Jetty server without them creeping into the production code.
You can place your additional configuration files under /src/test/resources and set a property <useTestScope>true</useTestScope> in the plugin configuration as specified here:
useTestScope
If true, the classes from testClassesDirectory and dependencies of scope "test" are placed first on the classpath. By default this is false.