The Console Launcher that comes with JUnit Platform (from JUnit 5) produces a quite nice summary view at the end. The Maven Surefire plugin, however, has a very simple output.
Is it possible to create with Surefire output similar to what the launches creates?
My current workaround is to disable surefire and use exec-maven-plugin to manually run ConsoleLauncher:
<!-- disable surefire -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version><!-- ... --></version>
<executions>
<execution>
<id>default-test</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
<!-- enable ConsoleLauncher -->
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version><!-- ... --></version>
<executions>
<execution>
<phase>test</phase>
<goals><goal>java</goal></goals>
<configuration>
<mainClass>org.junit.platform.console.ConsoleLauncher</mainClass>
<arguments>
<argument>--scan-class-path</argument>
<argument>${project.build.directory}/test-classes</argument>
</arguments>
<classpathScope>test</classpathScope>
</configuration>
</execution>
</executions>
</plugin>
<!-- ... -->
<dependency>
<groupId>org.junit.platform</groupId>
<artifactId>junit-platform-console-standalone</artifactId>
<version><!-- ... --></version>
<scope>test</scope>
</dependency>
I know it's an old topic, but this topic was the reason I've developed this extension 2 years ago: https://github.com/fabriciorby/maven-surefire-junit5-tree-reporter
Basically, to get your tree output, add this to your pom.xml:
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M7</version>
<dependencies>
<dependency>
<groupId>me.fabriciorby</groupId>
<artifactId>maven-surefire-junit5-tree-reporter</artifactId>
<version>1.0.1</version>
</dependency>
</dependencies>
<configuration>
<reportFormat>plain</reportFormat>
<consoleOutputReporter>
<disable>true</disable>
</consoleOutputReporter>
<statelessTestsetInfoReporter
implementation="org.apache.maven.plugin.surefire.extensions.junit5.JUnit5StatelessTestsetInfoTreeReporterUnicode">
</statelessTestsetInfoReporter>
</configuration>
</plugin>
And the magic happens
Currently Surefire is developig extensions 1 for embedded Surefire features, and a standalone extension supporting JUnit5 DisplayName.
One of these extensions is a console logger of testset information. Very similar output to the console in 2 might be possible to support as well then.
The extensions is a set of Java abstractions and Surefire/Failsafe plugins will contain default implementations of these abstractions. The other progressive extension implementations, with the output like in 2, would kindly require users to support Surefire project to implement the extensions in their own GitHub repositories (not in ASF). Surefire is welcome to list all third party implementations of these extensions on the ASF Maven Surefire webpage.
This way (Open-Closed DP) we believe we would provide you with certain freedom to change the behavior of plugins without reporting real Jira issues and without waiting for a new feature release.
Sure.
Feel free to open a feature request to extend the current summary output at https://issues.apache.org/jira/projects/SUREFIRE/issue and perhaps a Pull Request against https://github.com/apache/maven-surefire ;-)
Related
When running mvn versions:display-dependency-updates for the Version Maven Plugin I see lots of things like this:
[INFO] org.slf4j:slf4j-api ........................... 1.7.36 -> 2.0.0-alpha7
But just because I'm not using the alpha version of a later version doesn't mean I'm not using the latest available release version. Another Stack Overflow answer indicated that I can set up a rules.xml file to ignore versions like *.-alpha*, putting something like this in my POM:
<configuration>
<rulesUri>file:///${project.basedir}/rules.xml</rulesUri>
</configuration>
My question: is this rules.xml file inheritable? If I put it in a separate project in a parent POM of <packaging>pom</packaging>, published to Maven Central, will the child POMs pick it up? Or will the child projects look for a rules.xml file in the child project directory?
I want to configure the versions-maven-plugin in the parent POM (as I do already) and run mvn versions:display-dependency-updates on any child POM or descendant POM. How can I set up the ignore rules in the parent POM so that these version ignore rules will be picked up when I check for dependency updates in a child POM? (Is there no way to include the rule within the POM itself?)
Or will the child projects look for a rules.xml file in the child project directory?
Yes, if you define the rules.xml file via ${project.basedir} it will resolve to the current local base directory of the child project. I've verified this with a simple parent-child pom setup. So that will not work, unless you duplicate the rules file in every project.
If you wish to include the plugin configuration and ruleset in the parent pom without duplicating the rules file, you have two options:
If you have your ruleset xml file hosted at, for example, http://www.mycompany.com/maven-version-rules.xml then the following configuration in your corporate pom would ensure that all projects use this rule set.
<configuration>
<rulesUri>http://www.mycompany.com/maven-version-rules.xml</rulesUri>
</configuration>
or
You can provide your ruleset xml file also within a jar, if you want to distribute your ruleset xml as Maven artifact. Therefore you have to declare the containing jar as direct dependency of the versions-maven-plugin and to use classpath as protocol.
<configuration>
<rulesUri>classpath:///package/foo/bar/rules.xml</rulesUri>
</configuration>
<dependencies>
<dependency>
<groupId>com.mycompany</groupId>
<artifactId>version-rules</artifactId>
<version>1.0</version>
</dependency>
</dependencies>
Source:
https://www.mojohaus.org/versions-maven-plugin/version-rules.html
The configuration in the pom only has rudimentary includes and excludes filters. Those will allow you to exclude any dependency as a whole, but not specific update versions. As far as i can tell from the available documentation there is no way to define version rules in any other way.
See
https://www.mojohaus.org/versions-maven-plugin/examples/advancing-dependency-versions.html
Update 09-2022
In the github ticket we found in the comments we can see the following update:
It looks like a feature like this has recently been implemented by #369. Please see #318 where it's possible to provide inclusion and exclusion filters for determining which dependency patterns will be considered. Thanks to that, you can rule out patterns such as .*-beta. or .*_ALPHA, albeit not using regexp, but simple asterisk wildcards.
This will land in today's release (2.12.0).
This will add the following features:
Version 2.12.0 will introduce new arguments: dependencyIncluded, dependencyExcludes, dependencyManagementIncludes, dependencyManagementExcludes.
With the following example configuration in pom.xml given:
<profile>
<id>display-dependency-updates</id>
<build>
<plugins>
<plugin>
<groupId>${project.groupId}</groupId>
<artifactId>${project.artifactId}</artifactId>
<version>${project.version}</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>display-dependency-updates</goal>
</goals>
<configuration>
<dependencyIncludes>org.apache.maven.*:doxia*</dependencyIncludes>
<dependencyManagementIncludes>com.puppy*:*</dependencyManagementIncludes>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
This will also be implemented for filtering plugin and pluginManagement, but that will probably be added in a later release:
So, I've just added the missing plugin- and plugin management filtering which works likewise. I really doubt it will land into today's release though.
Pasting my answer here from Github, because I think it might benefit others.
Provided you have a directory called rules-test in your project containing the rules template file:
<ruleset comparisonMethod="maven"
xmlns="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0
https://www.mojohaus.org/versions-maven-plugin/xsd/rule-2.0.0.xsd">
<ignoreVersions>
<ignoreVersion type="regex">${ignoredVersions}</ignoreVersion>
</ignoreVersions>
</ruleset>
Then, in your main project, create the following profile:
<profile>
<id>rules-test</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>3.3.0</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<resources>
<resource>
<directory>rules-test</directory>
<filtering>true</filtering>
</resource>
</resources>
<outputDirectory>${project.basedir}</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>versions-maven-plugin</artifactId>
<version>2.12.0</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>display-dependency-updates</goal>
</goals>
<configuration>
<rulesUri>file://${project.basedir}/compiled-rules.xml</rulesUri>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
If you then execute the following Maven target:
mvn -P rules-test "-DignoredVersions=.*-(M\d*|.*-SNAPSHOT)" clean validate
then you will get a dependencies report using the filter in the -DignoredVersions argument (filtering out both *-M* and *-SNAPSHOT).
And if you put your ignoredVerions property in your project instead of passing it as a -D argument, then it will be inheritable!
Im using liquibase in a standard java project (non spring) and using maven to manage my migrations and rollbacks
to the plugin configuration in maven im passing a liquibase.properties file that currently has a plain password in it
here is the relevant code
<plugin>
<groupId>org.liquibase</groupId>
<artifactId>liquibase-maven-plugin</artifactId>
<version>4.3.3</version>
<configuration>
<propertyFile>src/main/resources/liquibase.properties</propertyFile>
</configuration>
<executions>
<execution>
<phase>process-resources</phase>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>org.liquibase.ext</groupId>
<artifactId>liquibase-postgresql</artifactId>
<version>4.3.3</version>
</dependency>
</dependencies>
</plugin>
and the properties file
driver=org.postgresql.Driver
url=jdbc:postgresql://localhost:5432/testdb
username=test
password=test
changeLogFile=src/main/resources/db/changelog-master.xml
how can i avoid this
You may use your own property provider class to handle encryption. I don't see any docs for this but you can browse the commits on this link, it might help.
Also the answer on this post will help you with using propertyProviderClass in liquibase.
Other than this, you can go through this article to have an idea.
In our java project, we are using HBase 1.1.1 java APIs. This library internally needs to use Guava 15.0 (Earlier versions of HBase, for ex 0.98, used Guava 18.0). Our current code base has one parent project and multiple child projects. A few of the child projects need methods only available in Guava 18.0. Is it possible for configuring the pom.xml of the parent project in our code base to let HBase use Guava 15.0 while letting the entire remaining code base to use Guava 18.0?
I've tried shading as shown below:
parent pom (example-parent)
<modules>
<module>../example-child1</module>
<module>../example-child2</module>
.......
</modules>
child pom (example-child1)
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>18.0</version>
</dependency>
<profiles>
<profile>
<id>child1</id>
<build>
<plugins>
<plugin>
<artifactId>maven-shade-plugin</artifactId>
<version>2.2</version>
<executions>
<execution>
<id>make-assembly-shade</id>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<relocations>
<relocation>
<pattern>com.google.guava</pattern>
<shadedPattern>shaded.com.google.guava</shadedPattern>
</relocation>
</relocations>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
And I built the jar using:
mvn clean compile package -Pchild1
However I am still seeing only one version of Guava in the final jar. Are there other ways to do the same?
I would highly suggest to define this 'special' guava dependency per profile. For example if Child1 requires Guava 15, in the related profile, add a dependency section with this specific one. If you want to keep thing simple you can remove it from parent and then decide on each profile (and group of modules) which version to include.
Please, someone help me, I'm desperate. I've been trying all night. The problem I have is this: Weird NoClassDef-s with Eclipse Jetty's Maven plugin
Basically: I can't make recent versions of the Jetty plug-in to work properly in an integration test. Indeed, everything works fine until the Jetty's shutdown stage, when I'm told that org.eclipse.jetty.util.FutureCallback is missing.
I've included the dependencies told in the link above. Initially they were ignored, then I've added them in project/build/extensions. Now I've several other ClassNotFoundExceptions and I can't fix that.
This is what I have in my POM:
<plugins>
<!-- This is activated before tests and uses the overlay import mechanism -->
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<configuration>
<systemProperties>
<!-- Triggers test data creation in uk.ac.ebi.fg.myequivalents.webservices.server.test.WebTestDataInitializer -->
<systemProperty>
<name>uk.ac.ebi.fg.myequivalents.test_flag</name>
<value>true</value>
</systemProperty>
</systemProperties>
<scanIntervalSeconds>10</scanIntervalSeconds>
<useTestScope>true</useTestScope>
<httpConnector>
<!-- 8080 is often busy on EBI hosts -->
<port>10973</port>
</httpConnector>
<stopPort>10974</stopPort>
<stopKey>KILL</stopKey>
</configuration>
<executions>
<!--
starts jetty before tests and stops it afterwards. Note that no stop goal is needed, it magically stops
after tests
-->
<execution>
<id>start-jetty</id>
<phase>pre-integration-test</phase>
<goals>
<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>
And these are the extesions I've set up:
<extensions>
<extension>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-util</artifactId>
<version>${jetty.version}</version>
</extension>
<extension>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-jsp</artifactId>
<version>${jetty.version}</version>
</extension>
<extension>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-io</artifactId>
<version>${jetty.version}</version>
</extension>
<extension>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-jaspi</artifactId>
<version>${jetty.version}</version>
</extension>
</extensions>
${jetty.version} is defined in the parent and = 9.1.3.v20140225, but I've tried many, down to 7.x
Moreover, Maven is 3.2.1, Java is 1.7.0_51, running on OS X 10.9.2
Thank you in advance for any help for this nasty issue.
I've found it!!! Apparently, the problem is the 'stop' goal is (rightly) attached to the 'post-integration-test' phase. So, if you issue 'mvn integration-test', such phase, as far as I understand, is not reached (http://tinyurl.com/omwulm5). By just giving 'mvn verify' or 'install', and without adding any Jetty-related dependency to the POM (everything needed should now be included in 9.1.x), Maven completed without any complaint (hooray!).
This might look silly to readers smarter than me, I'm reporting it nonetheless, just in case you're struggling as much as I've just done for hours.
You should not be using the "run" goal with an execution binding. Instead, you should be using the "start" goal. See the documentation here: http://www.eclipse.org/jetty/documentation/current/jetty-maven-plugin.html#jetty-start-goal
The difference is that the "run" goal will run a fresh build up until the "test-compile" phase. The "start" goal does not invoke a parallel build and simply runs at whatever phase it is bound to.
Jan
Just try to add <stopWait>10</stopWait> to plugin configuration.
Full configuration you can see in this answer.
I am currently doing some cleanup of Java projects which use Maven, and use NetBeans IDE to 'debug' problems in the POM. I have set Maven 3.0.4 in the IDE as the Maven version, but other developers or our Continuous Intgeration system might have different settings.
Is it possible to 'enforce' a specific Maven version directly in the POM (for example by using a Maven 3 specific element)?
Yes you can and you should. Some Maven plugins requires Maven 3 or newer.
Use the maven-enforcer-plugin by adding the following to your pom.xml:
<build>
<plugins>
<plugin>
<inherited>true</inherited>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.3.1</version>
<executions>
<execution>
<id>enforce-maven-3</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<requireMavenVersion>
<version>3.0.5</version>
</requireMavenVersion>
</rules>
<fail>true</fail>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
Another option is to use the prerequisites element in the pom, for example:
<project>
...
<prerequisites>
<maven>3.0.0</maven>
</prerequisites>
...
</project>
As noted Michal Kalinowski's answer - this simple approach does not work so well for children projects.
For a summary of which approach will work best for you, see here: enforcing maven 3 - when to use maven enforcer plugin? when to use pom prerequisites element?
The best thing you can do is to use Enforcer plugin. Here's an example:
http://maven.apache.org/enforcer/enforcer-rules/requireMavenVersion.html
There is no out-of-the-box method in Maven itself for doing this. There is actually prerequisites tag but it doesn't work well, because children don't inherit it.