I want cargo maven plugin to start a Tomcat7 so i put into my pom:
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.2.0</version>
<!-- minimal configuration to let adb run (mvn package org.codehaus.cargo:cargo-maven2-plugin:run) in a local tomcat -->
<configuration>
<containerId>tomcat7x</containerId>
<containerUrl>http://archive.apache.org/dist/tomcat/tomcat-7/v7.0.16/bin/apache-tomcat-7.0.16.zip
</containerUrl>
<configuration>
<properties>
<cargo.servlet.port>1718</cargo.servlet.port>
</properties>
</configuration>
</configuration>
</plugin>
The Problem is if i run:
mvn package org.codehaus.cargo:cargo-maven2-plugin:run
all is working fine but if i run
mvn package org.codehaus.cargo:cargo-maven2-plugin:start
the configuration set in pom is beeing ignored:"No container defined, using a default [jetty6x, embedded] container"
you can reproduce this easily. just create an war-maven app:
mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-webapp -DarchetypeArtifactId=maven-archetype-webappp
Then add the code above to pom and run both commands.
So how to set ContainerId and Url properly for goal start -- Am I missing something?!
so i contacted cargo support. the configuration above works indeed only with run goal, but there is also a configuration that works with both (the cargo doc is somehow misguiding):
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.2.0</version>
<!-- minimal configuration to let adb run (mvn package org.codehaus.cargo:cargo-maven2-plugin:run) in a local tomcat -->
<configuration>
<container>
<containerId>tomcat7x</containerId>
<zipUrlInstaller>
<url>http://archive.apache.org/dist/tomcat/tomcat-7/v7.0.16/bin/apache-tomcat-7.0.16.zip</url>
</zipUrlInstaller>
</container>
<configuration>
<properties>
<cargo.servlet.port>1718</cargo.servlet.port>
</properties>
</configuration>
</configuration>
</plugin>
notice the additional container and zipUrlInstaller tag instead of containerUrl.
Related
I'm trying to use the cargo maven plugin just to start a JBoss AS 7 server from maven, without executing any deployments.
I'm able to start the server but as I can read in cargo pluging documentation the goals cargo:run and cargo:start will deploy automatically the current project if project's packaging is Java EE (WAR, EAR, etc.) and if I'm not using deployable sections in the plugin configuration.
This is my simple cargo plugin section in the pom file:
<plugins>
...
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.4.13</version>
<configuration>
<!-- Container configuration -->
<container>
<containerId>jboss73x</containerId>
<home>${jboss-as.home}</home>
</container>
</configuration>
</plugin>
...
</plugins>
Since I'm not using deployables and the project packaging is war, cargo automatically deploys my project when the server starts.
I would like use the goal cargo:run just to start my local server without deploy any project artifacts.
Is it possible with the cargo maven plugin? Any idea or alternative?
I think that it might not be possible to ask the plugin not to deploy the project in which it is configured, when you are in the case of a deployable archive project.
But what you could do is creating a pom project, with no source in it just the pom.xml, and run your cargo plugin in that project.
My example below starts and stops the cargo plugin when I run the goal install on 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>fr.fabien.perso</groupId>
<artifactId>pom-project-tests</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>pom</packaging>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<executions>
<execution>
<id>start-container</id>
<phase>pre-integration-test</phase>
<goals>
<goal>start</goal>
</goals>
</execution>
<execution>
<id>stop-container</id>
<phase>post-integration-test</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
</executions>
<configuration>
<container>
<type>embedded</type>
</container>
</configuration>
</plugin>
</plugins>
</build>
</project>
Yes Yersan, it is possible to start the server without self built artifact deployment. It can be achieved by adding an empty <deployer /> element on the <configuration> tag of the project.
I found the info at the cargo plugin reference site. In addition, I have tested the configuration in my local project to confirm it works.
I am currently setting the port via a jetty.xml file and I've been trying to figure out from the new documentation how to actually define an httpConnector through the Maven plugin's configuration. The docs on Eclipse's site seem a bit vague on it and I've been trying to figure this out for a while, thus ending up using a jetty.xml. I'd like to find out the proper way to do this now.
I'm currently using org.eclipse.jetty:jetty-maven-plugin:9.2.1.v20140609.
The jetty-maven-plugin documentation (for jetty 11 at the time of this answer - update) states that you can either configure the httpConnector element in the pom.xml file to setup the ServerConnector preferences or use the jetty.http.port system property to change the port or use the Jetty descriptor i.e. the way you are doing it actually.
Then you have several options:
(Java) System Property:
Change the port when just running your application through the mvn command:
mvn jetty:run -Djetty.http.port=9999
(Maven) Project Property:
Set the property inside your project pom.xml descriptor file:
<properties>
<jetty.http.port>9999</jetty.http.port>
</properties>
Then just run your application through the Jetty plugin and the port will be picked up automatically:
mvn jetty:run
(Maven) Jetty Plugin Configuration:
Set the port in your plugin declaration inside the pom.xml file:
<build>
<plugins>
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>9.2.1.v20140609</version>
<configuration>
<httpConnector>
<!--host>localhost</host-->
<port>9999</port>
</httpConnector>
</configuration>
</plugin>
</plugins>
</build>
EDIT
In new versions of jetty-maven-plugin, jetty.http.port is the default port property and jetty.port won't work as in previous plugin versions.
Run following command:
mvn jetty:run -Djetty.port=9999
I guess mvn jetty:run -Djetty.http.port=9999 is deprecated. It didn't work for me.
You may configure the port through the pom.xml:
<build>
<plugins>
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>9.2.1.v20140609</version>
<configuration>
<httpConnector>
<port>9999</port>
</httpConnector>
</configuration>
</plugin>
</plugins>
</build>
This works for me, confirmed as I am currently debugging the server in my chrome on port 8088.
mvn jetty:run -Dhttp.port=8088
By Default Jetty runs on 8080 port, if any application like oracle DB using that port in your system then Jetty server will not start and gives some BIND exception. to overcome this if your project is maven project then in pom.xml file use below code, then it works perfectly(here i am using port 8888 which is free in my system)
<!-- The Jetty plugin allows us to easily test the development build by
running jetty:run on the command line. -->
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>${jetty.plugin.version}</version>
<configuration>
<scanIntervalSeconds>2</scanIntervalSeconds>
<httpConnector>
<host>localhost</host>
<port>8888</port>
</httpConnector>
</configuration>
</plugin>
<connectors>
<connector>
<port>9999</port>
</connector>
</connectors>
in pom.xml file
Every time I make even the tiniest change to my POM Intellij removes the .war extension for my exploded artifact in the Project Structure output directory setting. This causes an error in Intellij's Run/Debug configuration:
Artifact 'XXXX:war exploded' has invalid extension.
In order to resolve the issue I must manually override the Project Structure output directory setting. Every time I make even the tiniest change to the POM I must go back to the Output directory setting and manually append ".war" to the end of the Output directory setting. This is getting very old and frustrating.
e.g. I must change this:
E:\workarea\enterp\application\target\application
to this:
E:\workarea\enterp\application\target\application.war
If I manually set the Maven WAR plugin outputDirectory configuration as follows, this does not help at all:
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>${maven.war.plugin.version}</version>
<configuration>
<!-- Output directory of artifact:war exploded keeps losing the .war extension -->
<outputDirectory>${project.build.directory}.war</outputDirectory>
</configuration>
</plugin>
How can I resolve this problem?
EDIT:
Here's the complete build config:
<build>
<!-- Maven will append the version to the finalName (which is the name
given to the generated war, and hence the context root) -->
<finalName>${project.artifactId}</finalName>
<plugins>
<!-- Compiler plugin enforces Java 1.6 compatibility and activates annotation
processors -->
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>${maven.compiler.plugin.version}</version>
<configuration>
<source>${maven.compiler.source}</source>
<target>${maven.compiler.target}</target>
</configuration>
</plugin>
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>${maven.war.plugin.version}</version>
<configuration>
<!-- Output directory of artifact:war exploded keeps losing the .war extension -->
<outputDirectory>${project.build.directory}/${project.artifactId}.war</outputDirectory>
<!-- Java EE 7 doesn't require web.xml, Maven needs to catch up! -->
<failOnMissingWebXml>false</failOnMissingWebXml>
</configuration>
</plugin>
<!-- The WildFly plugin deploys your war to a local WildFly container -->
<!-- To use, run: mvn package wildfly:deploy -->
<plugin>
<groupId>org.wildfly.plugins</groupId>
<artifactId>wildfly-maven-plugin</artifactId>
<version>${version.wildfly.maven.plugin}</version>
</plugin>
</plugins>
</build>
SECOND EDIT:
I discovered that one solution is to append ".war" to ${project.artifactId} in the build configuration, e.g.:
<finalName>${project.artifactId}.war</finalName>
and remove outputDirectory from the plugin configuration. So the build config should look like this:
<build>
<!--
Maven will make finalName the name of the generated war.
NOTE: Output directory of artifact:war exploded keeps losing the .war extension
http://youtrack.jetbrains.com/issue/IDEA-86484
http://youtrack.jetbrains.com/issue/IDEA-95162
The solution is to append ".war" to ${project.artifactId}, below:
-->
<finalName>${project.artifactId}.war</finalName>
<plugins>
<!-- Compiler plugin enforces Java 1.6 compatibility and activates annotation
processors -->
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>${maven.compiler.plugin.version}</version>
<configuration>
<source>${maven.compiler.source}</source>
<target>${maven.compiler.target}</target>
</configuration>
</plugin>
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>${maven.war.plugin.version}</version>
<configuration>
<!-- Java EE 7 doesn't require web.xml, Maven needs to catch up! -->
<failOnMissingWebXml>false</failOnMissingWebXml>
</configuration>
</plugin>
<!-- The WildFly plugin deploys your war to a local WildFly container -->
<!-- To use, run: mvn package wildfly:deploy -->
<plugin>
<groupId>org.wildfly.plugins</groupId>
<artifactId>wildfly-maven-plugin</artifactId>
<version>${version.wildfly.maven.plugin}</version>
</plugin>
</plugins>
</build>
DISCLAIMER: If you use this workaround just be aware that when you deploy an unexploded WAR artifact the file name will be named XXXX.war.war. It works -- I deployed the artifact as a WAR file in Intellij -- but it's ugly.
INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) JBAS015876: Starting deployment of "XXXX.war.war" (runtime-name: "XXXX.war.war)"
If someone can tell me how to configure the Intellij project to work with Maven to select one or the other finalName values depending on whether I'm deploying a WAR file vs. exploded artifact then this question will be sufficiently answered.
<!-- Exploded artifact -->
<finalName>${project.artifactId}.war</finalName>
<!-- WAR file (unexploded) artifact -->
<finalName>${project.artifactId}</finalName>
There's a way to fix this in IntelliJ, without changing your pom.xml file(s), by adding an artifact with a reference to the exploded war (or in my case, the exploded ear) and it won't get stomped every time IntelliJ re-imports the maven pom(s). Here's how:
Stop/undeploy your current artifact deployment
Edit your run config, and in the Deployment tab, remove the current exploded war/ear artifact
Open the project's Artifacts settings and add a new artifact
Use the plus button to add a new war or (in my case) ear exploded artifact
Give it a name, then edit the Output directory to add the appropriate extension (.war or .ear)
In the Output Layout section where you see <output root>, use the plus button to add an Artifact
Select the desired exploded artifact
Edit your run config again, and in the Deployment tab, add the new workaround exploded artifact
Thanks to Nikolay Chashnikov for describing this in his comment on the bug report
Actually, you should leave the finalName attribute alone, otherwise you'll get the problems you describe. Rather, you should change the config for the maven war plugin to use the webappDirectory like this:
<plugin>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<webappDirectory>${project.build.directory}/${project.artifactId}.${project.packaging}</webappDirectory>
<failOnMissingWebXml>false</failOnMissingWebXml>
</configuration>
</plugin>
If we are talking about WAR inside EAR there is another way to resolve your problem by using correct configuration inside maven-ear-plugin. WAR pom.xml should be left as is, without any changes, but EAR pom.xml should contains something like this. (please, pay your attention to <unpack>${unpack.wars}</unpack>)
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ear-plugin</artifactId>
<version>2.9</version>
<configuration>
<version>6</version>
<defaultLibBundleDir>lib</defaultLibBundleDir>
<generateApplicationXml>false</generateApplicationXml>
<archive>
<manifest>
<addClasspath>true</addClasspath>
</manifest>
</archive>
<modules>
<webModule>
<groupId>com.test.app</groupId>
<artifactId>test-app-war</artifactId>
<unpack>${unpack.wars}</unpack>
</webModule>
</modules>
</configuration>
</plugin>
and then you can add profiles default and debug for proper artifact assembling.
<profiles>
<profile>
<id>default</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<unpack.wars>false</unpack.wars>
</properties>
</profile>
<profile>
<id>debug</id>
<activation>
<property>
<name>debug</name>
</property>
</activation>
<properties>
<unpack.wars>true</unpack.wars>
</properties>
</profile>
</profiles>
use debug profile inside IntelliJ IDEA for expanding wars and default profile for building artifacts in command line or CI (default profile would be active if no profile were provided, so your build will works as previously).
With this solution HotSwap and resources updates works as expected.
Hope this helps.
I think it's the same as this question: IntelliJ Artifact has invalid extension
Add a .war extension to the output directory as shown in my answer: https://stackoverflow.com/a/25569266/968988
I have a JAR in my Android project and I want it to be added to final APK.
Okay, here I go:
<dependency>
<groupId>com.loopj.android.http</groupId>
<artifactId>android-async-http</artifactId>
<version>1.3.2</version>
<type>jar</type>
<scope>system</scope>
<systemPath>${project.basedir}/libs/android-async-http-1.3.2.jar</systemPath>
</dependency>
But when I am running mvn package I am getting a warning:
[WARNING] Some problems were encountered while building the effective model for **apk:1.0
[WARNING] 'dependencies.dependency.systemPath' for com.loopj.android.http:android-async-http:jar should not point at files within the project directory, ${project.basedir}/libs/android-async-http-1.3.2.jar will be unresolvable by dependent projects # line 36, column 25
And in the final APK there are no JARs.
How do I fix that?
I don't know the real reason but Maven pushes developers to install all libraries (custom too) into some maven repositories, so scope:system is not well liked, A simple workaround is to use maven-install-plugin
follow the usage:
write your dependency in this way
<dependency>
<groupId>com.mylib</groupId>
<artifactId>mylib-core</artifactId>
<version>0.0.1</version>
</dependency>
then, add maven-install-plugin
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<version>2.5.2</version>
<executions>
<execution>
<id>install-external</id>
<phase>clean</phase>
<configuration>
<file>${basedir}/lib/mylib-core-0.0.1.jar</file>
<repositoryLayout>default</repositoryLayout>
<groupId>com.mylib</groupId>
<artifactId>mylib-core</artifactId>
<version>0.0.1</version>
<packaging>jar</packaging>
<generatePom>true</generatePom>
</configuration>
<goals>
<goal>install-file</goal>
</goals>
</execution>
</executions>
</plugin>
pay attention to phase:clean, to install your custom library into your repository, you have to run mvn clean and then mvn install
You will need to add the jar to your local maven repository. Alternatively (better option) specify the proper repository (if one exists) so it can be automatically downloaded by maven
In either case, remove the <systemPath> tag from the dependency
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<includeSystemScope>true</includeSystemScope>
</configuration>
</plugin>
Try this.
System scope was only designed to deal with 'system' files; files sitting in some fixed location. Files in /usr/lib, or ${java.home} (e.g. tools.jar). It wasn't designed to support miscellaneous .jar files in your project.
The authors intentionally refused to make the pathname expansions work right for that to discourage you. As a result, in the short term you can use install:install-file to install into the local repo, and then some day use a repo manager to share.
Try this configuration. It worked for me:
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.4</version>
<configuration>
<warSourceDirectory>mywebRoot</warSourceDirectory>
<warSourceExcludes>source\**,build\**,dist\**,WEB-INF\lib\*,
WEB-INF\classes\**,build.*
</warSourceExcludes>
<webXml>myproject/source/deploiement/web.xml</webXml>
<webResources>
<resource>
<directory>mywebRoot/WEB-INF/lib</directory>
<targetPath>WEB-INF/lib</targetPath>
<includes>
<include>mySystemJar1.jar.jar</include>
<include>mySystemJar2.jar</include>
</includes>
</resource>
</webResources>
</configuration>
</plugin>
Use a repository manager and install this kind of jars into it. That solves your problems at all and for all computers in your network.
mvn install:install-file -DgroupId=com.paic.maven -DartifactId=tplconfig-maven-plugin -Dversion=1.0 -Dpackaging=jar -Dfile=tplconfig-maven-plugin-1.0.jar -DgeneratePom=true
Install the jar to local repository.
Thanks to Ging3r i got solution:
follow these steps:
don't use in dependency tag. Use following in dependencies tag in pom.xml file::
<dependency>
<groupId>com.netsuite.suitetalk.proxy.v2019_1</groupId>
<artifactId>suitetalk-axis-proxy-v2019_1</artifactId>
<version>1.0.0</version>
</dependency>
<dependency>
<groupId>com.netsuite.suitetalk.client.v2019_1</groupId>
<artifactId>suitetalk-client-v2019_1</artifactId>
<version>2.0.0</version>
</dependency>
<dependency>
<groupId>com.netsuite.suitetalk.client.common</groupId>
<artifactId>suitetalk-client-common</artifactId>
<version>1.0.0</version>
</dependency>
use following code in plugins tag in pom.xml file:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<version>2.5.2</version>
<executions>
<execution>
<id>suitetalk-proxy</id>
<phase>clean</phase>
<configuration>
<file>${basedir}/lib/suitetalk-axis-proxy-v2019_1-1.0.0.jar</file>
<repositoryLayout>default</repositoryLayout>
<groupId>com.netsuite.suitetalk.proxy.v2019_1</groupId>
<artifactId>suitetalk-axis-proxy-v2019_1</artifactId>
<version>1.0.0</version>
<packaging>jar</packaging>
<generatePom>true</generatePom>
</configuration>
<goals>
<goal>install-file</goal>
</goals>
</execution>
<execution>
<id>suitetalk-client</id>
<phase>clean</phase>
<configuration>
<file>${basedir}/lib/suitetalk-client-v2019_1-2.0.0.jar</file>
<repositoryLayout>default</repositoryLayout>
<groupId>com.netsuite.suitetalk.client.v2019_1</groupId>
<artifactId>suitetalk-client-v2019_1</artifactId>
<version>2.0.0</version>
<packaging>jar</packaging>
<generatePom>true</generatePom>
</configuration>
<goals>
<goal>install-file</goal>
</goals>
</execution>
<execution>
<id>suitetalk-client-common</id>
<phase>clean</phase>
<configuration>
<file>${basedir}/lib/suitetalk-client-common-1.0.0.jar</file>
<repositoryLayout>default</repositoryLayout>
<groupId>com.netsuite.suitetalk.client.common</groupId>
<artifactId>suitetalk-client-common</artifactId>
<version>1.0.0</version>
<packaging>jar</packaging>
<generatePom>true</generatePom>
</configuration>
<goals>
<goal>install-file</goal>
</goals>
</execution>
</executions>
</plugin>
I am including 3 jars from lib folder:
Finally, use mvn clean and then mvn install or 'mvn clean install' and just run jar file from target folder or the path where install(see mvn install log):
java -jar abc.jar
note: Remember one thing if you are working at jenkins then first use mvn clean and then mvn clean install command work for you because with previous code mvn clean install command store cache for dependency.
Following this thread I was able to configure the install plugin to load my custom jar, but the plugin was not seeing my configuration when running a mvn install
I'm using the base maven-install-plugin:2.5.2 using the maven:3.6.3-jdk-8 docker image.
I don't fully understand this note in the documentation (at the end of the section), but it seems that you can give the phase goal an execution id forcing it to use your configuration:
Note: Configurations inside the element used to differ from those that are outside in that they could not be used from a direct command line invocation because they were only applied when the lifecycle phase they were bound to was invoked. So you had to move a configuration section outside of the executions section to apply it globally to all invocations of the plugin. Since Maven 3.3.1 this is not the case anymore as you can specify on the command line the execution id for direct plugin goal invocation. Hence if you want to run the above plugin and it's specific execution1's configuration from the command-line, you can execute:
mvn myqyeryplugin:queryMojo#execution1
My final working docker command:
docker run -it --rm --name parser -v "$(shell pwd)":/usr/src/parser -w /usr/src/parser maven:3.6.3-jdk-8 mvn -X install:install-file#install-my-jar-file
Where install-my-jar-file is my executions id <execution><id>install-my-jar-file</id>...
I couldn't find any clear answer about how to deploy simple Maven based project to remote GlassFish server via maven like
mvn package xxx:deploy
I think only cargo plugin supports GlassFish 3. Right?
I've problems at configuration side.
Any sample remote GlassFish deployment will be great. Cargo is not a must, if others are support remote GlassFish then we can also use it too.
In case you want to only use maven-glassfish-plugin (let say version 2.1), you can do a remote deploy by specifying the "host" parameter. Below is an example where configurations are setup in maven settings.xml and an plugin loads them using a profile:
In settings.xml define a profile:
<profile>
<id>production-config</id>
<properties>
<glassfish.glassfishDirectory>/var/local/glassfish/</glassfish.glassfishDirectory>
<glassfish.user>admin</glassfish.user>
<glassfish.adminPassword>adminadmin</glassfish.adminPassword>
<glassfish.domain.name>prd-domain</glassfish.domain.name>
<glassfish.domain.host>NAMEOFYOURREMOTEHOST</glassfish.domain.host>
<glassfish.domain.adminPort>10161</glassfish.domain.adminPort>
.
.
</properties>
</profile>
Next put this profile in your active profiles:
<activeProfiles>
<activeProfile>production-config</activeProfile>
</activeProfiles>
In your maven project pom.xml, create a profile and add the maven-glassfish-plugin in your list of profiles:
<profile>
<id>production</id>
<activation>
<activeByDefault>false</activeByDefault>
<os>
<arch>x86</arch>
<family>linux</family>
</os>
<property>
<name>profile</name>
<value>production</value>
</property>
<file>
<exists>
${glassfish.glassfishDirectory}/domains/${glassfish.domain.name}/config/domain.passwords
</exists>
</file>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.glassfish.maven.plugin</groupId>
<artifactId>maven-glassfish-plugin</artifactId>
<configuration>
<terse>true</terse>
<echo>true</echo>
<debug>true</debug>
<glassfishDirectory>${glassfish.glassfishDirectory}</glassfishDirectory>
<user>${glassfish.user}</user>
<adminPassword>${glassfish.adminPassword}</adminPassword>
<domain>
<name>${glassfish.domain.name}</name>
<host>${glassfish.domain.host}</host>
<adminPort>${glassfish.domain.adminPort}</adminPort>
</domain>
<components>
<component>
<name>${project.artifactId}</name>
<artifact>${project.build.directory}/${project.build.finalName}.war</artifact>
</component>
</components>
</configuration>
<executions>
<execution>
<goals>
<goal>deploy</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
This should do the trick. You can run this profile using maven : mvn glassfish:deploy -P production or just mvn deploy -P production (since we have added the goal deploy inside the executions part of plugin)
Using the model above you can create different profile per environment (dev, acc, tst, prd), and use different settings. For instance you can create a developer profile where a local glassfish is being used to deploy and run unit/integration tests on it.
Common mistake people make is to mix up the settings for the machine from where you are doing the remote deployment with the host where deployment is to be installed. glassfishDirectory is place from where you are running the deployment plugin from. As a result of mistake plugin just hangs, doing nothing and just waiting giving the impression that something is happening. Another mistake is to specify a password file instead of a password for a remote deploy which will also result in nothing.
As far as I know and could find around, only Cargo delivers (or deploys, in this case).
This is an example tested as working on a Maven OSGi WAR project:
<build>
<plugins>
...
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.1.2</version>
<configuration>
<container>
<containerId>glassfish3x</containerId>
<type>remote</type>
</container>
<configuration>
<type>runtime</type>
<properties>
<cargo.hostname>myhostname</cargo.hostname>
<cargo.remote.username>myusername</cargo.remote.username>
<cargo.remote.password>mypassword</cargo.remote.password>
</properties>
</configuration>
</configuration>
<dependencies>
<dependency>
<groupId>org.glassfish.deployment</groupId>
<artifactId>deployment-client</artifactId>
<version>3.2-b06</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
As you can see, the trick lies in the deployment-client dependency.
For the sake of completeness, you then just mvn package cargo:deploy and Bob's your uncle.