Regularly, the Jumpstart team members are invited to assist customers who either decided to adopt Rational Team Concert (RTC) and need to adapt their Maven build and deployment process to RTC or, as an “open source shop” wants to challenge RTC on this subject.
So, I would like to share with you some recommendations which helped our customers in dealing with Maven when it meets RTC…
Maven-RTC integration: first impression
|Generally, the customer first impression, when we show the Maven/RTC integration, is pretty good.
Actually, RTC-Maven integration is straight forward (cf: Jazz-Wiki: A Jazz-based Maven build); once the user has chosen to create a Build Definition using the Maven Build template, he needs to specify:
Unfortunately, this is not always so easy… Each customer I have met has had some particularities that I would like to share in his post.
Don’t tell to my Eclipse buddies: I truly believe that the main integration issue we have to face when we import a Maven project into RTC has to do with some Eclipse constraints/limitations; the issues with RTC happen latter, once this one is fixed…
Actually, most of my Maven customers are using Multimodule Projects. This aggregation of projects is generally defined as a hierarchy of folders and sub-folders. So when you have to import such structure into an Eclipse client, because Eclipse doesn’t support the notion of project/sub-projects, you have to create dedicated Eclipse projects to flatten the hierarchy using, for example, the Eclipse notion of linked projects. The Q4e Maven client is using this technique to import Maven projects into Eclipse.
I didn’t have the opportunity to investigate M2Eclipse which seems to be the way the Maven+Eclipse community (and Sonatype) are going. It might worse to study their own approach on importing Maven projects.
Unfortunately, this way of dealing with a Maven Multimodule project has several inconveniences. The main one is on the fact that you have to check-in the whole project: root project and sub-modules. You cannot split the project into smaller pieces and, for example, use the Jazz SCM Component artifacts to manage and version your Maven when it would be so useful.
The recommendation we provide on such situations is to flatten the Maven structure. This transformation requires small changes in the pom.xml files and it really simplifies the end-user life when he has to import and manage such structure in RTC.
Pulling or Pushing, this is a question
The RTC Build Component promotes the Source Code Pushing model. By “Pushing model” I mean that the Build Engine pushes the code to Build Machine before running the build script. With Maven, because you can include some dedicated goals to Pull the Source Code(Maven SCM API), it is required that the build script pulls the code into the Build Machine.
I will not argue which model is better (Pushing or Pulling); it could be a very interesting subject for another post. I will just recommend to use the first one -Pushing model- with RTC because it is perfectly integrated to RTC and the build master gets for free lots of interesting behaviors, that a Pulling model will have to handle by itself, like: Snapshot creation, list of delivered change sets, list of delivered Work Items, …
Actually, the easy part of this issue is to remove from the pom.xml files the code calling the Maven SCM APIs.
Sometimes, the complex part is to convince the customer that the Pushing model is another good way of building. Actually, once you have shown him how easy it is to use Personal Builds on such context, then the customer understands, appreciates and starts to be addicted to this model…
The Jazz project is presently developing the Maven SCM plugin for Jazz SCM to support faster migration. You can follow up this enhancement here: Maven SCM plug-in extension for RTC (Enhancement 90042). An initial implementation of a Maven SCM plugin for Jazz SCM is available in RTC 3.0 M7a (which also works with RTC 2.x). Information on using this plugin is available in the UsingMavenScmPlugin topic.
Build Toolkits API
The third point we have to solve when we want to integrate a Maven project into RTC is the insertion of the Build Toolkits API into a pom.xml file.
The Build Toolkit API are a set a ANT tasks used by a build script to communicate with the Jazz Team Server: publishing build results and contributions, enabling progress monitoring, working with Jazz source control and controlling the build life cycle.
If you want to make your build script “Jazz aware” you will need to (1) import the maven-antrun-plugin used to call ANT scripts from a Maven script and (2) insert Build Toolkit ANT calls appropriately in the pom.xml files. The following wiki page provides a good example to help you setup the Maven ANT plug-in: Invoking Jazz build toolkit Ant tasks in a Maven build.
On this section, I would like to talk about coupling a Maven repository with your Jazz team Server. A Maven repository is used to hold build artifacts and dependencies of varying types. It is a sort of Asset Manager. Most of the time my customers have built all their deployment process based on the assets stored in this repository.
The question which often shows up when a customer is using its own Maven repository: where should we store our built deliverable knowing we can also store them in the Jazz Team Server?
Usually, I recommend that customers store in the Maven repository any deliverable you want to be able to consume later on as a prerequisite of another pom.xml script. Now, in the context of continuous testing and continuous integration process you might have to reconsider this point. Actually, continuous testing and continuous integration are heavy deliverable generators. So, it might make sense to split the build in 2 phases: (1) Maven build, (2) Maven repository deployment.
In any cases, (1) it is really important to identify which deliverable should really be stored in the Maven repo and which one could be recreated each time you need to run a build and (2) don’t forget to publish in the build result the link to retrieve the deliverable you have stored into the Maven repository (Build Toolkit <artifactLinkPublisher> ANT task).
This last point concludes my post.
The following FAQ is an excellent place to retrieve all the entry points on Jazz.net covering this subject: Does Jazz Team Build support Maven?
Feel free to comment and share your own feedback on this particular subject…