Copying resources to JBoss with Maven

In my project, we use Maven to compile, build, package and deploy our application to JBoss 4.3. Every works fine. But each time a new developer comes along, or when we need to install a new server, we always have to remember to deploy the datasource and copy the MySQL JDBC Driver to JBoss. Nothing too complicated, but we tend to forget it. The file myproject-ds.xml defining the datasource needs to be copied to JBOSS_HOME/server/default/deploy and the mysql-connector-java-5.1.6.jar file needs to be copied to JBOSS_HOME/server/default/lib. To do that, we had an Ant script but people didn’t like the idea of using both Maven and Ant. So, why not using Maven profiles and the maven-resources-plugin to copy these two files to JBoss.

The idea is to use an Init profile to initialize JBoss (by typing mvn -PInit install). This will copy the files only once to JBoss. Then, the maven-resources-plugin can be used to copy the myproject-ds.xml (which is under the src\main\resources directory) and the MySQL driver (located in the local repository).

So, with a bit of Maven knowledge, a little help from my friend Arnaud and a lot of trying, here is what I came with :

pom.xml

</project>
 ...
 <profiles>
  <profile>
   <id>Init</id>
    <build>
     <plugins>
      <plugin>
       <groupId>org.apache.maven.plugins</groupId>
       <artifactId>maven-resources-plugin</artifactId>
       <version>2.3</version>
       <executions>

        <execution>
          <id>copy-datasource</id>
          <phase>install</phase>
          <goals>
            <goal>copy-resources</goal>
          </goals>
          <configuration>
            <outputDirectory>${env.JBOSS_HOME}/server/default/deploy</outputDirectory>
            <resources>
              <resource>
                <directory>src/main/resources</directory>
                <includes>
                  <include>myproject-ds.xml</include>
                </includes>
              </resource>
            </resources>
          </configuration>
        </execution>

        <execution>
          <id>copy-mysql-driver</id>
          <phase>install</phase>
          <goals>
            <goal>copy-resources</goal>
          </goals>
          <configuration>
            <outputDirectory>${env.JBOSS_HOME}/server/default/lib</outputDirectory>
            <resources>
              <resource>
                <directory>${settings.localRepository}/mysql/mysql-connector-java/5.1.6</directory>
                <includes>
                  <include>mysql-connector-java-5.1.6.jar</include>
                </includes>
              </resource>
            </resources>
          </configuration>
        </execution>

       </executions>
      </plugin>
     </plugins>
    </build>
   </profile>
  </profiles>
</project>

Make sure you have the JBOSS_HOME variable set as this script uses env.JBOSS_HOME. The ${settings.localRepository} points to your local Maven repository.

When I look at these 52 lines of XML that copy two files in two seperate directories, I either think that I’ve missed something (I could have use antrun plugin maybe) or that we are all doomed, sick and mad to use such a tool.

About these ads
Comments
8 Responses to “Copying resources to JBoss with Maven”
  1. Il est peut-être temps de passer à Gradle ? :-)

    Jeudi soir, le papa de Gradle fait une présentation de son bébé chez Zénika. Ca pourrait valoir le déplacement ! Histoire de comparer tes 52 lignes de XML et 2 lignes de Groovy avec Gradle.

    • agoncal says:

      Je me suis déjà inscrit. J’ai hate de découvrir Gradle. C’est clair, Maven, j’en ai ras le bol.

  2. Alexis says:

    depuis le temps qu’on te dit de passer a Buildr…

  3. Je vous attends de pied ferme jeudi :)
    Gradle, c’est quand même très fort.

  4. Maven n’a pas nécessairement vocation à être utilisé comme outil de déploiement. A chaque outil, son cas d’utilisation. Maven est avant tout un builder. Dans ce cas, il serait plus judicieux d’initialiser son serveur d’application une seul fois et de laisser Maven réaliser son travail de compilation, de packaging, et éventuellement de déploiement (mais juste la copie de l’archive Web, pas plus).

    Ensuite, il ne faut pas chercher à utiliser Maven pour toutes les étapes de son système de build. Ce cas d’utilisation est un très bon exemple de la mauvaise utilisation de Maven, et conduit de nombreuses personnes à le détester. Utiliser Maven, c’est connaître ses avantages mais aussi ses inconvénients, et surtout ses principes. L’emploie à la fois des systèmes de build Maven et Ant, est souvent justifié.

    Dans ce cas, l’utilisation de Gradle peut effectivement paraître plus souple en apportant l’utilisation des conventions de Maven avec plus particulièrement un cycle de vie de build (compilation, packaging,…) et la souplesse du langage Groovy avec l’éventuel utilisation de l’objet AntBuilder pour invoquer la tache Ant copy réalisant le travail de copie du driver JDBC et de la datasource.

  5. Shane Lee says:

    This maven profile does not include the library but allows you to deploy your project archive with ds.xml to jboss.

    hardeploy

    ${project.artifactId}

    org.codehaus.mojo
    jboss-maven-plugin
    1.4.1

    ${jboss.home}
    ${jboss.domain}

    src/main/resources-jbossas/default-ds.xml ${project.build.directory}/${project.build.finalName}.ear

    redeploy
    pre-integration-test

    hard-deploy

  6. Sanya says:

    “are all doomed, sick and mad to use such a tool”

    can’t agree more…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 7,653 other followers

%d bloggers like this: