Composer losing composure…

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?


4 responses to “Composer losing composure…

  1. I am sure there is a relatively simple Ant script that can be written to make a DAR if the folder structure + artifacts can be inferred.

  2. I think integration of Forms builder and BPM as Eclipse plugins is in the consideration for xCP 2.0.
    It would be great as it is frustrating to see hos disparate FB and BPM are. Change in one is not replicated in the other which causes a lot of pain.
    Hopefully they get the LWSO stuff figured out for Composer as well.

  3. Your first two commenters seem to miss the point of configuration vs. coding. Writing an ANT script is goint the opposite direction of configuration vs. coding. And if a non-coder has trouble with Eclipse for Composer, is it really the right decision to forc them to Eclipse for Forms Builder/BPM as well?

    Dctm would be foolish to make BPM and Forms Builder into Eclipse plugins after the nightmare we’ve all experienced with Composer.

  4. Contentess – the point here isn’t to have EVERYONE write their own Ant scripts but to have one available atleast in the interim so that a DAR can be packaged rapidly. An end user doesn’t have to get involved with it, just use it.

    Tools such as Ant and MAVEN automate build processes precisely so that developers and/or operations personnel don’t spend time on reinventing the wheel.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

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

Google+ photo

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

Connecting to %s