Retaining module keys when migrating Sonar from Maven runner to Ant runner - sonarqube

We'd like to convert our existing multi-module Sonar projects that use the Maven runner to use the Ant runner instead. These projects all use Ant for their main build anyway, and it will be a lot more convenient to have everything done with Ant.
We must preserve the history of the projects, meaning that we need to retain the keys used for the projects and their modules. I'm having trouble doing that.
Our current Maven parent pom looks something like this (the ui is similar, though the language is Flex):
<project ...>
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>anapp</artifactId>
<name>An Application</name>
<version>7.0</version>
<packaging>pom</packaging>
<modules>
<module>server</module>
<module>ui</module>
</modules>
<properties>
<sonar.dynamicAnalysis>reuseReports</sonar.dynamicAnalysis>
</properties>
</project>
The server module pom looks like this:
<project ...>
<parent>
<groupId>com.example</groupId>
<artifactId>anapp</artifactId>
<version>7.0</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>anapp_server</artifactId>
<name>Server</name>
<version>7.0</version>
<build>
<outputDirectory>build/classes</outputDirectory>
<sourceDirectory>src/main/java</sourceDirectory>
<testOutputDirectory>build/test/classes</testOutputDirectory>
<testSourceDirectory>src/test</testSourceDirectory>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.6</source>
<target>1.6</target>
</configuration>
</plugin>
</plugins>
</build>
<properties>
<sonar.dynamicAnalysis>reuseReports</sonar.dynamicAnalysis>
<sonar.core.codeCoveragePlugin>emma</sonar.core.codeCoveragePlugin>
<sonar.emma.reportPath>build\codecoverage-results</sonar.emma.reportPath>
<sonar.surefire.reportsPath>build\test\results</sonar.surefire.reportsPath>
</properties>
</project>
We set the sonar.branch property on the command line to "R7".
The key of the "myapp" project looks like
com.example:anapp:R7
The key of the "Server" module within the "myapp" project looks like this:
com.example:anapp_server:R7
For the same project to use the Ant task, I set up the properties as:
sonar.dynamicAnalysis=reuseReports
sonar.modules=server,ui
sonar.projectBaseDir=...
sonar.projectKey=com.example\:myapp
sonar.projectName=An Application
sonar.projectVersion=7.0
server.sonar.binaries=...
server.sonar.dynamicAnalysis=reuseReports
server.sonar.emma.reportPath=...
server.sonar.java.coveragePlugin=emma
server.sonar.java.source=1.6
server.sonar.language=java
server.sonar.libraries=...
server.sonar.projectBaseDir=...
server.sonar.projectKey=com.example\:anapp_server
server.sonar.projectName=Server
server.sonar.sources=...
server.sonar.surefire.reportsPath=...
server.sonar.tests=...
ui.sonar.dynamicAnalysis=false
ui.sonar.language=flex
ui.sonar.projectBaseDir=...
ui.sonar.projectKey=com.example\:anapp_ui
ui.sonar.projectName=UI
ui.sonar.sources=...
The key of the project looks the same as with the pom file ("com.example:anapp:R7"); however, the server module key looks like
com.example:anapp:com.example:anapp_server:R7
This difference will cause us to lose the history of the modules if I publish using them.
Is there a way for me to specify the Ant properties to generate the same key as with our existing Maven pom files?
Our Sonar admin tells me he can manually change the keys for us, but this would be tedious and time consuming. We'll resort to that if we have to, but I'm hoping I'm just missing something obvious that would save us a lot of work.

There's no way to transform Maven-style keys in standard SonarQube-style keys.
So your admin is right, the only way to do it is to manually update the keys through the interface, as explained on the documentation.

Related

wildfly.maven.plugin deploys nothing if packaging is set to pom

I am using Maven in order to automatically download a dependency, set up (and start) the JBoss server and deploy that downloaded dependency there. I created a pom.xml, which uses several Maven-Plugins. For JBoss-related interactions I am using the wildfly-maven.plugin (currently version 2.0.1.Final).
Since I am not building an artifact, but rather downloading it, I am not really producing a JAR (or any archived artifact).
The problem I currently have is: the wildfly-maven-plugin does not seem to do anything if packaging is set to pom.
As a workaround I currently set the project packaging to JAR and added the following to prevent the project JAR from building:
<properties>
<jar.skipIfEmpty>true</jar.skipIfEmpty>
<maven.install.skip>true</maven.install.skip>
</properties>
Update 04.03
This is what my pom.xml basically looks like:
<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>some.group</groupId>
<artifactId>artifact</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>jar</packaging>
<name>~y</name>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<maven.install.skip>true</maven.install.skip>
<jar.skipIfEmpty>true</jar.skipIfEmpty>
<plugin.wildfly.version>2.0.1.Final</plugin.wildfly.version>
<plugin.wildfly.jboss-home>D:\server\jboss-eap-7.1</plugin.wildfly.jboss-home>
<plugin.wildfly.hostname>localhost</plugin.wildfly.hostname>
<plugin.wildfly.port>9990</plugin.wildfly.port>
<plugin.wildfly.debug.port>9991</plugin.wildfly.debug.port>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.wildfly.plugins</groupId>
<artifactId>wildfly-maven-plugin</artifactId>
<version>${plugin.wildfly.version}</version>
<configuration>
<jboss-home>${plugin.wildfly.jboss-home}</jboss-home>
<id>local-jboss</id>
<hostname>${plugin.wildfly.hostname}</hostname>
<port>${plugin.wildfly.port}</port>
<filename>y.ear</filename>
<force>true</force>
</configuration>
<executions>
<execution>
<id>deploy-ear</id>
<phase>install</phase>
<goals>
<goal>deploy-only</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
I will give deploy-artifact a try, but in general I'd expect the wildfly.maven.plugin to work even if <packaging> is set to pom.
Maven command on commandline to build it: mvn clean install.
My real pom.xml is a bit more complex, but if it'd work using this simple pom.xml, I could make it work in the more complex one that I use.
Have a look at the deploy-artifact goal. There is an example of it in the documentation.
wildfly-maven-plugin does not seem to do anything if packaging is set to pom. Using the packaging-type jar along with jar.skipIfEmpty helps.
When using wildfly-maven-plugin's deploy-only goal, publishing works (through the management interface).

OpenLiberty Maven Plugin

I am trying to create a runnale openliberty server as part of my release process. I have a a multi module maven project with a submodule dedicated to packaging the server as a runnable. When I do a mvn clean package a lovely executable jar is produced which bundles one of the other submodules (war). The problem I am facing is when I do a maven deploy to our asset repo the packaged server is being uploaded as a zip file rather than a jar file. Does anyone know how to get the deploy plugin to upload the jar?
Here is a sample pom file
<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>
<parent>
<groupId>au.com.xxxx.xxxx</groupId>
<artifactId>xxx-backend-parent</artifactId>
<version>0.0.16-SNAPSHOT</version>
</parent>
<artifactId>xxxx-openliberty-server</artifactId>
<packaging>liberty-assembly</packaging>
<name>fusion-openliberty-server</name>
<description>Runnable Jar containing xxxxand the OpenLiberty applictaion server</description>
<dependencies>
<!-- Package xxxx-application.war with server assembly -->
<dependency>
<groupId>au.com.xxx.xxx</groupId>
<artifactId>xxxx-application</artifactId>
<version>${project.version}</version>
<type>war</type>
</dependency>
</dependencies>
<build>
<plugins>
<!-- Enable liberty-maven-plugin -->
<plugin>
<groupId>net.wasdev.wlp.maven.plugins</groupId>
<artifactId>liberty-maven-plugin</artifactId>
<version>2.6.1</version>
<extensions>true</extensions>
<configuration>
<assemblyArtifact>
<groupId>io.openliberty</groupId>
<artifactId>openliberty-javaee8</artifactId>
<version>18.0.0.3</version>
<type>zip</type>
</assemblyArtifact>
<include>runnable</include>
<serverName>xxx</serverName>
<appsDirectory>apps</appsDirectory>
<serverEnv>${basedir}/src/main/resources/server.env</serverEnv>
<configFile>${basedir}/src/main/resources/server.xml</configFile>
<jvmOptionsFile>${basedir}/src/main/resources/jvm.options</jvmOptionsFile>
<bootstrapProperties>
<app.context.root>xxx-app</app.context.root>
<default.http.port>5000</default.http.port>
<default.https.port>5443</default.https.port>
</bootstrapProperties>
</configuration>
</plugin>
</plugins>
</build>
</project>
I don't have an answer to your question but an explanation why this happens. Every packaging type (jar, war, liberty-assembly) defines a fixed extension for the artifact(s) it creates. The liberty-assembly types defines zip as it extension. This extension is used by the maven-install-plugin and maven-deploy-plugin regardless how the local file is names. I did quite some code digging but couldn't find a way to change this. It's probably sth. that only liberty-maven-plugin can change/fix.

Best tool to merge Git flow hotfix for multi-module maven projects

Let's say my develop branch is on v 1.0.1-SNAPSHOT, my master is on 1.0.0.
I have to create a hotfix. Using SourceTree's Git Flow menu (or any other tool), I create the hotfix branch from master, I update the poms to v 1.0.0.1 (using mvn versions:set -DnewVersion=1.0.0.1), and do the fix.
When I finish the hotfix using Git-Flow I have to merge back to develop branch. This means that the pom files will conflict. In case I have a multi-module project with a large module tree, all poms must be resolved. Other files which were changed in both branches will also conflict.
Considering that during the hotfix there were no changes to the poms, they can be resolved just using the version on the develop branch.
This must be done for every hotfix, but e.g using SourceTree, visually it is hard to distinguish between poms and other conflicted files. It would be nice I could separate those files somehow which I can safely ignore and merge by accepting what is already on the develop branch.
What is the best way for that?
The simplest solution I know is to use a property for a versions instead of literal defining them into the pom file(s). This is available since Maven 3.5.0.
You can do it like this:
<project ...>
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.apache</groupId>
<artifactId>apache</artifactId>
<version>18</version>
</parent>
<groupId>org.apache.maven.ci</groupId>
<artifactId>ci-parent</artifactId>
<name>First CI Friendly</name>
<version>${revision}</version>
...
</project>
Now you can build it via:
mvn -Drevision=1.2.0-SNAPSHOT clean package
But this would mean to define the revision each time you call Maven via command line which is a little bit cumbersome. So you could use the solution via .mvn/maven.config file which contains:
-Drevision=1.2.0-SNAPSHOT
You can define the property within the Maven pom itself like this:
<project>
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.apache</groupId>
<artifactId>apache</artifactId>
<version>18</version>
</parent>
<groupId>org.apache.maven.ci</groupId>
<artifactId>ci-parent</artifactId>
<name>First CI Friendly</name>
<version>${revision}</version>
...
<properties>
<revision>1.0.0-SNAPSHOT</revision>
</properties>
</project>
This means you have only a single location where the version is defined and not in every module etc.
A multi module setup works also like this where a child of an above parent could look like this:
<project>
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.apache.maven.ci</groupId>
<artifactId>ci-parent</artifactId>
<version>${revision}</version>
</parent>
<groupId>org.apache.maven.ci</groupId>
<artifactId>ci-child</artifactId>
...
</project>
BUT BE AWARE that you have to use flatten-maven-plugin in cases where you like to deploy such artifacts to a repository or just want to do mvn install. This needs to look like this:
<project>
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.apache</groupId>
<artifactId>apache</artifactId>
<version>18</version>
</parent>
<groupId>org.apache.maven.ci</groupId>
<artifactId>ci-parent</artifactId>
<name>First CI Friendly</name>
<version>${revision}</version>
...
<properties>
<revision>1.0.0-SNAPSHOT</revision>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>flatten-maven-plugin</artifactId>
<version>1.0.0</version>
<configuration>
<updatePomFile>true</updatePomFile>
</configuration>
<executions>
<execution>
<id>flatten</id>
<phase>process-resources</phase>
<goals>
<goal>flatten</goal>
</goals>
</execution>
<execution>
<id>flatten.clean</id>
<phase>clean</phase>
<goals>
<goal>clean</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<modules>
<module>child1</module>
..
</modules>
</project>
That means in the end you have only a single line where the version of your project is being defined and that should reduce this merge issues dramatically.
Please READ the documentation with care!
Please use only ${revision}, ${changelist} or ${sha1} other properties are currently not supported.
This is a great question for git flow.
In your scenario you haven't mentioned making changes to the Pom outside of the version but that is a possibility in a hot-fix. Aside from some really nifty git tricks we resolve this by hand.
In our workflows we do a manual merge resolution and then use maven to make sure we have the correct snapshot version set.
mvn versions:set -DnewVersion=1.0.1-SNAPSHOT -DgenerateBackupPoms=false
Then we run our tests, and call it a day.
I've been reading aboutgit rerere and think it could be super helpful here.
The name stands for "reuse recorded resolution" and as the name implies, it allows you to ask Git to remember how you've resolved a hunk conflict so that the next time it sees the same conflict, Git can automatically resolve it for you.
More here
This is a super annoying problem for most dev teams, I'm interested to see others solutions!

Running multiple Maven instances of a framework, how to set the goals?

Framework is run from a root directory typing
mvn ninja:run
To run two or more instances of Maven, I have to use modules. I got that part as:
<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/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.maventest</groupId>
<artifactId>myproject</artifactId>
<packaging>pom</packaging>
<version>1.0-SNAPSHOT</version>
<name>myproject</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
<modules>
<module>/user</module>
<module>/admin</module>
</modules>
</project>
To run on a specified port, I would have to type
mvn ninja:run -Dninja.port=YourPortNumber
what changes do I need to add to a pom.xml file and where, to get the both instances running at the same time and on different ports?
Edit: Ideal solution would be typing just a simple "mvn" command to start the modules which would make both instance run.
According to the documentation of the Ninja Plugin, you can configure the port as part of the plugin configuration as well, not only via command line option (the -Dninja.port=YourPortNumber option you mentioned).
Hence, in your two sub-modules, you could configure the plugin as following:
<build>
<plugins>
<plugin>
<groupId>org.ninjaframework</groupId>
<artifactId>ninja-maven-plugin</artifactId>
<version>5.2.2</version>
<configuration>
<port>1234</port>
</configuration>
</plugin>
</plugins>
</build>
As part of the port section, you can then type in each of the sub-module the specific port number you want to use and not providing it anymore from the command line. Also note, in the snippet above I used the 5.2.2 version (the latest), but you can change it according to the version you meant to use. Further note: you may already have a build section as part of your POM, in that case you would only need to add the plugin section above to the existing list of plugins configurations, if any.
As such, you would only require to execute mvn ninja:run, port numbers will be provided by each sub-module configuration.
Side note: it should be clear that Maven is a build tool and not an executor tool (even though it is a plugin executor in its bones), so we cannot pretend to simply launch mvn and execute our own logic.

creating war file using maven-ear-plugin and defining it in one pom.xml

I am at the starter level of the maven usage. I hope I can explain my problem clearly, I want to create an ear file which contains war file inside it. And I planned to use to create a war file from the start. Also I want to do it in my pom.xml at my project and there is only one pom.xml, here is the problem;
Can I create ear file and which contains this war that I created at the same time in one pom.xml file?
when I try to create war file in webmodule tag, here is the problem that I encounter " Artifact[war:denem.denem:denem] is not a dependency of the project." I understood so that's why I added dependency for this file in the same pom.xml but this time I encountered that problem
(By the way my command to build this pom is "mvn clean package" )
"1 required artifact is missing.
for artifact:
com.denem.denem:com.denem.de2:ear:v0.1"
It tries to find this war file but I want to create it not to find it. Here the code in my pom.xml file;
<parent>
<groupId>denem.denem</groupId>
<artifactId>com.denem.denem</artifactId>
<version>v0.1</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId>denem.denem</groupId>
<artifactId>com.denem.de2</artifactId>
<version>v0.1</version>
<packaging>ear</packaging>
<properties>
<cxf.version>2.2.5</cxf.version>
</properties>
<dependencies>
<dependency>
<groupId>denem.denem</groupId>
<artifactId>denem</artifactId>
<version>v0.1</version>
<type>war</type>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ear-plugin</artifactId>
<version>2.5</version>
<configuration>
<finalName>edu</finalName>
<defaultLibBundleDir>lib</defaultLibBundleDir>
<modules>
<webModule>
<groupId>denem.denem</groupId>
<artifactId>denem</artifactId>
<contextRoot>/WebContent</contextRoot>
</webModule>
</modules>
</configuration>
</plugin>
</plugins>
</build>
I guess I am doing lots of things wrong. But If you can help me I will be glad. Thank you anyway.
You need to create a modular project.
Create:
a parent project of type "pom";
a child project of type "war";
if needed, child projects of type "ejb";
if needed, child projects of type "jar" (common libraries);
one project of type "ear", that has all of the above as dependencies.
In the latter you need to configure the ear plugin putting all the modules that you need.

Resources