Develop Reference

Create Java 8 and Java 11 build for single API

We are working to upgrade our API from Java 8 to Java 11.
However we need to support Java 8 and Java 11 both at same time because all clients are not ready to move on Java 11.
Is it possible if we can create maven build with Java 8 and Java 11 without duplicate our repository and without any change in pom.xml each time before create build for Java 8 and Java 11?
Generated artifact should have different name to distinguish Java 8 and Java 11 versions something like xyz-jdk8-0.0.1.jar and xyz-jdk11-.0.1.jar

TL;DR
You don't need that, just build to Java 8 and be happy!
Solving
You can use Maven Build Profiles for this:
https://maven.apache.org/guides/introduction/introduction-to-profiles.html
1. Set your properties to Java 11:
<properties>
<maven.compiler.target>11</maven.compiler.target>
<maven.compiler.source>11</maven.compiler.source>
<maven.compiler.release>11</maven.compiler.release>
</properties>
2. Set your final name:
<build>
<finalName>${project.artifactId}-jdk11-${project.version}</finalName>
</build>
3. Add a profile:
<profile>
<id>jdk-8</id>
<properties>
<maven.compiler.target>1.8</maven.compiler.target>
<maven.compiler.release>1.8</maven.compiler.release>
</properties>
<build>
<finalName>${project.artifactId}-jdk8-${project.version}</finalName>
</build>
</profile>
4. Build:
You will need to run 2 builds, one normal, and other activating the JDK 8 profile:
$ mvn ...
$ mvn ... -P jdk-8
Considerations:
Always use JDK 11 as it can confidently build Java 8 targets;
You don't need target and source properties, but if some plugin fails, put it back.

You should:
Remove from you POM, if present, maven.compiler.source and maven.compiler.target.
Set JAVA_HOME=<<JAVA_8_HOME_FOLDER>>.
Build from Java 8 by mvn clean install.
Take the Java 8 artifact.
Set JAVA_HOME=<<JAVA_11_HOME_FOLDER>>.
Build from Java 11 by mvn clean install.
Take the Java 11 artifact.

I found a way to do that, which lies somewhat in the middle of Java 8 and Java 11. The main problem with the above solution occurs in case you have (or want to define) a module-info.java that can't be parsed in Java 8.
I started considering a solution with <classifier>s, likewise Claudio Weiler above answer but did not wanted to bother having two separate builds (and even two separate branches because I wanted to manage module-info).
I also noticed that some libraries like the JAXB API or activation API (jakarta.xml.bind:jakarta.xml.bind-api:2.3.3) shows a module-info when you use it in Java 11, but is compatible with Java 8 😮.
Digging into how the details of how the build of the com.sun.activiation:jakarta.activation library was made, I found the following solution :
compile the module-info.java with Java 11
compile the rest of your code (including tests) with Java 8. Of course, this has the drawback of not being able to use fully Java 11 features...
You thus need to add the following snippet in the <build> section of your pom.xml:
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<executions>
<execution>
<id>default-compile</id>
<configuration>
<source>1.8</source>
<target>1.8</target>
<excludes>
<exclude>module-info.java</exclude>
</excludes>
</configuration>
</execution>
<execution>
<id>module-info-compile</id>
<goals>
<goal>compile</goal>
</goals>
<configuration>
<release>11</release>
<includes>
<include>module-info.java</include>
</includes>
</configuration>
</execution>
<execution>
<id>default-testCompile</id>
<configuration>
<release>11</release>
</configuration>
</execution>
</executions>
</plugin>
I hope that helps.

How to use maven with both jigsaw and jre 8 support?

I'm building a java project with maven.
I want to make sure several things:
the built jar CAN run on jre8.
the built jar CAN run on jre9, with module/jigsaw.
the built jar CAN be put on maven central.
How should I configure the maven-compiler-plugin?
thanks.
the original repo is at https://github.com/cyanpotion/SDL_GameControllerDB_Util
right now I can pass 2 and 3, but the output jar seems cannot run on jre8.

A multi-release jar can be used to accomplish this purpose; however, if you are only after Jigsaw module support, a dual compilation configuration of Java 8 and 9 with the maven-compiler-plugin is sufficient (demonstrated below).
The following is a build configuration that is able to maintain JRE 8 support, but is compatible with being used as a module in JRE 9+. This can be tweaked to support a project as far back as JRE 1.6, if necessary.
Overview of the following build configuration:
Enforce a $JAVA_HOME JDK 9+ so that module-info.java can be compiled and validated against the sources (ensures that all module dependencies are correctly referenced).
Changes the default-compile execution to NO-OP. By specifying <release>8</release> (or target/source flags), some IDEs during Maven auto-importation (tested with IntelliJ) will assume the language level for this project is Java 8, and produce errors about the project's module-info.java.
Compiles all sources (including module-info.java) for Java 9; this ensures that the module-info.java includes any dependencies used without the project sources.
Compile all sources (excluding module-info.java) for Java 8, overwriting all previously compiled Java 9 classes with Java 8 classes; this means the only Java 9 class (class level 53+) will be module-info.class. All other classes should now be executable on a compliant JRE 8.
Notes:
A caveat is this will compile sources twice, once for Java 8 and another for Java 9. This may significantly increase build times for larger projects (but negligible for smaller projects). This may resolved by placing module-info.java in another source directory (e.g. src/main/java9) and configuring a multi-release JAR (see the first link at the beginning of this message). Note that for proper IDE auto-importation and marking this additional Java 9 source directory correctly, a NO-OP execution with org.codehaus.mojo:build-helper-maven-plugin can be used.
Only module-info.java will have Java 9 support, all other classes are limited to classes/methods/fields/code available in JDK/JRE 8.
Some tooling may need to be updated in your project configuration if it does not support Java 9 module-info.class. Some older variants of the default Maven plugins do not have sufficient support for modules.
<build>
<plugins>
<!-- ensure the project is compiling with JDK 9+ -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>3.0.0-M3</version>
<executions>
<execution>
<id>enforce-jdk9</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<requireJavaVersion>
<version>[1.9,)</version>
<message>JDK 9+ is required for compilation</message>
</requireJavaVersion>
</rules>
</configuration>
</execution>
</executions>
</plugin>
<!-- compile sources -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
<executions>
<!-- disable default phase due to fixed id and position in lifecycle -->
<execution>
<id>default-compile</id>
<phase>none</phase>
<!-- specify source/target for IDE integration -->
<configuration>
<release>9</release>
</configuration>
</execution>
<!-- compile sources with Java 9 to generate and validate module-info.java -->
<execution>
<id>java-9-module-compile</id>
<goals>
<goal>compile</goal>
</goals>
<configuration>
<release>9</release>
</configuration>
</execution>
<!-- recompile sources as Java 8 to overwrite Java 9 class files, except module-info.java -->
<execution>
<id>java-8-compile</id>
<goals>
<goal>compile</goal>
</goals>
<configuration>
<!-- specify JDK 9+ release flag to ensure no classes/methods later than Java 8 are used accidentally -->
<release>8</release>
<!-- exclude module-info.java from the compilation, as it is unsupported by Java 8 -->
<excludes>
<exclude>module-info.java</exclude>
</excludes>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>

I've done it. See my project, the IPAddress Java library. You compile with Java 9 compiler level, then you recompile everything except the module-info.java with Java 8 compile level.. So you have a Java 8 jar with a Java 9 module-info. You can see the compile commands in my ant xml script on GitHub.
There was originally an issue with Android studio that has since been resolved, it would not ignore the module-info. More recent Android studio versions are fine, and so are all Java platforms and environments. Java 9 jres and up will recognize the module-info, Java 8 will not, Java 8 and earlier will ignore it.
My jar is also in maven central, so it is satisfying your 3 requirements. Try it out in your dev environment to see it work, using Java 8 or later jres.
Multi-release jars are not necessary and not worth the trouble.
When I was researching this same question I found this same solution in use with an Apache project, so I am not the only one doing it.

Specifying Java version in maven - differences between properties and compiler plugin

I'm not very experienced with Maven and while experimenting with multi-module project I started wondering how can I specify Java version for all my child modules in parent Maven pom. Until today I was using just:
<properties>
<java.version>1.8</java.version>
</properties>
...but when researching I found that you can also specify Java version in Maven compiler plugin, like that:
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
</plugins>
And then wrap this into plugin management tag to enable child poms usage of this. So the first question is this:
What are the differences beetwen setting Java version in properties and in Maven compiler plugin?
I couldn't find clear answer but in process of researching I found that you can also specify Java version in this way:
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
</properties>
...which suggest that compiler plugin is there even if I don't explicit declare it. Running mvn package outputs with
maven-compiler-plugin:3.1:compile (default-compile) # testproj ---
...and some other plugins that I didn't declare.
So are those plugins default, hidden part of Maven pom? Are there any differences between setting source/target in properties and in Maven plugin configuration element?
Some other questions are - which way should be used (and when if they are not equal)? Which one is best for multi-module project and what happens if Java version specified in pom is different than version pointed in JAVA_HOME?

How to specify the JDK version?
Use any of three ways: (1) Spring Boot feature, or use Maven compiler plugin with either (2) source & target or (3) with release.
Spring Boot
<java.version> is not referenced in the Maven documentation.
It is a Spring Boot specificity.
It allows to set the source and the target java version with the same version such as this one to specify java 1.8 for both :
1.8
Feel free to use it if you use Spring Boot.
maven-compiler-plugin with source & target
Using maven-compiler-plugin or maven.compiler.source/maven.compiler.target properties are equivalent.
That is indeed :
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
</plugins>
is equivalent to :
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
</properties>
according to the Maven documentation of the compiler plugin
since the <source> and the <target> elements in the compiler configuration use the properties maven.compiler.source and maven.compiler.target if they are defined.
source
The -source argument for the Java compiler.
NOTE: Since 3.8.0 the default value has changed from 1.5 to 1.6. Since 3.9.0 the default value has changed from 1.6 to 1.7
Default value is: 1.7.
User property is: maven.compiler.source.
target
The -target argument for the Java compiler.
NOTE: Since 3.8.0 the default value has changed from 1.5 to 1.6. Since 3.9.0 the default value has changed from 1.6 to 1.7
Default value is: 1.6.
User property is: maven.compiler.target.
About the default values for source and target, note that
since the 3.8.0 of the maven compiler, the default values have changed from 1.5 to 1.6.
maven-compiler-plugin with release instead of source & target
The maven-compiler-plugin 3.6 and later versions provide a new way :
org.apache.maven.plugins
maven-compiler-plugin
3.8.0
9
You could also declare just :
<properties>
<maven.compiler.release>9</maven.compiler.release>
</properties>
But at this time it will not work as the maven-compiler-plugin default version you use doesn't rely on a recent enough version.
The Maven release argument conveys release : a new JVM standard option that we could pass from Java 9 :
Compiles against the public, supported and documented API for a
specific VM version.
This way provides a standard way to specify the same version for the source, the target and the bootstrap JVM options.
Note that specifying the bootstrap is a good practice for cross compilations and it will not hurt if you don't make cross compilations either.
Which is the best way to specify the JDK version?
The first way (<java.version>) is allowed only if you use Spring Boot.
For Java 8 and below :
About the two other ways : valuing the maven.compiler.source/maven.compiler.target properties or using the maven-compiler-plugin, you can use one or the other. It changes nothing in the facts since finally the two solutions rely on the same properties and the same mechanism : the maven core compiler plugin.
Well, if you don't need to specify other properties or behavior than Java versions in the compiler plugin, using this way makes more sense as this is more concise:
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
</properties>
From Java 9 :
The release argument (third point) is a way to strongly consider if you want to use the same version for the source and the target.
What happens if the version differs between the JDK in JAVA_HOME and which one specified in the pom.xml?
It is not a problem if the JDK referenced by the JAVA_HOME is compatible with the version specified in the pom but to ensure a better cross-compilation compatibility think about adding the bootstrap JVM option with as value the path of the rt.jar of the target version.
An important thing to consider is that the source and the target version in the Maven configuration should not be superior to the JDK version referenced by the JAVA_HOME.
A older version of the JDK cannot compile with a more recent version since it doesn't know its specification.
To get information about the source, target and release supported versions according to the used JDK, please refer to java compilation : source, target and release supported versions.
How handle the case of JDK referenced by the JAVA_HOME is not compatible with the java target and/or source versions specified in the pom?
For example, if your JAVA_HOME refers to a JDK 1.7 and you specify a JDK 1.8 as source and target in the compiler configuration of your pom.xml, it will be a problem because as explained, the JDK 1.7 doesn't know how to compile with.
From its point of view, it is an unknown JDK version since it was released after it.
In this case, you should configure the Maven compiler plugin to specify the JDK in this way :
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.8</source>
<target>1.8</target>
<compilerVersion>1.8</compilerVersion>
<fork>true</fork>
<executable>D:\jdk1.8\bin\javac</executable>
</configuration>
</plugin>
You could have more details in examples with maven compiler plugin.
It is not asked but cases where that may be more complicated is when you specify source but not target. It may use a different version in target according to the source version. Rules are particular : you can read about them in the Cross-Compilation Options part.
Why the compiler plugin is traced in the output at the execution of the Maven package goal even if you don't specify it in the pom.xml?
To compile your code and more generally to perform all tasks required for a maven goal, Maven needs tools. So, it uses core Maven plugins (you recognize a core Maven plugin by its groupId : org.apache.maven.plugins) to do the required tasks : compiler plugin for compiling classes, test plugin for executing tests, and so for... So, even if you don't declare these plugins, they are bound to the execution of the Maven lifecycle.
At the root dir of your Maven project, you can run the command : mvn help:effective-pom to get the final pom effectively used. You could see among other information, attached plugins by Maven (specified or not in your pom.xml), with the used version, their configuration and the executed goals for each phase of the lifecycle.
In the output of the mvn help:effective-pom command, you could see the declaration of these core plugins in the <build><plugins> element, for example :
...
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<version>2.5</version>
<executions>
<execution>
<id>default-clean</id>
<phase>clean</phase>
<goals>
<goal>clean</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<id>default-testResources</id>
<phase>process-test-resources</phase>
<goals>
<goal>testResources</goal>
</goals>
</execution>
<execution>
<id>default-resources</id>
<phase>process-resources</phase>
<goals>
<goal>resources</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<executions>
<execution>
<id>default-compile</id>
<phase>compile</phase>
<goals>
<goal>compile</goal>
</goals>
</execution>
<execution>
<id>default-testCompile</id>
<phase>test-compile</phase>
<goals>
<goal>testCompile</goal>
</goals>
</execution>
</executions>
</plugin>
...
You can have more information about it in the introduction of the Maven lifeycle in the Maven documentation.
Nevertheless, you can declare these plugins when you want to configure them with other values as default values (for example, you did it when you declared the maven-compiler plugin in your pom.xml to adjust the JDK version to use) or when you want to add some plugin executions not used by default in the Maven lifecycle.

None of the solutions above worked for me straight away. So I followed these steps:
Add in pom.xml:
<properties>
<maven.compiler.target>1.8</maven.compiler.target>
<maven.compiler.source>1.8</maven.compiler.source>
</properties>
Go to Project Properties > Java Build Path, then remove the JRE
System Library pointing to JRE1.5.
Force updated the project.

The below steps work for me like charm! so thought to share with everyone.
These are the lines i added in the pom.xml file to work with a basic project. I am using Java 12 (you can replace yours 11, 10, 1.8 etc).
<properties>
<maven.compiler.source>12</maven.compiler.source>
<maven.compiler.target>12</maven.compiler.target>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
<configuration>
<release>12</release>
</configuration>
</plugin>
</plugins>
</build>
After changing the pom file please reload your project so that IDE can download/fetch the plugin to the project. (For IntelijIDEA: Right-click on pom.xml -> Go to maven -> Reload project).
please make sure to configure the desire version in your IDE as well.

if you are using IntelliJ idea maven build.

Consider the alternative:
<properties>
<javac.src.version>1.8</javac.src.version>
<javac.target.version>1.8</javac.target.version>
</properties>
It should be the same thing of maven.compiler.source/maven.compiler.target but the above solution works for me, otherwise the second one gets the parent specification (I have a matrioska of .pom)

For NetBeans IDE, changing project properties - (Jersey Service) - Categories > Sources >
Selected 'Source/Binary Format' as 1.8.

How to run a multiple module project using Maven on NetBeans [duplicate]

I am new to maven. So I have a project with pom.xml file. So I ran that with maven and the build was successful. I have glassfish. Glassfish is already running separately. So now what is the next step to run the project with Glassfish? My IDE is eclipse.

You have to first tell Maven to build the WAR, check out this plugin for that: http://maven.apache.org/plugins/maven-war-plugin/.
Then you need to tell maven how to deploy to glassfish, you can either configure a Maven execution plugin to do this (see here: https://www.mojohaus.org/exec-maven-plugin/). Or you can look around for a custom plugin devoted to integrating maven with glassfish. This one looks promising, but I have not used it: http://maven-glassfish-plugin.java.net/.
Maven provides a lot of basic functionality out of the box, but most of the cooler stuff with build automation is done through plugins.
Update
Just updating to add a very simple Pom that will do a auto-deployment. Note: if you just run a "mvn clean install", with the packaging set to 'war', maven will build the .war file for you and place it in the target/ folder. You can take this and deploy it to glassfish manually if you just want to get started.
Below is part of a very simple pom that uses the Maven execution plugin to auto-deploy to glassfish as a function of the build:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>exec</goal>
</goals>
<phase>install</phase>
</execution>
</executions>
<configuration>
<executable>${path-to-asadmin-util}</executable>
<arguments>
<argument>deploy</argument>
<argument>--user=${username}]</argument>
<argument>--passwordfile=${password-file}</argument>
<argument>--host=localhost</argument>
<argument>--port=4848</argument>
<argument>target/${project.name}</argument>
</arguments>
</configuration>
</plugin>
</plugins>
</build>
This basically just calls the deploy command on the glassfish asadmin utility[1]. You need to fill in the following variables:
${path-to-asadmin-util} --> this is the path to your asadmin utility
(normally in the glassfish_home/bin)
${username} --> glassfish admin username
${password-file} --> password file for logging into glassfish
admin[2]
${project.name} --> name of your war
If you want to get more complicated I suggest taking a look at this thread: GlassFish v3 and glassfish-maven-plugin (Mac).
[1] - http://docs.oracle.com/cd/E18930_01/html/821-2433/deploy-1.html#SJSASEEREFMANdeploy-1
[2] - http://docs.oracle.com/cd/E18930_01/html/821-2435/ghgrp.html#ghytn

Additonnaly, you should have a glance at this StackOverflow thread, dealing with maven deployement in glassifsh : https://stackoverflow.com/a/1836691/1047365.
For further understanding of Maven, you should REALLY read this (free) book : http://www.sonatype.com/books/mvnref-book/reference/. This is THE reference for Maven.
We can explain you what Maven is doing, producing, etc ... but Sonatype made a great work and you'll probably learn more reading it than we could ever do !
Regards.

I found this tutorial useful: http://tshikatshikaaa.blogspot.com/2012/05/introduction-to-maven-concepts-crash.html

Can Maven Deploy a Module to JBoss?

We have a Maven project that we are using to deploy several wars to a JBoss server. We recently noticed that one of the jars that a couple of our wars depend on, uses Xerial. When Xerial starts it tries to load up a native driver, but only the first one successfully loads the native driver and the rest fail and fall back on a pure Java implementation because the native driver is already in a classloader. We would really like to gain the performance back by being able to load the native driver on all the wars.
It looks to me like the best way to do this would be add the jar we depend on to the JBoss server as a module, and then have the services depend on it.
My question is, is there a way we can get our Maven build to do this? Or are we going about this in the completely wrong way?

After a few days of looking, and talking to a couple of people who were much more familiar with JBoss-Maven interaction than me, it turns out the answer to my question is that it cant currently be done. There is no Maven plugin capable of deploying a Module to JBoss. This is largely in part to the fact that the modules are only loaded by JBoss when it starts, although if anyone is feeling particularly ambitious and wants to write their own Maven plugin, it could theoretically be worked around.
The answer #Robert Scholte left is a good one, and I learned from it, however it didn't actually answer my question.

First and most of all Apache Maven is a build management tool. It will "package" a project and will normally upload it to a repository so it can be used by other projects.
However, there are plugins available, which can deploy to JBoss:
http://mojo.codehaus.org/jboss-maven-plugin/ (maybe combined with http://mojo.codehaus.org/jboss-packaging-maven-plugin/ )
http://cargo.codehaus.org/
The first is JBoss specific, the latter a generic Java EE-container deploy plugin

I'd suggest to put your jar in the lib folder of the jboss server. This way, the jar is loaded in the shared classpath when the server starts. This will definitively serve the purpose.
Here is the jboss folder structured expleained.
http://docs.jboss.org/jbossas/guides/installguide/r1/en/html/dirs.html

I know this question has been marked as answered and the answer is that this currently is not possible, but I want to provide an alternative view. I am currently deploying Jboss modules to EAP 6.1 with Maven at my job. What we have done is use the maven-wagon plugin to scp the module to the tmp directory on the jboss server. I then use the maven-wagon plugin to issue a ssh command to the server to call the jboss-cli.sh script and tell it to perform a module installation. Here is a sample config:
<profile>
<id>uat</id>
<activation>
<activeByDefault>false</activeByDefault>
<property>
<name>switchEnv</name>
<value>uat</value>
</property>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>wagon-maven-plugin</artifactId>
<version>1.0-beta-5</version>
<executions>
<execution>
<id>upload-file-qa-server-one</id>
<phase>deploy</phase>
<goals>
<goal>upload-single</goal>
</goals>
<configuration>
<fromFile>${project.build.directory}/${project.build.finalName}.${project.packaging}</fromFile>
<url>scp://jboss#jboss-server-1/tmp/</url>
<toFile>${project.name}.${project.packaging}</toFile>
</configuration>
</execution>
<execution>
<id>upload-file-qa-server-two</id>
<phase>deploy</phase>
<goals>
<goal>upload-single</goal>
</goals>
<configuration>
<fromFile>${project.build.directory}/${project.build.finalName}.${project.packaging}</fromFile>
<url>scp://jboss#jboss-server-2/tmp/</url>
<toFile>${project.name}.${project.packaging}</toFile>
</configuration>
</execution>
<execution>
<id>install-module-qa-server-one</id>
<phase>deploy</phase>
<goals>
<goal>sshexec</goal>
</goals>
<configuration>
<serverId>jboss-server-1</serverId>
<url>scp://jboss#jboss-server-1/tmp</url>
<commands>
<command>/opt/jboss/bin/jboss-cli.sh -c --command="module add --name=${project.name} --resources=/tmp/${project.name}.${project.packaging} --dependencies=javax.api,javax.transaction.api"</command>
<command>sleep 5</command>
<command>rm -f /tmp/${project.build.finalName}.${project.packaging}</command>
</commands>
</configuration>
</execution>
<execution>
<id>install-module-qa-server-two</id>
<phase>deploy</phase>
<goals>
<goal>sshexec</goal>
</goals>
<configuration>
<serverId>jboss-server-2</serverId>
<url>scp://jboss#jboss-server-2/tmp</url>
<commands>
<command>/opt/jboss/bin/jboss-cli.sh -c --command="module add --name=${project.name} --resources=/tmp/${project.name}.${project.packaging} --dependencies=javax.api,javax.transaction.api"</command>
<command>sleep 5</command>
<command>rm -f /tmp/${project.build.finalName}.${project.packaging}</command>
</commands>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
<profile>

It´s not possible beause you have to use an OSGI approach.
To use maven try to work with OSGI within EAP, but it depends what you looking for. OSGI is supported since JBoss EAP 6.1.
If you are trying to work with EAI try to work with JBoss Fuse instead of EAP.
Then you will work with maven repositories, nexus or similar, hot deploy and all OSGI bundles stuff.