I have an application composed of multiple maven war projects.
I have another maven project that runs JUnit integration tests against the manually-started tomcat-deployed multi-war application using org.springframework.web.client.RestTemplate calls.
However, I'd like my integration test project to actually start my multi-war application (once for the duration of the entire suite) before it runs my tests...in spring-boot!
From my integration test project, I'd like to be able to run all the war projects together as a spring-boot application, each with their own contextPaths (e.g. localhost:8080/a for project 'a', localhost:8080/b for project 'b', etc. ), and without changing the original war projects (that are not (yet) spring-boot aware). If I can't make these projects run from my integration test project in spring-boot without changing them then I'd at least like to minimize the use of spring-boot dependencies and configuration in packaged war files...as much as possible.
I was able to get my integration test project to depend on a single war project, start it up and run tests against it...but I was unsuccessful getting two war projects running together in spring-boot under separate contextPaths.
Any suggestions would be welcome!
Here are some of the resources I've been using to put this together:
(Spring-boot documentation) http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-testing.html
(Blog post touching on starting spring app once for test suite) http://www.nurkiewicz.com/2010/12/speeding-up-spring-integration-tests.html
(Suggestions for including war files as dependencies in a integration test project pom) http://eureka.ykyuen.info/2009/10/30/maven-dependency-on-jarwar-package/
As per Andy's suggestion, I went with the Tomcat7 Maven Plugin and it worked just fine. The Jetty Maven Plugin was another option (and better documented IMO) although I couldn't find a way to avoid having to provide a "path" to my WAR files. The Tomcat7 Maven Plugin, let me load up my WARs from my local .m2 repository. I should also say that the following links were helpful as well...
http://cupofjava.de/blog/2013/02/05/integration-tests-with-maven-and-tomcat/
https://stackoverflow.com/a/16936585/1098564
Here's part of my integration test project pom...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.17</version>
<configuration>
<skipTests>true</skipTests>
</configuration>
</plugin>
<plugin>
<artifactId>maven-failsafe-plugin</artifactId>
<version>2.17</version>
<configuration>
<includes>
<include>**/*Test*</include>
</includes>
</configuration>
<executions>
<execution>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.2</version>
<configuration>
<path>/</path>
<webapps>
<webapp>
<groupId>com.mycompany</groupId>
<artifactId>app1</artifactId>
<version>${project.version}</version>
<type>war</type>
<asWebapp>true</asWebapp>
</webapp>
<webapp>
<groupId>com.mycompany</groupId>
<artifactId>app2</artifactId>
<version>${project.version}</version>
<type>war</type>
<asWebapp>true</asWebapp>
</webapp>
</webapps>
</configuration>
<executions>
<execution>
<id>start-tomcat</id>
<phase>pre-integration-test</phase>
<goals>
<goal>run-war</goal>
</goals>
<configuration>
<fork>true</fork>
</configuration>
</execution>
<execution>
<id>stop-tomcat</id>
<phase>post-integration-test</phase>
<goals>
<goal>shutdown</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
Related
I am trying to create an executable jar with my test. I cannot use maven to run the tests so I am trying to create a jer that will execute them.
I have a jar with all the test's and with all dependencies. But, when I try to run:
java -jar target/tests-0.0.1-SNAPSHOT-spring-boot.jar
I am getting -
Exception in thread "main" java.lang.ClassNotFoundException: com.xxx.xx.tests.framework.SDAutomation
at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at org.springframework.boot.loader.LaunchedURLClassLoader.loadClass(LaunchedURLClassLoader.java:93)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
pom.xml include the following to create the jar:
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<classifier>spring-boot</classifier>
</configuration>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals> <goal>single</goal> </goals>
<configuration>
<archive>
<manifest>
<mainClass>com.xxx.xx.tests.framework.SDAutomation</mainClass>
</manifest>
</archive>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
</plugin>
Any help will be great.
Edit 1:
found a seleution by creating a main with LauncherFactory
for example:
LauncherDiscoveryRequest request = LauncherDiscoveryRequestBuilder.request()
.selectors(
selectClass(SDAutomation.class)
)
.build();
Launcher launcher = LauncherFactory.create();
// Register a listener of your choice
SummaryGeneratingListener listener = new SummaryGeneratingListener();
launcher.registerTestExecutionListeners(listener);
launcher.execute(request);
TestExecutionSummary summary = listener.getSummary();
taken from juint doc
Spring boot works with a Jar which is not a Jar really. When you use spring-boot-maven- plugin - you instruct maven to prepare such a spring boot jar. I suggest to open this jar with some kind of WinRar/WinZip application and see what's inside actually.
So, if you have a spring boot jar and try to run it as a spring boot application it will load the main class and run it.
This main class should run programmatically all the automation tests and If I understand correctly this is exactly what SDAutomation is supposed to do.
But then you use maven assembly plugin and try to edit its manifest and specify the main plugin - do not do it. Instead specify the main class in a spring boot plugin. So this is clearly a mistake
The third step is even more confusing - you create a test jar, that's cool, but where do you use it?
So how to really solve this issue:
You should decide whether you want to use spring boot at all to run tests. Frankly I don't see a point of doing so - you could create a fat jar of all the dependencies and run tests from there. Unless these tests are not designed as #SpringBootTest which is also doesn't make sense for automation tests, here is why:
Spring Boot Test is an integration framework as opposed to automation tests which are usually cover the end to end flow. Automation tests run in the different JVM as the application as opposed to spring boot tests that provide a lot of convenience features for loading the application context of the real application inside of the test (or a part of application context). Automation tests should not load any production code at all... Probably if you could elaborate more on the purpose of the automation test suite - I could provide more information.
Even if you run the spring boot application, it should not be the same spring boot application that runs the production code. Probably you should create another maven module, provide a dependency on the artifact with a test classifier and in the main method use console application (again, no web server in this case is required) to run the test suite.
Last but not the least. Surefire/failsafe plugins of maven besides actually running the tests, also produce reports that can be integrated with a CI tool. Since you won't have any maven / surefire there (from your comment) you won't be able to benefit from these reports.
Below are steps ->
Step 1: Add the below plugins to your POM file -
<build>
<finalName>dockerized-springfield</finalName>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>3.1.0</version>
<executions>
<execution>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.0</version>
<configuration>
<release>11</release>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>prepare-package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>
${project.build.directory}/libs
</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.18.1</version>
<configuration>
<suiteXmlFiles>
<suiteXmlFile>src/test/java/com/automation/framework/gui/testng.xml</suiteXmlFile>
</suiteXmlFiles>
<argLine>
-javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar"
</argLine>
<classpathDependencyExcludes>
<classpathDependencyExclude>com.vaadin.external.google:android-json</classpathDependencyExclude>
</classpathDependencyExcludes>
</configuration>
</plugin>
</plugins>
</build>
Step 2: Run mvn commands to create jars
mvn package -DskipTests
This will create 3 jars files inside your target folder
application.jar [Springboot jar which contains code inside "main" folders along with the dependencies.]
application.jar.original [Jar which ONLY contains code inside "main" folders]
application-tests.jar [Jar which contains code inside the "test" folder.]
We only need the 2nd and 3rd jar files. You may delete the first file.
Now rename the second file and remove the ".original" from its file name. Let's say mainapplication.jar
We will also need the libs folder which contains jar files for respective dependencies mentioned in the POM file.
Step 3: Run your jar files.
java -cp mainapplication.jar:application-tests.jar:libs/* org.testng.TestNG testng.xml
I am trying to run integration testing on my maven project inside a docker container. I am using dockerfile-maven plugin to move jar file inside my docker container and maven-failsafe-plugin to initiate my integration testing. But somehow integration testing starts before docker being built. Also it doesn't call my test functions.
Here is my pom.xml snippet.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>2.12</version>
<executions>
<execution>
<goals>
<goal>integration-test</goal>
</goals>
<configuration>
<includes>
<include>**/*.java</include>
</includes>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>com.spotify</groupId>
<artifactId>dockerfile-maven-plugin</artifactId>
<version>1.3.7</version>
<executions>
<execution>
<id>default</id>
<goals>
<goal>build</goal>
<goal>push</goal>
</goals>
</execution>
</executions>
<configuration>
<repository>rohitbarnwal7/presto_him</repository>
<tag>${project.version}</tag>
<buildArgs>
<JAR_FILE>plugin-${project.version}-jar-with-dependencies.jar</JAR_FILE>
</buildArgs>
</configuration>
</plugin>
Update: With above configuration, integration test class are being called but none of the test is actually executed.
Any help will be highly appreciated. Thanks.
You need to bind the building of the image to a maven phase that runs before integration test.
As documented in Bind Docker commands to Maven phases, you can bind building the docker image to a specific maven phase as such:
build-image
compile
package
In this case, building the image will take place at the maven package phase which will run before integration-test phase
Between version 1.3.8.RELEASE of the spring-boot-maven-plugin and version 1.4.0.RELEASE - there has been a change in the generated package structure (if you extract the uber jar file)
1.3.8.RELEASE com, lib, META-INF and org directories
1.4.0.RELEASE has a BOOT-INF, META-INF and org directories
Basically from 1.4.0.RELEASE onwards - all the classes and libs are in the BOOT-INF directory.
Due to this - when you try to run a Spring Boot project on Amazon Lambda - it says that there is a jar not found as it cannot read the new Spring Boot Uber jar structure
My question is - is it possible in the newer versions of the Spring Boot Maven Plugin to get it to generate the uber jar to be the same structure as in version 1.3.9.RELEASE?
I tried the maven-shade-plugin - but that leads to other issues
Any help is greatly appreciated
Thanks
Damien
The solution was to add the MODULE layout for the plugin in the pom.xml file
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<layout>MODULE</layout>
</configuration>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>
In my case I'm using spring boot 2.X and I declared the spring-boot-maven-plugin after the maven-dependency-plugin (which I used to unpack and create exploded app in Docker) and it must be before the unpack, makes sense, it was unpacking before the spring boot maven plugin executed. Next time I'll declare it first thing in the plugin chain, lost more than 1 hour on this. Hope it helps someone.
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<mainClass>${spring.boot.mainClass}</mainClass>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>unpack</id>
<phase>package</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>${project.groupId}</groupId>
<artifactId>${project.artifactId}</artifactId>
<version>${project.version}</version>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
The answer above with
<layout>MODULE</layout>
does not work anymore, this is because layout element is deprecated in Spring Boot 2.x.
I am using Spring Boot 2.0.x, I found this helpful comment on github:
Support for the module layout was removed in Spring Boot 2.0 having been deprecated in 1.5. Unfortunately, the updates to the Maven Plugin's documentation were missed so we can use this issue to sort that out. You should use a custom LayoutFactory instead.
But as I did not want to implement LayoutFactory I tried this second solution below that actually repackage and creates an extra jar with a classifier given name:
This is due to the change in layout of executable jars in Spring Boot 1.4. Application classes are now packaging in BOOT-INF/classes.
Your client module depends on the repackaged, fat jar of your web module. Due to the new layout that means that the client module can no longer load the web module's classes. If you want to use your web module as a dependency, you should configure Boot's repackaging to apply a classifier to the fat jar. For example:
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
<configuration>
<classifier>exec</classifier>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
Doing so will allow other modules to depend on the original jar that does not embed the module's dependencies and has the classes at the root of the jar.
One original jar have the same structure as I wanted like
com.my-package.foo.bar
META-INF
and the second classifier have the newer structure with BOOT-INF/ etc.
For me, the solution was a bit more insidious....I had the spring-boot-maven-plugin nested under pluginManagement, (see below). Doh!
The nasty thing, is that when I'd run mvn spring-boot:run, spring boot comes up just fine, and runs app! It wasn't until we tried to deploy to PCF (as a spring-boot JAR), that we'd get an error that there was something wrong with format of the binary....
<build>
<!--
DON'T DO THIS!!
-->
<pluginManagement>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>${spring.boot.version}</version>
<executions>
<execution>
<goals>
<goal>repackage</goal>
<goal>build-info</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
<!--
DO THIS INSTEAD!!
-->
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>${spring.boot.version}</version>
<executions>
<execution>
<goals>
<goal>repackage</goal>
<goal>build-info</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
Once I removed the pluginManagement tags from the POM, I would now get the ./BOOT-INF structure. Please keep in mind that pluginManagement is typically for a parent-pom structure, where you want that plugin's config used across other modules.
I was using Gradle, instead of Maven, and this is what I had to do:
1- In my build.gradle, I added the following properties as defined in https://spring.io/guides/gs/spring-boot-Docker/.
buildscript {
...
dependencies {
...
classpath('gradle.plugin.com.palantir.gradle.docker:gradle-docker:0.13.0')
}
}
group = 'springio'
...
apply plugin: 'com.palantir.docker'
task unpack(type: Copy) {
dependsOn bootJar
from(zipTree(tasks.bootJar.outputs.files.singleFile))
into("build/dependency")
}
docker {
name "${project.group}/${bootJar.baseName}"
copySpec.from(tasks.unpack.outputs).into("dependency")
buildArgs(['DEPENDENCY': "dependency"])
}
2- My dependency folder was not being written to
ARG DEPENDENCY=target/dependency
instead, I located it in another folder, so I changed this property in the Dockerfile:
ARG DEPENDENCY=build/dependency
With this I got a successful build.
I have the following maven configuration
my goal is to replace web-xml for development mode from usual web.xml to web-dev.xml
gwt-maven-plugin seems to have configuration wor it (webXml) but it's not working not as eclipse plugin (run as web application), not when mvn gwt:run.
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>${gwtVersion}</version>
<executions>
<execution>
<goals>
<goal>compile</goal>
</goals>
</execution>
</executions>
<configuration>
<gwtSdkFirstInClasspath>true</gwtSdkFirstInClasspath>
<hostedWebapp>${webappDirectory}</hostedWebapp>
<runTarget>index.html</runTarget>
<style>PRETTY</style>
<webXml>src/main/webapp/WEB-INF/web-dev.xml</webXml>
<inplace>true</inplace>
</configuration>
</plugin>
Despite what the doc says, the webXml configuration parameter is actually only used for the mergewebxml goal (almost useless nowadays).
Try doing things the other way around: web.xml for dev, and a web-prod.xml for prod that you configure in the maven-war-plugin, as gwt:run will copy your src/main/webapp as-is, bypassing any configuration you could have made for the maven-war-plugin.
Some unit tests in my application are related to finding and manipulating certain files resources that are part of the application itself.
I need these tests to be executed in the real production setting of the application, where it is deployed as a JAR file, not as an exploded directory.
How could I instruct Maven to execute my unit tests considering as the classpath the project generated jar file (and any other declared library dependencies) instead of the compiled classes in the file system as it does by default?.
In other words, right now the classpath for my unit tests is set to: /$PROJECTPATH/target/classes/.
Instead, I would like this classpath to be set to: /$PROJECTPATH/target/myjarfile.jar.
I have tried manually adding and removing dependency classes, as explained here:
http://maven.apache.org/plugins/maven-surefire-plugin/examples/configuring-classpath.html
,but until now it is not working.
My current project POM looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>org.mygroupid</groupId>
<artifactId>myartifact</artifactId>
<version>0.0.1-SNAPSHOT</version>
<dependencies>
...
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.1</version>
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>2.1.2</version>
<executions>
<execution>
<id>attach-sources</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.4</version>
<configuration>
<includeScope>runtime</includeScope>
<outputDirectory>${project.build.directory}/lib</outputDirectory>
</configuration>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>process-resources</phase>
<!-- <phase>package</phase> -->
<goals>
<goal>copy-dependencies</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.12.3</version>
<configuration>
<classpathDependencyExcludes>
<classpathDependencyExclude>
${project.build.outputDirectory}
</classpathDependencyExclude>
</classpathDependencyExcludes>
<additionalClasspathElements>
<additionalClasspathElement>
${project.build.directory}/${project.build.finalName}.${project.packaging}
</additionalClasspathElement>
</additionalClasspathElements>
</configuration>
</plugin>
</plugins>
</build>
</project>
Thanks in advance for any help!.
The standard unit tests executed as part of the test lifecycle phase cannot see the project JAR because the test phase is executed before the package phase, so your tests are run before Maven generates the JAR. See this page for a list of lifecycle phases and their order.
What you want it to run your tests as integration tests, which execute in the integration-test phase.
There are a number of tutorials for setting up Maven to run integration tests. Here and here are a couple of starters. The failsafe plugin is typically used for executing integration tests.
I can't recall exactly if integration tests use target/classes or your project's JAR file in the classpath. But if it doesn't you could always create another Maven project, add your tests in there and add the main project as a dependency to this integration test project. In some cases this can be preferable to using the integration test phase in the main project if it is not just a standard Java library, for example if you are writing an annotation processor.