Before Composer, there was no IDE for building WDK based application on top of Documentum. In 5.3, we had Documentum Application Builder (DAB), which supported the development and configuration of server side objects like lifecycles, workflows, object types, etc. When Business Object Framework (BOF) came out in 6.0, DAB was extened to support creation of modules which served as “container” for custom BOF code. However, you still had to have a java environment to build JAR files that contained BOF code. In addition, any customizations to WDK/Webtop was not supported in DAB. The WAR build and deployment process was entirely separate from docapp installation process.
Then came the promise of true IDE that would support both server side development and web app development -> Documentum Composer, which was built as Eclipse plugin. From architectural perspective, building Composer on popular open source Java IDE made sense. Promises dont always turn to reality though. I think EMC underestimated the effort it would take to rewrite DAB as Composer, while providing additional capabilities that Documentum developers never had. To this day, there are still a lot of options that you cant do in Composer, that is available in DAB out of the box. I question whether there will ever be feature parity.
Lets talk about tomorrow and some of other problems that Composer faces today. Composer’s design goal of being IDE for server side and web app development worked fine when building WDK based apps (and even custom web apps). However, given that the evolution of application development is moving towards xCP and configuring (vs coding), the java centric IDE is no longer the ideal IDE. For those of you who are not familiar with xCP, its a suite of products – namely TaskSpace, Forms Builder, Process Builder, and Business Activity Monitor (BAM). These four products have their own UI for building TaskSpace app, forms, workflows, and reports respectively. These UI were designed to allow systems analyst (not java coders) to configure and develop task centric applications.
This is great except that these non-coders have to use Composer to package all the custom forms, workflows, and other relevant custom objects in DAR file in order to move the application components from environment to another. From a java developer’s perspective, creating a DAR file is straight forward process – you import the relevant artifacts and then build the DAR file. The issue is that Composer is a “beast” compared to the other xCP tools. The flexibility of Eclipse makes it more complex to train someone who is not a coder. Ideally, the need for Composer to create DAR file for TaskSpace application would go away.
I know that xCP 2.0 is going to address this. My biggest concern is how long its going to take to build a truly INTEGRATED development environment for TaskSpace application. When demonstrating the various components of xCP, I have customers saying:
“The toolset looks great, but why do I have to launch 5 separate applications to create single app. Oracle does this from a single UI.”
I explained to them the evolution of the products and the xCP roadmap, but the question that I cant answer is – when will there be a true IDE?