get maven to replace values based on user/build.properties - maven

im at the point in my project where im moving data connections to the beta and production databases for testing. obviously, having the alpha database credentials stored in the source repository is fine, but the beta and production credentials, id be put in front of a firing squad for that one.
i know maven can have a {userdir}/build.properties file. this is the file i want to use to keep the db credentials out of the source repository. but i can't seem to get maven to figure out that for file x.cfg.xml it has to replace values.
so i have in one of my hibernate.cfg.xml files this line
<property name="hibernate.connection.url">#ssoBetaUrl#</property>
now how do i get maven to replace that variable with the value thats in the {userdir}/build.properties file?
edit-------------
ive been playing with the properties-maven-plugin plugin but i seem to not be able to get it to fire. i put this in my parent pom
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-2</version>
<executions>
<execution>
<id>read-properties</id>
<phase>initialize</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
</execution>
</executions>
</plugin>
but when it builds, it does not fire. if im reading http://maven.apache.org/maven-1.x/reference/properties.html right it should find the build properties file in the ~/build.properties folder and go from there, but im not sure.

I think you are approaching this the wrong way around. Instead of having the build process bake the appropriate connection details into the JAR file you should instead have the program look for a configuration file at startup.
Typically, my hibernate based apps, will look for a file under %user.home&/.appname/config.properties and load DB credentials and other deployment specfic data from there. If the file is missing, a default version can be included in the JAR and copied to this location (on initial startup so you don't have to copy-paste the file to new systems) that is then edited with appropriate settings.
This way, you can use the same build to produce JAR (or WAR) files for test and production servers, the differences will be in the (presumably already deployed) configuration files. This also makes it possible to have multiple production deployments, each talking to a different database, without any complications in the build process.

You could use two plugins.
properties-maven-plugin
replacer
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-1</version>
<executions>
<execution>
<phase>initialize</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
<configuration>
<files>
<file>{userdir}/build.properties</file>
</files>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>com.google.code.maven-replacer-plugin</groupId>
<artifactId>replacer</artifactId>
<version>1.5.2</version>
<executions>
<execution>
<phase>prepare-package</phase>
<goals>
<goal>replace</goal>
</goals>
</execution>
</executions>
<configuration>
<includes>
<include>target/**/*.*</include>
</includes>
<replacements>
<replacement>
<token>#ssoBetaUrl#</token>
<value>http://[anyURL]</value>
</replacement>
</replacements>
</configuration>
</plugin>

Related

swagger maven plgin executions do not run independant

I use the latest swagger-maven-plugin from the io.swagger.core.v3 to generate my static swagger api documentation.
In my project, I have to separate apis so I want to get a json and yml representation for each api within one package process.
<plugin>
<groupId>io.swagger.core.v3</groupId>
<artifactId>swagger-maven-plugin</artifactId>
<version>2.2.6</version>
<configuration>
<outputPath>${basedir}/target/</outputPath>
<outputFormat>JSONANDYAML</outputFormat>
<prettyPrint>true</prettyPrint>
</configuration>
<executions>
<execution>
<id>1</id>
<goals>
<goal>resolve</goal>
</goals>
<configuration>
<resourcePackages>
<resourcePackage>de.test.rest</resourcePackage>
</resourcePackages>
<outputFileName>swagger</outputFileName>
<configurationFilePath>${basedir}/src/main/resources/openApiConfig.yml</configurationFilePath>
</configuration>
</execution>
<execution>
<id>2</id>
<goals>
<goal>resolve</goal>
</goals>
<configuration>
<resourcePackages>
<resourcePackage>de.test.secondAPI</resourcePackage>
</resourcePackages>
<outputFileName>secondAPI</outputFileName>
<configurationFilePath>${basedir}/src/main/resources/secondOpenApiConfig.yml</configurationFilePath>
</configuration>
</execution>
</executions>
</plugin>
PROBLEM:
the execution creates the expected json and yml files for each execution
swagger.yml
swagger.json
secondAPI.yml
secondAPI.json
The problem is, that the seconAPI files are a copy of the swagger files.
I've read the documentation and I thought that configuration in the plugin root is shared between multiple executions. Configurations within the execution tag are individually used per execution.
Is there a way to run the executions in parallel with individual configuration?
Or is it a problem with the plugin itself?
EDIT:
Each execution works as expected when there is only one execution defined in the executions tag.

Check for unresolved properties in Maven Resources

Given the following property in src/main/resources/hello.xml
<test>${resolved.property}</test>
<test>${unresolved.property}</test>
With properties:
resolved.property=test
How do I validate, after going through mvn:resources filtering, if there are any unresolved properties left?
You can use the XML Maven Plugin to validate your XML file after resource filtering has completed.
This plugin can validate XML files against a schema or even just check that they are well formed (which will be sufficient to verify that your XML files do not contain property tokens).
You declare the plugin like so:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>xml-maven-plugin</artifactId>
<executions>
<execution>
<phase>process-resources</phase>
<goals>
<goal>validate</goal>
</goals>
</execution>
</executions>
<configuration>
<validationSets>
<validationSet>
<dir>... your xml dir ...</dir>
<includes>
<include>*.xml</include>
</includes>
</validationSet>
</validationSets>
</configuration>
</plugin>
Note: the use of <phase>process-resources</phase> is important here since you want to ensure that validation runs after your resources have been filtered.

Using sonar.test.exclusions with Sonarqube 6.3

I'm currently evaluating Sonarqube 6.3 (a big upgrade from my current 5.5 instance) and I'm getting confused trying to work out the functionality of the sonar.test.exclusions setting.
There's this question: Sonar Maven Plugin: How do I exclude test source directories? which seems to indicate that it is used to exclude test files from analysis (which is what I'm after - I don't want my sonar ruleset run over my unit tests). The documentation https://docs.sonarqube.org/display/SONAR/Narrowing+the+Focus also indicates that it is used to 'exclude unit test files' (perhaps this can be expanded upon to make it clearer?)
Thing is, when I add sonar.test.exclusions with a value of **/src/test/** and then run my analysis, I'm still getting code smells and the like being found for:
Foo/src/test/java/foo/bar/BarTest.java
Foo/src/test/java/lah/LahTest.java
etc.
When I use sonar.exclusions instead, they don't show up. Why is sonar.test.exclusions not doing what I expect?
First of all: if you have a Maven project, you should use the scanner for Maven (mvn sonar:sonar). It will simplify your configuration, and will automatically register src/test/java folder as a test directory.
Now if you want to do the configuration manually, or understand what is going on under the hood, here is the explanation: SonarQube scanner work with 2 sets of files, main and test. Main source files are configured using the property sonar.sources. Test source files are configured using sonar.tests.
On top of that, you can filter some content using the sonar.[test.]exclusions properties.
In you case your problem is that Foo/src/test/java/foo/bar/BarTest.java seems to be considered as a main source file. That's why sonar.test.exclusions has no effect.
Using maven with verfication goal (mvn clean verify sonar:sonar install), I have used this configuration without problems:
...
<properties>
....
<sonar.exclusions>
**/generated/**/*,
**/model/**/*
</sonar.exclusions>
<sonar.test.exclusions>
src/test/**/*
</sonar.test.exclusions>
....
<sonar.java.coveragePlugin>jacoco</sonar.java.coveragePlugin>
<sonar.jacoco.reportPath>${project.basedir}/../target/jacoco.exec</sonar.jacoco.reportPath>
<sonar.coverage.exclusions>
**/generated/**/*,
**/model/**/*
</sonar.coverage.exclusions>
<jacoco.version>0.7.5.201505241946</jacoco.version>
....
</properties>
....
Coverage exclusion configuration, inside properties (up) and jacoco plugin configuracion:
.....
<build>
<plugins>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>${jacoco.version}</version>
<executions>
<execution>
<id>prepare-agent</id>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>report</id>
<phase>prepare-package</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
<execution>
<id>post-unit-test</id>
<phase>test</phase>
<goals>
<goal>report</goal>
</goals>
<configuration>
<dataFile>target/jacoco.exec</dataFile>
<outputDirectory>target/jacoco-ut</outputDirectory>
</configuration>
</execution>
</executions>
<configuration>
<systemPropertyVariables>
<jacoco-agent.destfile>target/jacoco.exec</jacoco-agent.destfile>
</systemPropertyVariables>
</configuration>
</plugin>
</plugins>
</build>
....

Build a site zip with Maven

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.

selecting test file (jmx file) not working with jmeter-maven-plugin

I want to select only one JMeter test file (jmx file) to run at one time. I have the following in my pom.xml:
<plugin>
<groupId>com.lazerycode.jmeter</groupId>
<artifactId>jmeter-maven-plugin</artifactId>
<version>1.9.0</version>
<executions>
<execution>
<id>jmeter-tests</id>
<phase>verify</phase>
<goals>
<goal>jmeter</goal>
</goals>
<configuration>
<testFilesIncluded>
<jMeterTestFile>ionix-${foo.bar}.jmx</jMeterTestFile>
</testFilesIncluded>
<overrideRootLogLevel>DEBUG</overrideRootLogLevel>
<testResultsTimestamp>false</testResultsTimestamp>
</configuration>
</execution>
</executions>
</plugin>
I have multiple jmx files in src/test/jmeter. It turns out those jmx files are always run by the jmeter plugin no matter what, even if I run maven with command like below:
mvn clean -Dfoo.bar=nonsense jmeter:jmeter
According to the documentation, my settings above should only execute ionix-${foo.bar}.jmx. (Whether the file ionix-${foo.bar}.jmx exists doesn't seem to make a difference in my case.) So, what am I missing here?
Thank you very much.
Enable debug in Maven by adding -X to see what is happening .
could you list content of folder that contains jmx files

Resources