How to hot redeploy non-active maven project via jetty-maven-plugin - maven

I'm trying to evaluate jetty for rapid development or project which is currently running on tomcat. My configuration looks like
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>9.2.3.v20140905</version>
<configuration>
<scanIntervalSeconds>3</scanIntervalSeconds>
<webApp>
<descriptor>${project.build.directory}/${project.build.finalName}/WEB-INF/web.xml</descriptor>
<resourceBases>
<directory>${basedir}/src/main/webapp</directory>
<directory>${basedir}/../SharedWeb/src/main/webapp</directory>
</resourceBases>
<allowDuplicateFragmentNames>true</allowDuplicateFragmentNames>
<contextPath>/test</contextPath>
</webApp>
</configuration>
</plugin>
I have main war depending on SharedWeb war via war overlay mechanism. I specify resourceBases for both maven projects so changes in resources are scanned automatically and reloaded on the fly and all working fine. Also when I compile classes in main war, jetty restarts automatically, reloading the latest changes. But when I try to change any class in SharedWeb project and compile it, the class is not reloaded. I'm just wondering if there is a way to make embed jetty to reload classes from SharedWeb automatically? I understand that jetty-maven-plugin uses SharedWeb war from local maven repository, so I need to install SharedWeb artifact before I can see any changes. So I don't have high expectations, but maybe I'm missing something.

Ivan,
The plugin is using the classes and resources from your dependency
war, NOT from the that you have added. The
simply tells jetty to watch that location and redeploy if something in
it changes - it does NOT put it onto the classpath.
You need to tell jetty to use the classes and resources from your
dependency war's project, NOT the war artifact.
So do something like:
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>9.2.3.v20140905</version>
<configuration>
<webApp>
<!-- tell jetty to use the classes from the dependency
webapp project directly -->
<extraClassPath>${basedir}/../SharedWeb/target/classes</extraClassPath>
<!-- tell jetty to use both this project's static
resources, and those of the dependency webapp project -->
<resourceBases>
<directory>${basedir}/src/main/webapp</directory>
<directory>${basedir}/../SharedWeb/src/main/webapp</directory>
</resourceBases>
</webApp>
<scanIntervalSeconds>3</scanIntervalSeconds>
<!-- tell jetty to watch the dependency webapp project classes
dir for changes -->
<scanTargets>
<scanTarget>${basedir}/../SharedWeb/target/classes/</scanTarget>
</scanTargets>
</configuration>
</plugin>
Jan

Since there doesn't seem to be a good prior answer that is specific enough for this question (aka <scanTarget>) I'll just post this new one and tweak the title to make it easier to find in the future.
What you are looking for is <scanTarget>, as that will allow you to customize the scanning locations for changed content that will trigger a hot redeploy.
The jetty-maven-plugin intentionally does not set this up for custom <resourceBases> as there are far to many legitimate use cases where this can cause aggressive / too often / or infinite redeploys. It was decided that it was best to break from "convention over configuration" for <scanTarget> entries and allow the developers to decide what should be scanned for changes.
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>9.2.3.v20140905</version>
<configuration>
...
<scanIntervalSeconds>3</scanIntervalSeconds>
<scanTargets>
<scanTarget>${basedir}/../SharedWeb/src/main/webapp/</scanTarget>
<scanTarget>${basedir}/../SharedWeb/target/classes/</scanTarget>
</scanTargets>
</configuration>
</plugin>

Related

Hot deployment failure with Maven jetty plugin on Windows

I have configured the Jetty Maven plugin to run my compiled war.
Here is the relevant part of my pom.xml.
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>9.4.50.v20221201</version>
<configuration>
<war>${jway.webapps.dir}/myapp.war</war>
<scanIntervalSeconds>2</scanIntervalSeconds>
</configuration>
</plugin>
If I execute mvn jetty:run-war, my war is build and Jetty serves the app as expected.
I have configured scanIntervalSeconds to allow hot redeploy.
However, if I rebuild using mvn install, I get the following error during redeployment:
java.lang.IllegalStateException: Failed to delete temp dir F:\...\myproject\target\tmp
at org.eclipse.jetty.webapp.WebInfConfiguration.configureTempDirectory (WebInfConfiguration.java:532)
at org.eclipse.jetty.webapp.WebInfConfiguration.resolveTempDirectory (WebInfConfiguration.java:424)
at org.eclipse.jetty.webapp.WebInfConfiguration.preConfigure (WebInfConfiguration.java:140)
at org.eclipse.jetty.webapp.WebAppContext.preConfigure (WebAppContext.java:488)
at org.eclipse.jetty.webapp.WebAppContext.doStart (WebAppContext.java:523)
at org.eclipse.jetty.maven.plugin.JettyWebAppContext.doStart (JettyWebAppContext.java:397)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start (AbstractLifeCycle.java:73)
at org.eclipse.jetty.maven.plugin.JettyRunWarMojo.restartWebApp (JettyRunWarMojo.java:113)
at org.eclipse.jetty.maven.plugin.AbstractJettyMojo$1.filesChanged (AbstractJettyMojo.java:472)
at org.eclipse.jetty.util.Scanner.reportBulkChanges (Scanner.java:848)
at org.eclipse.jetty.util.Scanner.reportDifferences (Scanner.java:765)
at org.eclipse.jetty.util.Scanner.scan (Scanner.java:641)
at org.eclipse.jetty.util.Scanner$1.run (Scanner.java:558)
at java.util.TimerThread.mainLoop (Timer.java:555)
at java.util.TimerThread.run (Timer.java:505)
It seems that Jetty wants to delete the file, but Windows locks the file. In the plugin documentation, I have not found any configuration which seems to be helpful. Furthermore I have nothing found on Google. Is there any way to solve this issue?
I don't know if its relevant, but I do not use the jetty:run goal, because my war is build using a third party tool and I do not have a standard directory structure.
The jetty documentation contains a section about Troubleshooting Locked Files on Windows.
So I updated my plugin config according to the documentation:
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>9.4.50.v20221201</version>
<configuration>
<war>${jway.webapps.dir}/myapp.war</war>
<scanIntervalSeconds>2</scanIntervalSeconds>
<webApp>
<_initParams>
<org.eclipse.jetty.servlet.Default.useFileMappedBuffer>false</org.eclipse.jetty.servlet.Default.useFileMappedBuffer>
</_initParams>
</webApp>
</configuration>
</plugin>

Spring boot: resolve JSPs from jar dependencies

Unfortunately haven't found an answer in official documentation. Maybe what I'm trying to do is not supported event by Tomcat, but still. Is it possible to make spring-boot/Tomcat to resolve JSP pages from .jar file that is in the classpath?
I have a spring-boot (2) application that is packed as a war file. There are a numerous jsp pages in 'webapp/view' folder, and appropriate MVC configuration:
#Configuration
public class MVCConf implements WebMvcConfigurer {
// ...
#Bean
public ViewResolver internalResourceViewResolver() {
return new InternalResourceViewResolver(){{
setPrefix("/view/");
setSuffix(".jsp");
setRedirectHttp10Compatible(false);
}};
}
// ...
}
All these pages are being resolved. Okay.
But. The project is a multi-module maven one. It supports builds with different dependencies (my own modules) depending on maven profiles.
I need to make application to resolve JSPs from those optional dependencies that are included into runtime as jars in a classpath.
And I'm getting Whitelabel error that says that JSP files can not be found.
Is it even possible to make it work? And if it is, than how?
P.S.: I have already tried to make some magic with copying JSPs into "root" spring-boot application itself and it works, but this way is dirty and tricky.
I don't think it is worth to publish the whole pom.xml, but here is the maven-dependency-plugin section that works in my case:
<!-- ... -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>3.1.1</version>
<executions>
<execution>
<phase>generate-resources</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<!-- this skip property is set by maven profile in same pom.xml - no magic here -->
<skip>${exclude.some_submodule}</skip>
<artifactItems>
<artifactItem>
<groupId>${project.groupId}</groupId>
<artifactId>some_submodule</artifactId>
<version>${project.version}</version>
<type>jar</type>
<overWrite>true</overWrite>
<outputDirectory>${project.build.outputDirectory}</outputDirectory>
<!-- there are webapp/view/*.jsp files in some_module's structure -->
<includes>view/**</includes>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
<!-- ... -->
The only problem here is that it works only when you launch the executable .war. Launching this application from IDE (IntelliJ IDEA) need some additional steps to be made. And that's another one disadvantage of this solution, to my mind. The first one is a dirty pom.xml.
TL;DR
Solution:
BUT!. I have found another solution that is more suitable, I think.
Actually I have moved from Tomcat to Jetty, and solution above works fine even there. There's no need in hacking the build anymore.
Now I put my .jsp files into src/main/webapp/META-INF/resources/view/some_module folder in some_module dependency and resolve it by path 'some_module/someJsp' via standard Spring's #Controllers.
I apologize that I haven't found this topic earlier. Now this is a duplicate. But who knows, maybe someone will apply solution with maven dependency plugin.

Required to create Maven plugin or 'some kind of wrapper' or should I use a parent pom

We are using the frontend-maven-plugin in several (10+) projects.
These projects are build in combination with our own CMS. These projects are using a specific 'parent' in the pom, such as:
<parent>
<groupId>nl.companyname</groupId>
<artifactId>companyname-corporate-pom</artifactId>
<version>2.0.13</version>
</parent>
In this 'corporate pom', we have some predefined configuration and 'plugin management', such as:
<project.frontendmavenplugin.version>1.3</project.frontendmavenplugin.version>
<project.frontendmavenplugin.workingDirectory>./</project.frontendmavenplugin.workingDirectory>
<project.node.downloadRoot>http://nodejs.COMPANYURL.nl/dist/</project.node.downloadRoot>
<project.node.version>v6.9.1</project.node.version>
<project.yarn.version>v0.17.9</project.yarn.version>
<project.yarn.downloadRoot>http://yarnpkg.COMPANYURL.nl/</project.yarn.downloadRoot>
<project.npm.registryUrl>http://nexus.COMPANYURL.nl/content/groups/npm-all/</project.npm.registryUrl>
and
<build>
<pluginManagement>
<!-- Generic configuration for plugins used by (almost) all projects. -->
<plugins>
<plugin>
<groupId>com.github.eirslett</groupId>
<artifactId>frontend-maven-plugin</artifactId>
<version>${project.frontendmavenplugin.version}</version>
<executions>
<execution>
<id>install node and yarn</id>
<goals>
<goal>install-node-and-yarn</goal>
</goals>
<phase>generate-resources</phase>
<configuration>
<workingDirectory>${project.frontendmavenplugin.workingDirectory}</workingDirectory>
<nodeVersion>${project.node.version}</nodeVersion>
<nodeDownloadRoot>${project.node.downloadRoot}</nodeDownloadRoot>
<yarnVersion>${project.yarn.version}</yarnVersion>
<yarnDownloadRoot>${project.yarn.downloadRoot}</yarnDownloadRoot>
</configuration>
</execution>
etc.
This way we don't have to copy/manage all configuration in each project.
This works great.
But: we are now also creating more and more new applications (based on Spring Boot) which are independent from our CMS and where we cannot use this 'parent pom' because Spring Boot has it's own (spring-boot-starter-parent) and our 'corporate pom' also contains very specific plugins / configuration which only applies to our CMS (which we are not including in these Spring Boot projects).
So what I need is something more 'standalone' for the frontend-maven-plugin configuration (and maybe in the future more 'platform' independent config/plugins). As far as I know, it's not possible to have more then 1 parent, so are there any other options?
I thought of creating a new 'companyname-frontend-maven-plugin' which both contains the PluginManagement as all the (extendable) configuration for the Frontend Maven Plugin. But I don't know if this will work and also it's a lot of work creating and maintaining this in git / Jenkins etc.
Are there any other options I could look in to?
Thank you all for your time!
maybe you can use a profile.
You can create a "corporate" pom that inherit from spring-boot-starter-parent and that contains a maven profile with all the properties and plugins required by your cms. So, when you are working on the CMS you will enable the "cms-profile".
Kind regards.

How do I get maven to use the JNLP version naming convention?

I've been tasked with reducing the download size of one of our webstart apps. I've figured that a decent portion of the download is from all a largish library of jar files, and since we rarely update many of them, it seems the download will be reduced significantly using the JNLP Version Download Protocol. This should stop the continual re-download of the same jars when a new version of the app is released.
Now, the project is build with maven. Part of the process is automatically generating a JNLP file from a velocity template. The resources section of the JNLP file is populated by a $dependencies variable assumedly passed in by maven and looks something like this:
<jar href="lib/mainjar-0.1.40-SNAPSHOT.jar" main="true"/>
<jar href="lib/somejar-1.1.jar"/>
<jar href="lib/someotherjar-1.0.jar"/>
<jar href="lib/anotherjar-1.6.0.jar"/>
etc...
It seems to me that maven is using its standard naming convention and constructing the jar names from the artifactId and version tags out of the project pom files.
How can I get it to use the JNLP naming convention instead?
I can change the velocity template to cut the $dependencies variable up and re-combine it with the JNLP convention - but that's only halfway what I need since the actual jar names need to be changed too.
The version download protocol article is about speeding up the check that resources are up to date. Although it may be useful as well, it is not the part that prevents re-downloading of the same files.
Webstart-maven-plugin can take care of versioning of the jars for you and they declare they use the version protocol as well. See http://www.mojohaus.org/webstart/webstart-maven-plugin/jnlp-mojo.html#outputJarVersions
My personal experience differs from what the docs say. It adds the version attribute for jars in the resulting jnlp and does not set the jnlp.versionEnabled property, which seems to be required for the version download protocol. Either way JWS works as I would expect - files are not re-downloaded when their version does not change.
Plugin setup:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>webstart-maven-plugin</artifactId>
<version>1.0-beta-6</version>
<dependencies>
<!--This dependency definition resolves class loading issue on Java 8 -->
<dependency>
<groupId>org.codehaus.mojo</groupId>
<artifactId>keytool-api-1.7</artifactId>
<version>1.4</version>
</dependency>
</dependencies>
<executions>
<execution>
<phase>process-resources</phase>
<goals>
<goal>jnlp-download-servlet</goal>
</goals>
</execution>
</executions>
<configuration>
<outputDirectoryName>/</outputDirectoryName>
<libPath/>
<sign>
<keystore>${basedir}/foo-key-store.jks</keystore>
<storepass>password</storepass>
<alias>foo-self-signed</alias>
<verify>true</verify>
</sign>
<unsign>true</unsign>
<jnlpFiles>
<jnlpFile>
<inputTemplate>template.vm</inputTemplate>
<outputFilename>foo.jnlp</outputFilename>
<jarResources>
<jarResource>
<groupId>foo.bar</groupId>
<artifactId>foo</artifactId>
<version>${project.version}</version>
<mainClass>foo.bar.Foo</mainClass>
<outputJarVersion>false</outputJarVersion>
</jarResource>
</jarResources>
</jnlpFile>
</jnlpFiles>
<gzip>true</gzip>
</configuration>
</plugin>
Excerpt from the generated foo.jnlp showing the version attribute of a dependency:
<jar href="commons-collections.jar" version="3.2.1"/>
And the file it references is named:
commons-collections-3.2.1.jar

Best way to hand a WAR file from one Maven project to another, to use with Embedded Jetty?

I thought this was simple, but having problems:
Project1 is of type war. It creates an entire webapp .war file, including some Apache modules (solr/lucene), and some of our custom code.
Project2 is an existing application. It needs to launch embedded Jetty to do queries against Project1's war file. (see code below)
Main Problem:
When Project2 instantiates Jetty, it needs to pass in the full path to the WAR file, but this changes each time. Maven adds version number stuff to Project1's war file.
Assemblies to the Rescue?
I'm able to get a custom assembly to work, but can't get rid of the versioning stamp from Project1.
But I always wind up with Project1-1.4.1-20120530.233546-2.war. It's in a more convenient place, but the name is still weird.
Jetty code in Project2:
// Context
WebAppContext webapp = new WebAppContext();
webapp.setContextPath("/");
String jettyHome = System.getProperty( "jetty.home", ".." );
String fullWarName = ...; // Project1's WAR file. This path always changes
webapp.setWar( fullWarName );
// Server
Server server = new Server( kPort ); // TODO: get from config
server.setHandler(webapp);
server.start();
server.join();
Other considerations:
I realize there is a maven-jetty plugin, but I don't believe that's appropriate here. It seems to be targeted at Unit tests, and also our application stack doesn't use maven at runtime to launch services.
I'm also aware that Solr has a fully embedded version that doesn't require a web container, but that's been deprecated for a while and not a good idea to use.
Is there a better way to refactor this project? Maybe this isn't "the maven way" ?
It turns out I didn't need an assembly (advice I had got internally), instead there's something easier in the main pom. Also, having the war unpacked here turned out to be a nice idea.
At the top of Project1's pom.xml I have:
<groupId>com.my.group</groupId>
<artifactId>project-one</artifactId>
<version>1.2.3-SNAPSHOT</version>
<packaging>war</packaging>
This goes near the bottom of Project2's pom.xml
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>unpack-webapp</id>
<phase>package</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>com.my.group</groupId>
<artifactId>project-one</artifactId>
<version>1.2.3-SNAPSHOT</version>
<type>war</type>
<overWrite>true</overWrite>
<outputDirectory>${project.build.directory}/webapps/project-one</outputDirectory>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
Then when launching Jetty I have:
webapp.setWar( "target/webapps/project-one" );
I still think there might be issues with some Jetty settings, but I think this is the right direction.

Resources