I have a maven (multi-module) project creating some WAR and EAR files for JBoss AS 7.1.x.
For one purpose, I need to deploy one generated EAR file of one module to a fresh JBoss instance and run it, call some REST web service calls against it and stop JBoss. Then I need to package the results of these calls that were written to the database.
Currently, I am trying to use CARGO and the maven ant run plugin to perform this task.
Unfortunately, I cannot get the three (maven, ant run and CARGO) to play together. I don't have the uberjar that is used in the ant examples of cargo. How can I configure the ant run task so that the cargo ant task can create, start, deploy my JBoss? Ideally the one unpacked and configured by the cargo-maven2-plugin in another phase?
Or, is there a better way to achieve my goal of creating the database?
I cannot really use the integration-test phase, as it is executed after the package phase. So, I plan to do it all in compile phase using ant run.
To clarify again:
I need to do the following: start JBoss; deploy a WAR; wait until the startup of the WAR is complete; deploy an EAR file; wait until the EAR has initialized it's database; Call some web services in the implemented by the EAR; stop JBoss; package the database.
All these steps need to be strictly sequential.
The following part gives you an impression how to do that. You must change the details. In the given case i use a Tomcat. This will download the Tomcat archive uncompress and install Tomcat locally...
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<configuration>
<wait>false</wait>
<container>
<containerId>tomcat${tomcat.major}x</containerId>
<zipUrlInstaller>
<url>http://archive.apache.org/dist/tomcat/tomcat-${tomcat.major}/v${tomcat.version}/bin/apache-tomcat-${tomcat.version}.tar.gz</url>
<extractDir>${project.build.directory}/extract/</extractDir>
<downloadDir>${project.build.directory}/download/</downloadDir>
</zipUrlInstaller>
<output>${project.build.directory}/tomcat${tomcat.major}x.log</output>
<log>${project.build.directory}/cargo.log</log>
</container>
<configuration>
<home>${project.build.directory}/tomcat-${tomcat.version}/container</home>
<properties>
<cargo.logging>high</cargo.logging>
<cargo.servlet.port>9080</cargo.servlet.port>
<cargo.tomcat.ajp.port>9008</cargo.tomcat.ajp.port>
</properties>
</configuration>
</configuration>
<executions>
<execution>
<id>start-container</id>
<phase>pre-integration-test</phase>
<goals>
<goal>start</goal>
<goal>deploy</goal>
</goals>
<configuration>
<deployer>
<deployables>
<deployable>
<groupId>${project.groupId}</groupId>
<artifactId>mod-war</artifactId>
<type>war</type>
<pingURL>http://localhost:9080/mod-war</pingURL>
<pingTimeout>30000</pingTimeout>
<properties>
<context>mod-war</context>
</properties>
</deployable>
</deployables>
</deployer>
</configuration>
</execution>
<execution>
<id>stop-container</id>
<phase>post-integration-test</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
</executions>
</plugin>
Related
actually, I generate a maven site containing the documentation of my project. It works very well, in fact if works so well that my customers wants to get that site as a deliverable (for obvious documentation purpose).
How can I tell Maven to build a zip of the whole site and deploy it to my artifacts manager (Nexus)? I've tried several things, but if I understand correctly, deploying artifacts and generating the site are using different livecycle, and the site generation occurs after the deployment of the artifacts..
I could obviously get the generated site from the location it's deployed during site-deploy, but I would greatly appreciate an automatic and centralized way...
PS: giving access to the customer to our internal site is NOT an option.
Here is a working solution delegated to a Maven profile to isolate the behavior (and speed-up normal builds), but which could also be integrated in the default build if required (although not recommended).
<profiles>
<profile>
<id>site-zip</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-site-plugin</artifactId>
<version>3.4</version>
<executions>
<execution>
<id>pack-site</id>
<phase>prepare-package</phase>
<goals>
<goal>site</goal>
<goal>jar</goal>
</goals>
<configuration>
<attach>false</attach>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>com.coderplus.maven.plugins</groupId>
<artifactId>copy-rename-maven-plugin</artifactId>
<version>1.0.1</version>
<executions>
<execution>
<id>rename-file</id>
<phase>prepare-package</phase>
<goals>
<goal>rename</goal>
</goals>
<configuration>
<sourceFile>${project.build.directory}/${project.build.finalName}-site.jar</sourceFile>
<destinationFile>${project.build.directory}/${project.build.finalName}-site.zip</destinationFile>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.10</version>
<executions>
<execution>
<goals>
<goal>attach-artifact</goal>
</goals>
<phase>package</phase>
<configuration>
<artifacts>
<artifact>
<file>${project.build.directory}/${project.build.finalName}-site.zip</file>
<type>zip</type>
<classifier>site</classifier>
</artifact>
</artifacts>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
What the profile is actually doing:
Configuring an execution of the Maven Site Plugin, attached to the prepare-package phase and running the site and jar goals (as also suggested by #khmarbaise).
Renaming the file from jar to zip via the Copy Rename Maven Plugin
Attaching the zip to the build via the Build Helper Maven Plugin and its attach-artifact goal
As such, running
mvn clean install -Psite-zip
Will also install in your local Maven cache the zipped site. The deploy phase would do the same on your target Maven repository then.
Note that the Maven Site Plugin and the Copy Plugin must be declared in the order above to follow the required flow within the same phase.
Also note that if zip is not a strong requirement, you can then just skip the Copy and Build Helper executions and only use the Maven Site execution. By default the jar created providing the site is already attached to the build (and hence it will be installed and deployed automatically). In order to have the zip, we had to disable this behavior (<attach>false</attach>) and re-attach it via the Build Helper plugin.
The generated zipped has automatically a classifier, which is site in this case.
You can use the maven-site-plugin.
After years of working with Spring, I'm working on a Java EE 7 application with EJB 3.2 and Maven. One thing I would like is to deploy the EJB Jars separately from the web application so I can develop independently. Including the EJB Jars in the WAR causes the app server to redefine the EJBs in the context of the WAR, which I don't want to happen.
The prescribed method is to have maven create a client jar with this directive:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ejb-plugin</artifactId>
<version>2.5.1</version>
<configuration>
<ejbVersion>3.2</ejbVersion>
<generateClient>true</generateClient>
<clientExcludes>
<clientExclude>**/*Impl.class</clientExclude>
</clientExcludes>
</configuration>
</plugin>
I'm excluding any Impls from the Client JAR.
The issue I'm having is that maven isn't installing the client jar during the install phase.
I can install it manually by doing this:
mvn install:install-file -Dfile=foo-1.0-client.jar -DgroupId=com.awesome -DartifactId=foo -Dversion=1.0 -Dpackaging=jar -Dclassifier=client
I fiddled around a lot and came up with this
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ejb-plugin</artifactId>
<version>2.5.1</version>
<configuration>
<ejbVersion>3.2</ejbVersion>
<generateClient>true</generateClient>
<clientExcludes>
<clientExclude>**/*Impl.class</clientExclude>
</clientExcludes>
</configuration>
<executions>
<execution>
<id>package</id>
<phase>package</phase>
<goals>
<goal>ejb</goal>
</goals>
</execution>
<execution>
<id>install</id>
<phase>install</phase>
</execution>
</executions>
</plugin>
</plugins>
However, this isn't proper. This installs the client as a new artifact, not as the same artifact with classifier client. When you include the client in another application, you are supposed to use ejb-client. This looks in your folder that contains the normal artifact, foo-1.0.jar, and looks for something with classifier client.
<dependency>
<groupId>com.awesome</groupId>
<artifactId>foo</artifactId>
<version>${com.awesome.version}</version>
<type>ejb-client</type>
</dependency>
Stumped here, any ideas?
I have a project composed of several modules that uses maven and is automatically uploaded and deployed to a Jenkins application that runs the build and its tests.
There is for example an API module, a server and a client.
Both client and server use the API as dependency to be able to work correctly.
The client connects to the server's web-services through HTTP(s) in normal use.
To be able to function, the server needs to be run on Jetty.
I have unit testing that works and test the client by calling the server's functionality with mocked HTTP requests.
I would like to be able to do some integration testing, to test for example the HTTP (and HTTPS) connection between the 2 entities, testing for timeouts and such, and reproducing the unit testing without resorting to mocked request, to be closer to real use cases.
It seems like such a thing should be easy to do, but I can't find a way to do it simply and in a way that could be automated.
For example, testing manually in my IDE is done by clicking on "run war" on the server project, and "run tests" on my application.
Is there a way to reproduce this simple process in Jenkins so it is done automatically, by Maven configuration or even a Jenkins plugin ?
UPDATE :
I'm trying to make another module that would use the war resulting from the packaging of my server, and run it with Jetty.
Since my server's Jetty configuration is quite complicated, using Spring and https configuration filtered by Maven, I've some problems making it work in my new module because of missing classes and relative paths not working in that context.
Is it possible to run that war like it would have been started in the other module without jumping through hoops of duplicating resources and other dirty tricks ?
For information, the specific Jetty war part of my pom.xml is :
<configuration>
<contextHandlers>
<contextHandler implementation="org.eclipse.jetty.webapp.WebAppContext">
<war>${project.parent.basedir}/cmp-service/cmp-webapp/target/cmp-webapp-1.0-SNAPSHOT.war</war>
<contextPath>/cmp</contextPath>
<persistTempDirectory>true</persistTempDirectory>
<allowDuplicateFragmentNames>true</allowDuplicateFragmentNames>
</contextHandler>
</contextHandlers>
</configuration>
UPDATE 2 :
I managed to build a functioning module that starts jetty and run my integration test with this pom.xml.
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<parent>
<artifactId>parent</artifactId>
<groupId>com.project.test</groupId>
<version>1.0-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId>com.project.test.integration-testing</groupId>
<artifactId>integration-testing</artifactId>
<packaging>jar</packaging>
<name>integration-testing</name>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>9.3.0.M2</version>
<configuration>
<contextHandlers>
<contextHandler implementation="org.eclipse.jetty.webapp.WebAppContext">
<war>
${project.parent.basedir}/myserver/myservice/target/myservice-${project.parent.version}.war
</war>
<contextPath>/cmp</contextPath>
<persistTempDirectory>true</persistTempDirectory>
<allowDuplicateFragmentNames>true</allowDuplicateFragmentNames>
</contextHandler>
</contextHandlers>
<contextXml>
${project.parent.basedir}/myserver/myservice/src/test/resources/jetty/jetty-context.xml
</contextXml>
<jettyXml>
${project.parent.basedir}/myserver/myservice/src/test/resources/jetty/jetty.xml,${project.parent.basedir}/myserver/myservice/src/test/resources/jetty/jetty-ssl.xml,${project.parent.basedir}/myserver/myservice/src/test/resources/jetty/jetty-http.xml,${project.parent.basedir}/myserver/myservice/src/test/resources/jetty/jetty-https.xml
</jettyXml>
<systemProperties>
<systemProperty>
<name>scsf.configuration.file</name>
<value>
${project.parent.basedir}/myserver/myservice/src/main/resources/config/cmpserver.properties
</value>
</systemProperty>
<systemProperty>
<name>org.eclipse.jetty.annotations.maxWait</name>
<value>180</value>
</systemProperty>
</systemProperties>
<systemPropertiesFile>
${project.parent.basedir}/myserver/myservice/src/main/resources/config/cmpserver.properties
</systemPropertiesFile>
<daemon>true</daemon>
<stopKey>STOP</stopKey>
<stopPort>10001</stopPort>
</configuration>
<executions>
<execution>
<id>start-jetty</id>
<phase>pre-integration-test</phase>
<goals>
<goal>start</goal>
</goals>
<configuration>
<scanIntervalSeconds>0</scanIntervalSeconds>
</configuration>
</execution>
<execution>
<id>stop-jetty</id>
<phase>post-integration-test</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<skipTests>true</skipTests>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>2.18.1</version>
<executions>
<execution>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencies>
...
</dependencies>
</project>
You need to add the dependency to your war as provided too.
But (there's always a but) there is a problem when running the verify goal.
When I run verify in my integration-test module, it kind of works.
But when I run the verify goal in the parent, which is supposed to call that exact same verify goal of my integration-test module (if I understand correctly how it works), some paths are treated differently and are resolved as, for example, parent/src/... instead of parent/integration-test/src...
It seems that when running my goal from the parent, the context of the execution changes and causes my application to break when looking for resources and such.
Is there something I didn't understand about how the whole process works and is there a way to make it work ?
UPDATE 3
I've resolved to hack my way into making all my paths into absolute paths, it works, but it doesn't explain that behavior.
You already figured out the basic steps yourself:
create a separate module for integration tests
start an application- or web-server (e.g.jetty) via a suitable maven-plugin (e.g. cargo, wildfly-maven-plugin, etc.) in the pre-integration-test phase
run tests via the maven-failsafe-plugin:integration-test mojo
verify results via the maven-failsafe-plugin:verify mojo
Stephen Connolly, a maven developer, already wrote a great answer about this topic on stackoverflow.
I don't know the jetty-maven-plugin very well, but it seems it doesn't support deploying an existing artifact. Specifying relative or absolute path is definitively not the way to go here. You should probably use cargo instead to deploy to jetty. The cargo configuration could look like this:
<configuration>
<configuration>
<type>runtime</type>
<properties>
<cargo.hostname>testserver</cargo.hostname>
<cargo.servlet.port>8080</cargo.servlet.port>
</properties>
</configuration>
<container>
<containerId>jetty9x</containerId>
</container>
<deployables>
<deployable>
<groupId>your.group.id</groupId>
<artifactId>your-war</artifactId>
<type>war</type>
<properties>
<context>/cmp</context>
</properties>
</deployable>
</deployables>
<deployer>
<type>remote</type>
</deployer>
</configuration>
The cargo documentation has more details.
hth,
- martin
Hello Jay,
Would really like to simplify things in here, why don't you run these jobs in succession? First would be your compile, unit-tests and deploy tasks using Maven. For your integration testing, create another job that would use of plugins like Selenium ( for your web application) and JMeter (for your web services). You can also try other license testing suite like Openscript.
The web service testing will be tricky, since your web service consumer runs on another client. Do you have any slave agents running on the client application? If you have one, run those jobs inside the slave.
I'm trying to use the cargo maven plugin just to start a JBoss AS 7 server from maven, without executing any deployments.
I'm able to start the server but as I can read in cargo pluging documentation the goals cargo:run and cargo:start will deploy automatically the current project if project's packaging is Java EE (WAR, EAR, etc.) and if I'm not using deployable sections in the plugin configuration.
This is my simple cargo plugin section in the pom file:
<plugins>
...
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.4.13</version>
<configuration>
<!-- Container configuration -->
<container>
<containerId>jboss73x</containerId>
<home>${jboss-as.home}</home>
</container>
</configuration>
</plugin>
...
</plugins>
Since I'm not using deployables and the project packaging is war, cargo automatically deploys my project when the server starts.
I would like use the goal cargo:run just to start my local server without deploy any project artifacts.
Is it possible with the cargo maven plugin? Any idea or alternative?
I think that it might not be possible to ask the plugin not to deploy the project in which it is configured, when you are in the case of a deployable archive project.
But what you could do is creating a pom project, with no source in it just the pom.xml, and run your cargo plugin in that project.
My example below starts and stops the cargo plugin when I run the goal install on it :
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>fr.fabien.perso</groupId>
<artifactId>pom-project-tests</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>pom</packaging>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<executions>
<execution>
<id>start-container</id>
<phase>pre-integration-test</phase>
<goals>
<goal>start</goal>
</goals>
</execution>
<execution>
<id>stop-container</id>
<phase>post-integration-test</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
</executions>
<configuration>
<container>
<type>embedded</type>
</container>
</configuration>
</plugin>
</plugins>
</build>
</project>
Yes Yersan, it is possible to start the server without self built artifact deployment. It can be achieved by adding an empty <deployer /> element on the <configuration> tag of the project.
I found the info at the cargo plugin reference site. In addition, I have tested the configuration in my local project to confirm it works.
I am having headaches trying to setup maven-as-plugin.
My goal is to redeploy an ear before running integration tests.
I want this process to be automatic to integrate it into CI.
The server is a JBoss server (AS 7) running remotely.
Thanks to infamous PermGen space issues of Jboss, I need to restart the server before
deploying the ear. Otherwise, the server will explode every 5 runs or so ...
For that purpose, I have tried to setup a goal "shutdown", with reload=true.
The issue is that maven plugin won't wait for it to be finished before running the next goal (cleaning previous artifacts).
Here is an excerpt of my POM :
<!-- Jboss Deploy/undeploy application EAR -->
<plugin>
<groupId>org.jboss.as.plugins</groupId>
<artifactId>jboss-as-maven-plugin</artifactId>
<version>7.5.Final</version>
<configuration>
<!-- JBoss management -->
<hostname>${sanity.tests.jboss.host}</hostname>
<port>${sanity.tests.management.port}</port>
<username>${sanity.tests.jboss.username}</username>
<password>${sanity.tests.management.password}</password>
</configuration>
<executions>
<!-- Reload Jboss to avoid permgen space -->
<execution>
<id>restart</id>
<phase>pre-integration-test</phase>
<goals><goal>shutdown</goal></goals>
<configuration>
<reload>true</reload>
</configuration>
</execution>
<!-- Undeploy previous ear -->
<execution>
<id>undeploy</id>
<phase>pre-integration-test</phase>
<!-- Cleanup : Undeploy -->
<goals>
<goal>undeploy</goal>
</goals>
<configuration>
<matchPattern>rm-app.*.ear</matchPattern>
<ignoreMissingDeployment>true</ignoreMissingDeployment>
</configuration>
</execution>
<!-- Deploy before int test -->
<execution>
<id>deploy</id>
<phase>pre-integration-test</phase>
<goals>
<goal>deploy-artifact</goal>
</goals>
<configuration>
<name>xxxx</name>
<groupId>xxxxx</groupId>
<artifactId>xxxx</artifactId>
<version>${project.version}</version>
</configuration>
</execution>
</executions>
</plugin>
Any help would be much appreciated.
Try running your undeploy first. If that's the only ear on the AS then the reload will most likely be quick enough for the deploy goal to not timeout.
<goals>
<goal>undeploy</goal>
<goal>shutdown</goal>
<goal>deploy</goal>
</goals>
Unfortunately, I do not know how to increase the timeout of the deploy goal.
I had exactly the same issue. switangs suggestion (first undeploy before restarting JBoss) for sure helps. Another thing i did to add some time between server restart and redeployment was to bind the undeploy and restart of the server to a very early step of the build process (e.g. initialize), whereas the deployment step was bind to process-resources or pre-integration-test as in your case. That worked because i was deploying my artifacts in a separate integration test module, which first copied all relevant server artifacts with maven-dependency-plugin plugin to the ${project.build.directory}/dependency folder as one of the first steps.
But i agree that this is not a very good solution, a blocking restart cli command for standalone JBoss nodes would be much better.
In fact, the shutdown goal won't solve the PermGen issue.
I worked this out by use cli.
<plugin>
<groupId>org.jboss.as.plugins</groupId>
<artifactId>jboss-as-maven-plugin</artifactId>
<version>7.5.Final</version>
<configuration>
<afterDeployment>
<commands>
<command>/host=master:shutdown(restart=true)</command>
</commands>
</afterDeployment>
<!-- your configuration -->
...
</configuration>
<plugin>
and "master" is the name of host in domain mode.