GlassFish 3 + Maven + remote deploy

Question

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.

Wulf

Answer 1

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.

Intrude

Note: This require Glassfish to be installed outside of your Maven build. – Peanut

Ok, as far as I can make out this requires you to have asadmin accessible under the directory specified by 'glassfishDirectory'. Which in effect does not help at all, since the question is about deploying to a remove server instance. The ONLY way I have been able to get this is working with ant (or other) scripts that copy the artifact to the remote server, and then via SSH execute asadmin there. And that is a major pain in the arse. – Madden

Answer 2

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.

Liquid

Why 3.2-b06 for your deployment-client version? – Tranquilizer

@Tranquilizer Not a particular reason: it worked at the time. Honestly, I haven't checked a more recent configuration – Liquid