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

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).

Related

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!

copy jars used by plugin to single folder using Maven

In my POM.xml other the plugin configuration, i am not required to configure any dependenices to run the plugin. I would like to download dependent jars used by plugin(soapui-maven-plugin) from the repository into one single folder. I tried the command "mvn dependency:copy-dependencies", but no jars are copied. Is there any way to do it?
<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>service.report</groupId>
<artifactId>service-report</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>Maven 2 SoapUI Sample</name>
<build>
<plugins>
<plugin>
<groupId>com.smartbear.soapui</groupId>
<artifactId>soapui-maven-plugin</artifactId>
<version>5.0.0</version>
<executions>
<execution>
<phase>test</phase>
<goals>
<goal>loadtest</goal>
</goals>
<configuration>
<projectFile>${basedir}/src/main/resources/xxxxx-soapui-project.xml</projectFile>
<testSuite>xxxx</testSuite>
<testCase>sssss</testCase>
<loadTest>LoadTest 1</loadTest>
<outputFolder>${basedir}/target/surefire</outputFolder>
<junitReport>true</junitReport>
<exportAll>true</exportAll>
<printReport>true</printReport>
<testFailIgnore>false</testFailIgnore>
<!-- <projectProperties>
<value>message=Hello World!</value>
</projectProperties> -->
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
mvn dependency:copy-dependencies is only applied to current maven module only. It won't works on plugins. If you want to download all soapui-maven-plugin dependencies, you need to execute command from soapui-maven-plugin project. You can follow the following steps. I assumed you familiar with GIT CLI. If not, you need to manually download from https://github.com/SmartBear/soapui
git clone https://github.com/SmartBear/soapui
cd soapui/soapui-maven-plugin
mvn dependency:copy-dependencies
You can get list of dependencies in soapui/soapui-maven-plugin/target/dependency (total 82files)
[ERROR] Failed to execute goal on project soapui-maven-plugin: Could not resolve dependencies for project com.smartbear.soapui:soapui-maven-plugin:maven-plugin:5.0.0: Could not find artifact javafx:jfxrt:jar:2.2 at specified path (your jdk path)
If you get the above error, it means your maven jdk is version jdk.1.7 (u6 or earlier) which is not installed with javafx. Download newer jdk that comes with javafx at http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html . Remember change your maven jdk to this newer jdk.
If you want to use the dependency-plugin you could add the dependencies to the pom...and download with the depepndency-plugin...
It works right for me...
<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>com.ab.forge.utility.copydependenciespom</groupId>
<artifactId>copydependenciespom</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>pom</packaging>
<!-- BINARIES -->
<dependencies>
<!--CUSTOMER RETURN -->
<dependency>
<groupId>com.ab...</groupId>
<artifactId>customerret.....</artifactId>
<version>1.0-SNAPSHOT</version>
<scope>compile</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<phase>install</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<overWriteIfNewer>true</overWriteIfNewer>
<overWriteReleases>true</overWriteReleases>
<overWriteSnapshots>true</overWriteSnapshots>
<excludeGroupIds>com.ab.ah.scad.acl</excludeGroupIds>
<excludeTypes>pom</excludeTypes>
<includeGroupIds>com.ab.oneleo</includeGroupIds>
<outputDirectory>${outputDirectory}</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
After I just run the install passing the -DoutputDirectory parameter....
Try this...
To view all the plugin dependencies you can run a dependency:tree on the pom (where the plugin in configured)

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

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.

Maven descriptor (META-INF/maven) duplicate entry in archive

I'm facing a problem with maven build. I have several ejb projects. After maven build the jar-file contains the maven descriptor in META-INF/maven twice, i.e. if I extract files to disk 7zip asks to overwrite files although extracted to a new folder. If a specify <addMavenDescriptor>false</addMavenDescriptor> in the archive-tag of the ejb plugin then the maven decriptor is still generated but only once. Is there another place where I can disable maven descriptor generation or does anybody know the reason for the duplicate generation?
Maven version is: 3.0.3
Project structure is like:
-pom
-ejb
Here is the pom.xml of the EJB module:
<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>
<artifactId>TestMavenDescriptors</artifactId>
<groupId>de.test</groupId>
<version>0.0.1-SNAPSHOT</version>
<relativePath>..</relativePath>
</parent>
<artifactId>TestEJB</artifactId>
<packaging>ejb</packaging>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ejb-plugin</artifactId>
<version>2.3</version>
<configuration>
<ejbVersion>3.1</ejbVersion>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.0.2</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
</configuration>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>6.0</version>
<scope>provided</scope>
</dependency>
</dependencies>
Here is the pom.xml of the parent project.
<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>de.test</groupId>
<artifactId>TestMavenDescriptors</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>pom</packaging>
<modules>
<module>TestEJB</module>
</modules>
</project>
I found out that this is a problem special to eclipse version (I have RAD 8 trial) and possibily of the m2e plugin version. The above behavior (duplicate generation of maven descriptors) occurs only if I have the EJB project in my workspace added. That means if I remove the EJB project from workspace (without deleting contents on disk) such that only the hierarchal parent maven project (pom packaged) is existing in the workspace (which contains the EJB project but EJB project is then not known to eclipse) then everything works fine. Strange, isn't it?!
BTW: on current eclipse (java ee package) this doesn't occur, all fine there.

Resources