I have a resource file located in folder src/test/java/resources/framework.properties with this content:
felix.auto.start.1=\
"file:${test.archive.directory}/agenda.test-1.0.0.jar"
And I use (or pretend to use) the maven-surefire-plugin to replace that variable (${test.archive.directory}) by the correct value see sample ballow:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<skipTests>${skipTests}</skipTests>
<systemPropertyVariables>
<test.archive.directory>${project.build.directory}</test.archive.directory>
</systemPropertyVariables>
</configuration>
</plugin>
</plugins>
</build>
It just fails miserably and the test returns this message error:
java.io.FileNotFoundException: ${test.archive.directory}\testbundle.test-1.0.0.jar (The system cannot find the path specified))
Obviously the maven-surefire-plugin is not replacing the property value. I was digging all over internet and cannot find a decent answer to this, any idea of what am I doing wrong?
UPDATE
Consider also that I am running this code for an Arquillian OSGi test case. The parameters to replace above is for the Arquillian to locate the necessary bundles to run the tests so the replacement of the parameter must be made before the framework starts.
<test.archive.directory>${project.build.directory}</test.archive.directory>
is available as System property to the Java process it spans off for surefire, you can read them by
System.getProperty("test.archive.directory");
in your Java class, you can't expect it to magically replace it in properties file
Related
I have a Java (11.0.7) Maven (3.0.6) multi-module project that contains the following module declarations:
<modules>
<module>jdrum-commons</module>
<module>jdrum-datastore-base</module>
<module>jdrum-datastore-simple</module>
<module>jdrum</module>
</modules>
Each of these Maven modules contains a module-info that defines the necessary requirements and exports to restrict access and visibility.
As such, jdrum-datastore-simple has some test utility classes that I reuse in jdrum's tests. By configuring the surefire plugin in jdrum's config via the code snippet below I am able to package the whole project without any issues.
<build>
<plugins>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<argLine>
<!-- Allow the unnamed module access to the tests at test-time -->
--add-opens jdrum/at.rovo.drum.impl=ALL-UNNAMED
--illegal-access=deny
</argLine>
</configuration>
</plugin>
</plugins>
</build>
Within the parents POM I've also configured the generation of a report via the site argument, which also generates the Javadoc of the respective projects. The configuration for the JAR containing the javadoc as well as the configuration for the Javadoc generation as part of the report are both the same and look like this:
<!-- Generate Javadoc while reporting -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>3.2.0</version>
<inherited>true</inherited>
<configuration>
<verbose>true</verbose>
<source>${maven.compiler.source}</source>
<show>protected</show>
<failOnWarnings>false</failOnWarnings>
<release>${maven.compiler.release}</release>
<stylesheet>java</stylesheet>
</configuration>
<reportSets>
<reportSet>
<id>html</id>
<reports>
<report>javadoc</report>
</reports>
</reportSet>
</reportSets>
</plugin>
The Javadoc generation as part of the package step, which generates the project-version-javadoc.jar as output, succeeds as both, the jdrum-datastore-simple dependencies as well as its tests, are only included at test time:
<!-- Test data store to use for testing -->
<dependency>
<groupId>at.rovo</groupId>
<artifactId>jdrum-datastore-simple</artifactId>
<version>${project.parent.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>at.rovo</groupId>
<artifactId>jdrum-datastore-simple</artifactId>
<version>${project.parent.version}</version>
<scope>test</scope>
<type>test-jar</type>
</dependency>
If I'd change the scope from test to compile or provided the Javadoc generation would also fail with an error such as
Exit code: 1 - javadoc: error - The code being documented uses packages in the unnamed module, but the packages defined in https://github.com/RovoMe/JDrum/jdrum-datastore-simple/apidocs/ are in named modules.
The issue here, as far as I understood the problem, is, that the jdrum-datastore-simple module is not added to the module path of Javadoc. The next logical step was therefore to add that module to the configuration as such:
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<configuration>
<additionalOptions>
<option>--add-modules</option>
<option>jdrum.datastore.simple</option>
</additionalOptions>
</configuration>
</plugin>
</plugins>
</reporting>
This adds the jdrum-datastore-simple module to the Javadoc configuration string, which can be seen in the jdrum/target/site/apidocs/options file that now contains an
...
--add-modules
jdrum.datastore.simple
...
entry. On further analyzing the generated options file it is apparent that the module path is missing out a reference to the actual JAR file and hence the Javadoc generation and thus the Maven process fails due to Javadoc not being able to locate the defined module. If I update that options file and add the path to the missing JAR file and then only perform a mvn package site the whole process succeeds and all is fine (as the pure invocation of the javadoc.bat located in the target/site/apidocs folder would as well).
Now, in order to make the whole process more dynamic I wanted to add or update the module path. However, the maven-javadoc-plugin does not directly allow this. Therefore I came up with adding a further maven-javadoc-plugin option of --module-path and a further option entry that contains the whole path. By the whole path I mean the path to every single dependency, so not only the path to jdrum-datastore-simple. This also works but due to hardcoding the path to the respective JAR files, the project is now not usable by other users unless they have the same system and path structure I used. To fix this I quickly replaced the respective path structure with ${settings.localRepository} and ${project.parent.basedir} properties on the respective modules in the module path. Unfortunately Javadoc is rather nitpicking on the path structure it accepts and it turns out that on my Windows machine Maven does return a path structure starting with C:\Users\... which Javadoc can't handle. If the path structure looks like C:/Users/... however Javadoc is fine with the values.
On further research I stumbled upon this thread which suggests to use Maven's build-helper-maven-plugin to define new properties for i.e. the M2 repository and use the built-in reg-ex capability to replace \ characters with /. However, adding a configuration such as
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>3.1.0</version>
<executions>
<execution>
<id>replace-local-repo-characters</id>
<goals>
<goal>regex-property</goal>
</goals>
<configuration>
<name>tag.m2repo</name>
<value>${settings.localRepository}</value>
<regex>\\</regex>
<replacement>/</replacement>
<failIfNoMatch>false</failIfNoMatch>
</configuration>
</execution>
<execution>
<id>replace-local-path-characters</id>
<goals>
<goal>regex-property</goal>
</goals>
<configuration>
<name>tag.basedir</name>
<value>${project.parent.basedir}</value>
<regex>\\</regex>
<replacement>/</replacement>
<failIfNoMatch>false</failIfNoMatch>
</configuration>
</execution>
</executions>
</plugin>
and using the introduced tags instead does not work at all as Maven is complaining about an invalid value provided. If I use $\{settings.localRepository} Maven is fine about the provided value, however in the final options file not the value of the actual settings.localRepository is updated but the provided string itself and I end up with something like $/{settings.localRepository}/org/slf4j/... which Javadoc can't resolve and therefore still misses out on the correct location to the jdrum-datastore-simple dependency.
So, how can I add the path to the missing dependency to maven-javadoc-plugin's module path defined in the generated options file so that the Maven is actually able to generate the whole report?
It seems that with java11 Update 9 (maybe also with update 8; not tested) maven-javadoc-plugin is able to correctly generate the Javadoc for multi-module projects without the need to alter the module-path.
For those interested how the actual Maven POM looks like:
Parent POM
POM for a shared module
POM for a sharing and consuming module
POM for the consuming module
I'm new to Java scene and was attempting to create a maven plugin.
I started with the archetype 'maven-archetype-plugin' and it comes with a default testing scaffold with artifact id 'maven-plugin-testing-harness'.
One confusing thing I've observed is that in the pom of testing directory 'project-to-test' exists a configuration over output directory
<build>
<plugins>
<plugin>
<artifactId>my-plugin-artifact-id</artifactId>
<configuration>
<!-- Specify the MyMojo parameter -->
<outputDirectory>target/test-harness/project-to-test</outputDirectory>
</configuration>
</plugin>
</plugins>
</build>
This parameter configuration didn't seem to take effect at all. The actually output path was set to default ('./target/) regardless
What did I do wrong?
After running maven commands in the project-to-test directory, I've realized that the newly created plugin was resolved to package org.apache, which is completely wrong.
With this hint I've added label to the pom build section and it now behave as expected.
I have a project that uses Spring Boot. I need to rename the application.properties file to something else (i.e. othername.properties). The reason I need to rename it is because we have a bunch of other scripts that rely on that naming convention.
How can I tell Spring Boot to use othername.properties instead of the default application.properties? The documentation says that I can use the java command and pass an argument when running the application, but that doesn't help when I run a maven > install because there are spring integration/unit tests to be run as well (which rely on the application.properties file db settings).
Right now I have tried to set an environment property in the maven-surefire plugin like so:
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<systemPropertyVariables>
<spring.config.name>othername.properties</spring.config.name>
</systemPropertyVariables>
</configuration>
</plugin>
</plugins>
</pluginManagement>
When I add that in my pom.xml, it seems that Spring Boot isn't picking up that file, and also isn't reading from application.properties (because the db settings are in application.properties as well as othername.properties right now, and it fails, so I know it isn't being read).
The otherfile.properties is in my project's resources folder, should it go somewhere else? Also, how do I specify a relative path to that file if it were to live somewhere else?
Didn't try it, but I think it should be
<systemPropertyVariables> <spring.config.name>othername</spring.config.name> </systemPropertyVariables>
Without .properties
I'm having difficulty trying to add an argument to the jvm. It looks like using surefire is the only way to do this. My current code in the pom.xml is
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.19</version>
<configuration>
<argLine>-Xmx512m</argLine>
<systemPropertyVariables>
<all.clusters>${all.clusters}</all.clusters>
<branding.token>${brandingToken}</branding.token>
</systemPropertyVariables>
</configuration>
</plugin>
Maven is new to me so perhaps I'm missing something simple.
Running in a Netbeans 8.1 environment.
Turns out that what I needed to do was not to get surefire to run with special arguments, because that only covers tests. The trick to getting it working was the fact that this project is a NetBeans application which uses the
nbm-maven-plugin.
The following blog post describes how to modify the arguments.
Blogpost
<build>
<plugins>
<plugin>
<groupId>org.jvnet.jax-ws-commons</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<version>2.3</version>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>wsimport</goal>
</goals>
<id>generate-sei</id>
<configuration>
<sourceDestDir>${project.basedir}/src/main/java</sourceDestDir>
</configuration>
</execution>
</executions>
<dependencies>...</dependencies>
</plugin>
</plugins>
</build>
The above XML snippet is from a POM file in a Java project. In this snippet I've defined the jaxws-maven-plugin to use a wsdl file to generate the SEI code and place it in the src/main/java directory. This plugin is bound to the generate-sources phase, and works fine.
I want to make it so that if I issue the plugin directly, using:
mvn jaxws:wsimport
it should place the files in the above mentioned folder. From the plugins reference site (https://jax-ws-commons.java.net/jaxws-maven-plugin/wsimport-mojo.html), I can't figure out how to pass the parameter (sourceDestDir) as a command line argument. Is there someway I can do this?
WARNING /!\
You are trying to generate sources under the source folder src/main/java. Unless there is a very strong reason, don't do this. All generated content should always be placed under the build directory (target by default) and not be version-controlled. You can always add the generated sources as source folder using the build-helper-maven-plugin:add-source, if the plugin does not do it already itself.
To be able to set parameters directly on the command line, the plugin needs to define a user property. However, the org.jvnet.jax-ws-commons:jaxws-maven-plugin does not define a user property for the sourceDestDir parameter. This is noticeable because the documentation does not have a "User Property" set.
You can also find this in the source code:
#Parameter(defaultValue = "${project.build.directory}/generated-sources/wsimport")
private File sourceDestDir;
The #Parameter annotation, used to declare the parameter of the Maven plugin, does not have a corresponding property.
As such, you will need to have the following:
Define a Maven property jaxws.sourceDestDir with a value of ${project.basedir}/src/main/java with
<properties>
<jaxws.sourceDestDir>${project.basedir}/src/main/java</jaxws.sourceDestDir>
</properties>
Preferably, you would have ${project.build.directory}/some/path instead of src/main/java.
Configure the plugin to use this Maven property:
<configuration>
<sourceDestDir>${jaxws.sourceDestDir}</sourceDestDir>
</configuration>
If you want to override it, you can now do so directly on the command line with -Djaxws.sourceDestDir=/my/new/value. This system property will take precedence over the value of the Maven property.