Cooking composer

Well, no doubts that Documentum Composer is an evil, and even vendor fails to maintain it, nevertheless it is a kind of evil we need to deal with – I do know how to create a lot of Documentum artefacts using API and DQL only, but I have no idea how to install process templates, moreover, somewhen in 2009 there was a hope, that EMC would create a robust technique to transfer process templates between repositories, but that was just a hope – current support of XPDL does not allow to transfer workflow templates between Documentum repositories :(, so, I decided to share my composer-related experience.

First of all, lets define objectives we pursue when dealing with composer, in my opinion there are following goals:

  • we must store all composer-related stuff in version control system
  • the build process must be fully automated, be a part of SDLC and support CI/CD practices
  • the deployment phase should not take a lot of time

Storing composer project in VCS

The first steps you need to perform after creating composer project are (actually, this was not obvious to me 6 years ago, because I was not experienced eclipse user):

  • export project to the filesystem folder backed by VCS
  • remove project from workspace
  • import project into workspace

Automating build process and shortening deployment phase

This parts are already challenging. When EMC developed composer (actually it is just Eclipse plugin), they did really think that developers would use it as IDE (how wrong they were), and because of that Documentum composer lacks some vital functionality. If you are not familiar with evolution of build automation tools, below is gist:

  • in 1976 Stuart Feldman created make, before him developers used shell-scripts to build their software
  • in 2000 James Duncan Davidson released first public version of Apache Ant
  • in 2002 Takari’s Jason van Zyl created Apache Maven
  • and in 2007 Hans Dockter and Adam Murdoch released a first version of gradle

Actually, gradle is my personal choice, but I also do not experience any difficulties with both maven and ant, however, talented team still thinks that shell-scripts is a good option:

(Un)fortunately it is not an option for me, so, I wrote a simple eclipse plugin, which allows somehow automate composer tasks, for example, you may write following ant build file:

<?xml version="1.0"?>

<project name="myproject" default="all">

    <macrodef name="copy.project">
        <attribute name="project" />
            <pro.importProject project="@{project}" 
                               copy="true" replace="true" 

    <macrodef name="import.project">
        <attribute name="project" />
            <pro.importProject project="@{project}" 

    <macrodef name="copy.dar">
        <attribute name="project" />
            <mkdir dir="${output.dir}" />
            <pro.copyDar project="@{project}" todir="${output.dir}" />

    <target name="create-workspace" description="Create local composer workspace">
        <import.project project="MyDocumentumProject" />

    <target name="create-build-workspace" description="Create build composer workspace">
        <copy.project project="MyDocumentumProject" />

    <target name="importcontent" description="Import content">
        <pro.importContents file="${basedir}/importcontents.txt" />

    <target name="build-workspace" description="build eclipse project">
        <eclipse.incrementalBuild kind="full" />

    <target name="clean-workspace" description="clean eclipse project">
        <eclipse.incrementalBuild kind="clean" />

    <target name="copy">
        <copy.dar project="MyDocumentumProject" />

    <target name="setoptions" description="Set upgrade options">
        <pro.setUpgradeOptions file="${basedir}/upgradeoptions.txt" />

    <target name="all" depends="create-build-workspace, importcontent, setoptions, build-workspace, copy" />


and call ant from either ant or maven (via exec-maven-plugin), or gradle (via JavaExec or ComposerExec).

5 thoughts on “Cooking composer

  1. What’s the goal of exporting and importing the project?

    To get new challenge: combine all projects together and build them 🙂

    If talking seriously, I do believe that if something is suitable for large project is it also suitable for small project, and the converse is not true – it is exactly what we mean under “best practices” term. From large project perspective flat structure (it is exactly what composer creates by default) always sucks because it is not flexible – imagine that I developed a lot of semi- or independent Documentum modules and now I want to create a solution for specific customer, how can I achieve that using flat composer structure? Nohow, I need to store this modules separately (and, obviously, together with related java code), after that I will able to combine these modules together.

    Liked by 1 person

  2. Have they fixed the issue yet when you import a Documentum Project from SVN, it creates the project under TCMReferenceProject instead of its actual project name? The workaround is to create a test Documentum Project, remove it and then import it again from the SVN.


  3. It was working in Eclipse with Compser plugins 6.5 and it broke on 6.6 and above. Even it has been reported, it is still not fixed on Composer 7.2. I will check Composer 7.3, but I don’t believe that something has changed.


Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s