views:

3399

answers:

3

What is the most minimal example of deploying a war to multiple tomcat servers using maven that can be written?

I've tried the following URLs and asked the mailing list, but not coming up with anything that was short and would simply work.

The example should have the servers defined in the example somewhere (with sample usernames/passwords)

+2  A: 

Maybe the "most minimal" solution isn't minimal at all. If you have problems with doing that in maven itself, try using ant: create two different deploy tasks (one per server) and another task which has them as dependencies. There are several examples how to deploy to a tomcat server using ant. Just google them. Done this, you need to integrate the new ant tasks into maven which isn't difficult at all using the antrun plugin.

Markus Lux
True enough, I was hoping for an example.
altCognito
+6  A: 

The idea of Markus Lux can be also applied with a Maven2 solution, with the profiles management:

<build>
    <plugins>
        <plugin>
            <groupId>org.codehaus.cargo</groupId>
            <artifactId>cargo-maven2-plugin</artifactId>
        </plugin>
    </plugins>
    ...
</build>
<profiles>
    <profile>
        <id>env-foo1</id>
        <!-- Activated when -Denv=foo1 is given as parameter. -->
        <activation>
            <property>
                <name>env</name>
                <value>foo2</value>
            </property>
        </activation>
        <properties>
            <deploy.env>xxx</deploy.env>
            <tomcat.manager>http://foo1/manager&lt;/tomcat.manager&gt;
            <tomcat.manager.username>foo</tomcat.manager.username>
            <tomcat.manager.password>bar</tomcat.manager.password>
        </properties>
    </profile> 
    <profile>
        <id>env-foo1</id>
        <!-- Activated when -Denv=foo2 is given as parameter. -->
        <activation>
            <property>
                <name>env</name>
                <value>foo2</value>
            </property>
        </activation>
        <properties>
            <deploy.env>dev</deploy.env>
            <tomcat.manager>http://foo2/manager&lt;/tomcat.manager&gt;
            <tomcat.manager.username>foo</tomcat.manager.username>
            <tomcat.manager.password>bar</tomcat.manager.password>
        </properties>
    </profile>
    ... 
</profiles>

Then, you will just need to run X times the mvn command, with the adequate parameter (-Denv=foo1, -Denv=foo2,...)


In addition to that, you can enhance this solution by using the Matrix feature of the Hudson Continuous Integration server. I gave a short explanation about this feature here.

Basically, you just define a "normal" Maven2 job in Hudson, and with the Matrix feature, you can ask Hudson to run this job several times, one per environment. In others words, you create your Hudson job, and then you define the "environment axis" with all possible value for the env parameter:

  • foo1
  • foo2
  • foo3
  • ...

Hudson will then build the application with the mvn command and with the parameter -Denv=foo1.Once this build is finished, it will build the same application but with the parameter -Denv=foo2, and so on...

This way, Hudson will deploy your application in every environments...

I hope my solution will help you to reach your goals...

romaintaz
Holy crap, this is potentially hugely useful, as Hudson is exactly what I was targeting using this in....
altCognito
Funny thing is, this is similar to what the link I gave was suggesting, but it's not precisely clear. Can't wait to try it.
altCognito
A: 

This answer is for Jetty and for a slightly different situation, but you might find it useful anyway.

On a previous project we used Jetty, so I wrote a simple Jetty deployer module that would periodically scan the maven repository and download and deploy new artifacts as soon as they became available. This ran well on a small cluster of staging and development machines.

You can find the code at Google Code in the Polar Rose Jetty Maven Deployer project.

Note that we only did this for development and staging servers. In my opinion production apps should never ever be upgraded automatically.

St3fan