Using Maven to setup a Drupal PHP project

Question

What do I want to achieve?

We are currently working on a PHP project that uses Drupal.

I desperately want to learn how to create a One-step build for the whole project. Preferably by using something new (for me) that seems very powerful: Maven

Basically I want to automate the following process:

1. Checkout Drupal from the official CVS repository.
2. Checkout official 3rd party modules from their respective CVS repositories.
3. Checkout our custom modules from our mercurial repository.
4. Copy/move all the modules to the appropriate directory within Drupal.
5. Checkout and install our custom theme.
6. Add a custom drupal installation profile.
7. Create a new MySQL database schema.
8. If possible, automate the drupal db connection setup.

In the future I would like to run this build on a Hudson (or any other) continues integration server.

Why Maven? (why not Ant or Phing?)

Other than the desire to learn something new (I have used Ant before) I think the dependency management of Maven might work well for the drupal modules.

Do you think this is enough reason to use Maven, even though Maven was not originally intended for PHP projects? I know Ant was not originally used for PHP either, but there are far more examples of people using Ant and PHP together.

BTW I think I will switch to Ant if I can't get Maven to work soon. The procedural style of Ant is just easier for me to understand.

What do I have so far?

I have a pom.xml file, that uses the SCM plugin, to checkout the drupal source. When I run:

mvn scm:checkout

the source is checked out into a new directory:

target/checkout

When I try:

mvn scm:bootstrap

it complains about the install goal not being defined.

Here is the pom.xml:

<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>com.example</groupId>
  <artifactId>drupal</artifactId>
  <version>1.0</version>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-scm-plugin</artifactId>
          <version>1.1</version>
          <configuration>
            <username>anonymous</username>
            <password>anonymous</password>
          </configuration>
      </plugin>
    </plugins>
  </build>
  <scm>
    <connection>scm:cvs:pserver:cvs.drupal.org:/cvs/drupal:drupal</connection>
    <developerConnection>scm:cvs:pserver:cvs.drupal.org:/cvs/drupal:drupal</developerConnection>
    <tag>DRUPAL-6-12</tag>
    <url>http://cvs.drupal.org/viewvc.py/drupal/drupal/?pathrev=DRUPAL-6</url>
  </scm>
</project>

Finally, what are my questions?

• Is Maven the wrong tool for this?

If no,

• How would you do this?
• Is it the scm:bootstrap goal that I should be using?
• What is the Maven way of moving directories around on the file system?
• Should the install goal be used to move the modules into the drupal directory?
• Currently all our custom modules are in one mercurial repository. Is it possible to create a pom.xml and checkout each module individually?
• Any general advice would be appreciated.

Thanks for your time!

Answer 1

I'm 98% certain that what you really need is Drush Make, which can recursively build Drupal projects, provided they provide their own .make file listing their dependencies. It can download from multiple SCMs, web, patch files, and you can control where they get downloaded. It also support external libs, such as wysiwyg, PHP files, or JS libraries.

See the Open Atrium make file for a sample of what it can do.

Answer 2

Definitely you're not using Maven, here some thoughts:

• Maven is a Java build tool and dependency management software with a well-defined lifecycle which goes like this: validate, compile, test, package, integration-test, verify, install, deploy. What you are using is the scm plugin which can stick to any of the phases defined here and perform some actions but unless you make complicated changes in the POM (I haven't heard of anyone doing this) the lifecycle will continue being executed.
• Maven also is designed to package JARs, WARs and with the use of some plugins EARs, SARs, RARs (not that RARs) and some other files; you might have to program a new plugin to get the type of packages you expect or use the assembly plugin which will make things more complicated.

Because of the previous points, there is no command for Maven to move the files into an specific directory (not a native one) and you shouldn't invoke install phase to copy the files to any other location than the local repository. What you're doing is like taking a laundry machine and converting it into a blender.

After reading what you want to do with your project I'd suggest you to create a script (shell script or batch script depending on your OS) for doing the job. SVN and CVS has command line tools which can be invoked from inside your build scripts. I guess you opted for Maven, among other reasons, because Hudson and many other Continuous Integration software are well integrated with it but you can use them with scripts too.

If you are comfortable using Ant and you consider using it will ease the building time of your app I think is not as bad ;) (I haven't used Ant for other purposes than Java projects)

Answer 3

The Drush 'module' is a great tool for scripting out things in Drupal. But, beyond that, I think your approach of doing CVS checkouts for each 'build' is a little off base - unless you have -really- good reasons to have every chunk of the project in a separate repository, your best bet is to have fixed checkouts of Drupal core & contributed modules committed to your project's repository. Not only does this take out a dependency on a network connection and the stability of an external server but it allows you to have local modifications of the contributed modules (unfortunately, you're probably going to end up doing this somewhere down the line).

Once you take out the requirement to do checkouts from multiple repositories, you'll probably notice that your task becomes -much- easier, leaving you with some simple MySQL manipulation and writing out a settings.php.