The test results of JUnit tests have a properties tag with a bunch of properties. What is logged seems to be at the discretion of each executor of the tests.
I want to process the XML files further, so it would be really nice to have the same keys each time. For maven-surefire-plugin that's pretty straightforward:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<systemPropertyVariables>
<propertyName>propertyValue1</propertyName>
</systemPropertyVariables>
</configuration>
</plugin>
This adds the line <property name="propertyName" value="propertyValue1"/> to the XML result file.
For the tycho-surefire-plugin, I tried the following:
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>tycho-surefire-plugin</artifactId>
<version>${tycho-version}</version>
<configuration>
<systemPropertyVariables>
<propertyName>propertyValue1</propertyName>
</systemPropertyVariables>
<systemProperties>
<property>
<name>propertyName</name>
<value>propertyValue2</value>
</property>
</systemProperties>
<argLine>-DpropertyName=propertyValue3</argLine>
</configuration>
</plugin>
...but neither of these values is printed inside the XML result.
How do I add information to the JUnit test results using tycho-surefire-plugin?
The documentation of the tycho-surefire-plugin states that you should use the <systemProperties> map:
<configuration>
<systemProperties>
<propertyName>propertyValue1</propertyName>
</systemProperties>
</configuration>
This will start the forked test JVM with -DpropertyName=propertyValue1.
Related
I have the need to create a deployable ZIP archive from a script, much as the "Export" function does in Mule Studio. I'm expecting the ZIP to contain everything needed to deploy the app: JAR files, message flows, etc etc etc - again, just as Mule Studio Export does.
Is there a simple way to do this, or an example I can follow?
Maven is your best bet. Using the mule plugin for maven runnning mvn package will produce the deployable archive. More info on Mule and Maven here: http://www.mulesoft.org/documentation/display/current/Using+Maven+with+Mule
There is also an ant plugin but don't use it myself. Some info here: http://blogs.mulesoft.org/building-mule-apps-with-ant/
Alternatively, you can read about the application deployment structure here: http://www.mulesoft.org/documentation/display/current/Application+Format , so in theory you can build this structure yourself. But I wouldn't advise it and would stick to Maven.
Use Maven for building the app in jar/zip and deploy to the Mule standalone server automatically ... Make Sure your MULE_HOME is set to your standalone server in Environment variable ... and insert the following in your Maven Script to build it in Jar/Zip and deploy to app folder of Mule Standalone directly :-
<build>
<resources>
<resource>
<directory>>${project.basedir}/lib</directory>
<filtering>true</filtering>
</resource>
</resources>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<version>2.3.1</version>
</plugin>
</plugins>
</pluginManagement>
<plugins>
<plugin>
<groupId>org.mule.tools</groupId>
<artifactId>maven-mule-plugin</artifactId>
<version>1.6</version>
<extensions>true</extensions>
<configuration> <!-- This tag sets true/false to copy jar/zip file to Mule server app folder -->
<copyToAppsDirectory>true</copyToAppsDirectory>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
<encoding>ISO-8859-1</encoding>
</configuration>
</plugin>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<finalName>YOUR_APPPLICATION_NAME</finalName>
<descriptors>
<descriptor>assembly.xml</descriptor>
</descriptors>
<appendAssemblyId>true</appendAssemblyId>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-eclipse-plugin</artifactId>
<version>${eclipsePluginVersion}</version>
<configuration>
<!-- by default download all sources when generating project files -->
<downloadSources>true</downloadSources>
<classpathContainers>
<classpathContainer>org.eclipse.jdt.launching.JRE_CONTAINER/${vmtype}/${jdkName}
</classpathContainer>
</classpathContainers>
</configuration>
</plugin>
<!--
make sure that MULE_HOME is set when building (required below when copying the
artifact to Mule's apps directory
-->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.0-beta-1</version>
<executions>
<execution>
<phase>install</phase>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<requireProperty>
<property>env.MULE_HOME</property>
<message>You must set MULE_HOME before installing the example.</message>
</requireProperty>
</rules>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<id>package-example</id>
<phase>install</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<!-- This tag automatically deploy jar/zip file to server -->
<copy file="${project.build.directory}/${project.build.finalName}.zip"
todir="${env.MULE_HOME}/apps" overwrite="true"/>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
I'd like to use a random port for arquillian.
So in arquillian.xml
I do:
<arquillian>
<container qualifier="tomcat7" default="true">
<configuration>
...
<property name="bindHttpPort">0</property>
...
</configuration>
</container>
</arquillian>
In my unit test:
#ArquillianResource
private URL base;
I hope to have the real port (localPort) used by Apache Tomcat (because yes it start with a random port) but this URL is with 0 port the one from configuration not random one.
So how to have access to this?
Are you using Apache Maven to run such tests ?
Here is how I did. On Maven side I'm using the buildhelper plugin and surefire to define the random port and pass it to tests as a system property
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<executions>
<execution>
<id>reserve-network-port</id>
<phase>initialize</phase>
<goals>
<goal>reserve-network-port</goal>
</goals>
<configuration>
<portNames>
<portName>tomcat.http.port</portName>
</portNames>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<systemProperties>
<!-- Port used for Tomcat HTTP connector -->
<tomcat.http.port>${tomcat.http.port}</tomcat.http.port>
</systemProperties>
</configuration>
</plugin>
</plugins>
And then I configured arquillian with
<arquillian>
<container qualifier="tomcat" default="true">
<configuration>
<property name="bindHttpPort">${tomcat.http.port:9090}</property>
</configuration>
</container
</arquillian>
Note : I'm using a default value for the port for when I'm launching the test from my IDE to avoid to have to manually configure it.
HTH
Cheers,
You can use the arquillian-available-port-extension.
Simply add the dependency in your pom
<dependency>
<groupId>com.github.mryan43</groupId>
<artifactId>arquillian-available-port-extension</artifactId>
<version>${arquillian-available-port-extension.version}</version>
</dependency>
and put in your arquillian.xml :
<property name="bindHttpPort">${available.port}</property>
This has the advantage of working both when running in maven and when running in your IDE.
https://github.com/mryan43/arquillian-available-port-extension
I have :
src/main/java/com.tuto
Class1.java
Class2.java
Class3.java
My pom is packaging a war.
So in my war, in WEB-INF/classes/com/tuto I found the 3 classes.
Now I want to exclude Class2.java
I tried
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1</version>
<configuration>
<excludes>
<exclude>**/Class2.class</exclude>
</excludes>
</configuration>
</plugin>
But it's not working.
How can I do ?
Ok, so like Aaron tell me, this is working :
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1</version>
<configuration>
<packagingExcludes>**/Class2.class</packagingExcludes>
</configuration>
</plugin>
But ...
Let's take the problem by the other side : I want to exclude all except Class1 and Class3
So I tried
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1</version>
<configuration>
<packagingIncludes>**/Class1.class,**/Class3.class</packagingIncludes>
</configuration>
</plugin>
and this time it's not working.
As the documentation says, you should use the packagingExcludes element instead.
Note that packagingExcludes doesn't use nested elements. Instead, the content is a "comma-separated list of Ant file set patterns".
From the documentation, excludes will take higher priority over includes. In your case, use packagingExcludes for excluding class2 explicitly.
<packagingExcludes>WEB-INF/classes/com/tuto/Class2.class</packagingExcludes>
The complete plugin xml should be like the following
<plugin>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<outputDirectory>${build.output.directory}</outputDirectory>
<packagingExcludes>WEB-INF/classes/ItemConsumer.class</packagingExcludes>
</configuration>
</plugin>
add plugin to pom.xml - 100% working properly.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.3</version>
<configuration>
<!--package path you want to delete-->
<packagingExcludes>WEB-INF/classes/lk/**</packagingExcludes>
<webResources>
<resource>
<!--project build path-->
<directory>${project.basedir}/target/classes/</directory>
<filtering>true</filtering>
<includes><include>**/*.class</include></includes>
</resource>
</webResources>
</configuration>
</plugin>
I am trying to setup a maven project such that I will be able to run checkstyle using two distinct rule sets: one for main, and one for test. What I would like to do is something along the lines of:
<reporting>
<plugins>
<!-- One configuration for main -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<configuration>
<configLocation>checkstyle</configLocation>
</configuration>
</plugin>
<!-- But a different set of rules for test -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<configuration>
<sourceDirectory>${project.build.testSourceDirectory}</sourceDirectory>
<configLocation>checkstyle-test.xml</configLocation>
</configuration>
</plugin>
</plugins>
</reporting>
I have been successfully able to run one version or the other, but not both at the sames time. Including trying to bind them to different executions phases, but it seems the rule of thumb is the last definition is the only one used.
So I would either like to:
-Ideally - have two seperate checkstyle configuration files that can be run independently
OR
-Have a single checkstyle config, use the config property includeTestSourceDirectory to check main and test at the same time, but have some rules selectively applied to one of main/test or the other.
I have been unable to find any mechanism by which different checkstyle rules can be applied to different source roots at compile time (the other answer may work for report generation, but my needs are specifically compile time checking). The solution implemented is to have the rules that apply to source and then use the checkstyle supressions mechanism to exclude certain rules on the test classes i.e.
<suppress checks="CheckInappropiateForTests" files=".*Test\.java"/>
What about the following:
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>2.6</version>
<reportSets>
<reportSet>
<id>main_checks</id>
<reports>
<report>checkstyle</report>
</reports>
<configuration>
<sourceDirectory>${project.build.sourceDirectory}</sourceDirectory>
<includeTestSourceDirectory>false</includeTestSourceDirectory>
<configLocation>config/maven_checks.xml</configLocation>
<outputDirectory>${project.reporting.outputDirectory}/main-checks/</outputDirectory>
</configuration>
</reportSet>
<reportSet>
<id>test_checks</id>
<reports>
<report>checkstyle</report>
</reports>
<configuration>
<sourceDirectory></sourceDirectory>
<testSourceDirectory>${project.build.testSourceDirectory}</testSourceDirectory>
<includeTestSourceDirectory>true</includeTestSourceDirectory>
<configLocation>config/sun_checks.xml</configLocation>
<outputDirectory>${project.reporting.outputDirectory}/test-checks/</outputDirectory>
</configuration>
</reportSet>
</reportSets>
</plugin>
</plugins>
</reporting>
I found using this tip, applied to checktyle plugin, simpler.
In my case, it looks like this :
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<executions>
<execution>
<id>checkstyle</id>
<goals>
<goal>check</goal>
</goals>
<phase>verify</phase>
<configuration>
<configLocation>some location</configLocation>
</configuration>
</execution>
<execution>
<id>checkstyle2</id>
<goals>
<goal>check</goal>
</goals>
<phase>verify</phase>
<configuration>
<configLocation>some other location</configLocation>
</configuration>
</execution>
</executions>
</plugin>
I'm setting up an integration test module for a good sized web project. The integration test module is separated from the web project itself, and it has it's own pom.
The idea is to use the maven-soapui-plugin to send requests and verify the response. Setting up the soapui-plugin is no hassle. However, I'm having trouble with figuring out how I can tell the jetty-maven-plugin to deploy a war from a remote repository.
If I have understood correctly, the jetty-maven-plugin has a property called '<webApp>/<webApp>' which lets me specify the war file to deploy. The problem is that the war file is not present in the module itself.
I have heard that I can use the maven assembly plugin to retrieve the war from a repository via the projects artifactId, but I am yet to figure out how I would go about doing so.
Here's a summary of what I want:
Retrieve a specific war from a repository or the like, in example via its artifactId.
Deploy this war to the jetty-maven-plugin (goal deploy-war?)
get maven-soapui-plugin to run tests and report the results back in the integration-test phase.
I am pretty sure I've got step 3 covered, but I am very unsure how to achieve step 1 and 2.
Any help is greatly appreciated
It is maybe possible to use dependency:copy to retrieve the war, unpack it and to get the whole thing working with the maven jetty plugin, but this would be hacky and kinda ugly. A cleaner solution would be to use the Maven Cargo plugin and this is my suggestion. Below, a sample POM showing how to retrieve a WAR artifact using its coordinates and how to deploy it on an embedded Jetty container using Cargo:
<dependencies>
<dependency>
<groupId>war group id</groupId>
<artifactId>war artifact id</artifactId>
<type>war</type>
<version>war version</version>
</dependency>
...
</dependencies>
...
<build>
<plugins>
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<configuration>
<!-- Container configuration -->
<container>
<containerId>jetty6x</containerId>
<type>embedded</type>
</container>
<!-- Configuration to use with the container or the deployer -->
<configuration>
<deployables>
<deployable>
<groupId>war group id</groupId>
<artifactId>war artifact id</artifactId>
<type>war</type>
<properties>
<context>war context</context>
</properties>
</deployable>
</deployables>
</configuration>
<!-- Don't wait, execute the tests after the container is started -->
<wait>false</wait>
</configuration>
<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>
</plugin>
...
</plugins>
...
</build>
Finally, just bind the soapui plugin on the integration-test phase.
I'm doing the same thing, John, but I took a different approach with the Jetty plugin. I think the end result is the same. I'm developing an integration-test suite to run against several web service WARs. I'm using dependency:copy in the package phase and then a list of <contextHandler/>s configured for maven-jetty-plugin:
<project>
…
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>copy-wars</id>
<phase>package</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/wars-to-be-tested</outputDirectory>
<stripVersion>true</stripVersion>
<artifactItems>
…
<artifactItem>
<groupId>groupId</groupId>
<artifactId>artifactId</artifactId>
<version>version</version>
<type>war</type>
</artifactItem>
…
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>7.1.3.v20100526</version>
<configuration>
…
<contextHandlers>
…
<contextHandler implementation="org.mortbay.jetty.plugin.JettyWebAppContext">
<war>${project.build.directory}/wars-to-be-tested/artifactId.war</war>
<contextPath>/context</contextPath>
</contextHandler>
</contextHandlers>
</configuration>
<executions>
<execution>
<id>start-jetty</id>
<phase>pre-integration-test</phase>
<goals>
<goal>stop</goal>
<goal>run</goal>
</goals>
<configuration>
<scanIntervalSeconds>0</scanIntervalSeconds>
<daemon>true</daemon>
</configuration>
</execution>
<execution>
<id>stop-jetty</id>
<phase>post-integration-test</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
I would prefer to declare the various wars as dependencies and then use dependency:copy-dependencies to set up the wars-to-be-tested directory; this would allow the Maven reactor to figure out that it needs to build my integration-test module after the wars it'll be testing. The problem I ran into was that the Jetty plugin thought that I wanted to "overlay" all of the wars that were listed as dependencies (a concept that I'd never even heard of until I saw it happen); I don't know if allowing that to happen would have hurt anything, but I didn't like it, so I went with the dependency:copy method.
This is just an alternative to using Cargo. I'll be looking into that myself, but I just wanted to provide another way of doing it.