At work we are trying to get our drupal php code into a workflow that’s more familiar to the java community. Build -> Upload artifact -> Deploying by downloading the corresponding artifact.

Our Drupal Deployment Workflow

Let me explain a little regarding our deployment workflow. The goal here is not having to check in resources generated by grunt or dependencies pulled down by bower into the code base. We want to generate these resources in a build step to be eventually used on the web servers. Maven is DEFINITELY NOT the technology of choice. It’s a technology of convenience. Because it’s already being used by the java projects at work for similar purposes and it’s available. That’s why we went with maven. And there isn’t a whole lot of technologies ready to be used with php deployment in that regard. Maybe docker will help?

Here’s a diagram that explains the whole process.

We’ve been using maven to jar up our zipped php files. This has been working well for a single site. Recently we are creating a new site. The way drupal works it seems to make more sense to keep the code in the same git repository because the site is so similar and it will share a lot of code with the existing site. However we want independent build process for each site so they do not affect each other when comes to the deployment workflow.

In order to keep using maven for this job, I had to make two changes. Move the pom.xml from the root to a site specific directory and then trigger maven deploy as well as release:prepare and release:perform against the new poms.

Using a pom file that does not reside in its traditional location is a challenge. The two maven plugins we use for jarring up & uploading are the maven-release-plugin and the maven-scm-provider-gitexe. The current site has been using

<plugin>
    <artifactId>maven-release-plugin</artifactId>
    <version>2.4.2</version>
    <configuration>
        <arguments>${release.arguments}</arguments>
    </configuration>
    <dependencies>
        <dependency>
            <groupId>org.apache.maven.scm</groupId>
            <artifactId>maven-scm-provider-gitexe</artifactId>
            <version>1.8.1</version>
        </dependency>
    </dependencies>
</plugin>

configuration without issue.

After I created two pom files each at their respective locations, the maven deploy is being triggered without issue. However when it comes to release, it’s a complete different story.

In order for release:prepare to update and commit changes on the correct pom file, I first used the pomFileName parameter as suggested here.
via

<plugin>
    <artifactId>maven-release-plugin</artifactId>
    <version>2.4.2</version>
    <configuration>
        <arguments>${release.arguments}</arguments>
        <pomFileName>path/to/pom.xml</pomFileName>
    </configuration>
    <dependencies>
        <dependency>
            <groupId>org.apache.maven.scm</groupId>
            <artifactId>maven-scm-provider-gitexe</artifactId>
            <version>1.8.1</version>
        </dependency>
    </dependencies>
</plugin>

From testing, release:prepare is not correctly committing the change to the correct pom file and release:perform is not looking for the correct pom file for running its deploy target. Using the pomFileName parameter seems like a complete failure.

The next thing I tried is using the -f parameter in the command. Our job is being run by the Jenkins framework. I updated the Goals and options for maven to

-e clean -Dresume=false -f=path/to/pom.xml release:prepare release:perform

This change made release:perform honor the correct pom file. However it did not fix the issue where release:prepare is not committing change to the pom file. The issue I’m running into is basically the same issue as in this thread.

The number one suggested solution is what I already have: the combination of release plugin v2.4.2 and scm plugin v1.8.1 and that obviously does not work for me. Since I do not have direct control over maven and git versions on our Jenkins server, messing with the plugin version seems to be the route I should take.

After many trial-and-error, ultimately the following worked for me

<plugin>
    <artifactId>maven-release-plugin</artifactId>
    <version>2.5.1</version>
    <configuration>
        <arguments>${release.arguments}</arguments>
    </configuration>
</plugin>

Use the 2.5.1 version of release plugin and let it pull its own dependency of the scm plugin.

Conclusion

To get maven release working with two separate non root pom.xml files. You will need to use maven release plugin v2.5.1 (or higher I assume) and let it pull its own scm plugin dependency. And run

-e clean -Dresume=false -f=path/to/pom.xml release:prepare release:perform

as your maven release command.