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" />
        <sequential>
            <pro.importProject project="@{project}" 
                               location="${composer.project.dir}" 
                               copy="true" replace="true" 
            />
        </sequential>
    </macrodef>

    <macrodef name="import.project">
        <attribute name="project" />
        <sequential>
            <pro.importProject project="@{project}" 
                               location="${composer.project.dir}" 
                               copy="false" 
            />
        </sequential>
    </macrodef>

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

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

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

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

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

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

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

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

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

</project>

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

Are changes coming?

Pro Documentum

On last week something weird had happened – a couple of researches disclosed information about vulnerabilities in Documentum xPression and Documentum WDK applications:

and these disclosures are qualitatively different from what EMC was publishing previosely – these disclosures had been coordinated. Let’s explain this point. When Documentum was under EMC wing EMC was never published correct/true information about security flaws: they were always underestimating security impact and were never noticing that exploit/PoC were available in the wild, and such behaviour, obviously, had negative impact on customers: customers see that vulnerability impact is medium and prefer do not install security fixes – that is a kind of…

View original post 651 more words