As posted previously we’ve been using Composer quite a lot on our current project and have set up a development environment which the dev team should be proud of. There is no doubt in my mind that Composer is a big step forward in the Documentum development process. Being able to work on artifacts which are stored on a filesystem and then having this controlled through a code management tool such as Subversion is a big benefit.
Our environment
The approach to development has been to give the developers access to an image of the Documentum server side components, namely the Content Server and Web Application we’re using, RMA. Each developer starts with an identical image, i.e. the products are all the same and they work locally against the image in their own space. When they’re happy with their work it gets checked in to Subversion and then deployed to the central development server.
Point 1: We have not achieved my ultimate goal of continuous build and automated deployment into the central development server. This would help us enormously; as we are working to some of the Agile principles this may be something we bite the bullet on as the Technical Debt we face may prove expensive in the long run. This is not due to any technical problems, just time as we have been focussing on some user demonstrations and addressing some of the technical components of the solution.
Point 2: We have not achieved the goal of using a single product for all Documentum development. Problems with the WDK development have meant that we still use a true version of Eclipse for WDK development and Composer for some of the Documentum based configuration/development.
Point 3: We had to have the developers have their own version of tomcat running locally on the PC, not within the image. Well I say we had to but we took the decision this was the most efficient, enabling us to deploy much easier and also to run in Debug mode better.
Point 4: We have had problems with Forms, creating them in Forms Builder and then bringing them into the Composer project to deploy has caused us grief. Support has been raised on this one but our workaround has been to revert to using DAB as the vehicle for moving Forms from one repository to another.
Point 5: Forms, and Process Builder, again. Okay it would be too much for the early release but it would be really good if we can start to see Process Builder and Forms Builder being integrated into Composer. If I’m developing an application which is based on a process and uses a form which requires some validation, or another level of adaptor, then I’ve got 3 products up and running. Plus the Form and the Process are still being built in the repository. Not a complaint but more of something to add to the wish list!
Overall the product gets a big thumbs up though, huge step in the right direction from EMC and when the next release comes out with Forms and Process plug-ins which can be licensed separately then I’ll raise a glass.
Observing Content Management 