Docapps, composer and some Taskspace apps...

Hello everyone,

I have to admit I was a bit reluctant about using Composer. I gave it a try a while ago and I found it full of annoying bugs and random crashes. But that was back in 6.0, so I decided to give it another chance, now that it has reached version 6.5 (sp2).

The story goes like this: we've created custom object types, methods, jobs, roles, groups etc. in the old fashioned way, using scripts for object types, DA for methods and jobs, in two words - NO IDE (either Composer or DAB). Along with that we also created a Taskspace application, this being a Taskspace project and all. At some point in time (about a two weeks ago) we decided to go back to the righteous ways and use Composer to do the work.After browsing the user guide I took the following steps into building our application:

1. Created a new Composer Documentum project

2. Imported the custom object types into the project

3. Imported the new methods into the project

4. Imported the Taskspace application

5. Imported some other artifacts like Forms (yes, we have those, too), Process Templates, Roles, Groups...

The result was quite funny - the Taskspace application imported its dependencies, meaning the object types, the forms and roles. The reasonable behaviour would have been to overwrite the object types definitions that I already imported in the project but noo... It just created a NEW object types definitions and appended a [1] to the name. After importing the process templates I realized it also duplicated the name of some roles I used in the process templates.

I tried to install the project on a fresh docbase (with all the necessary DARs like forms, taskspace etc.) installed and it raised an error saying that

Unexpected error occured during install org.eclipse.core.runtime.AssertionFailedException: assertion failed: precondition dfTypeObject must be null before creating a new type object (type name = 'bcr_dms_document')

and I suspect this is because the duplicate definitions in the project.

Simply deleting the [1] definitions proved to be quite wrong because other artifacts have references to them.

So... what can I do to deploy this in a customer's environment ?!

Find more posts tagged with

Comments

Francois Dauberlieu

Instead of deleting the artifacts automatically imported and duplicated, did you try to suppress the ones you imported before hand? Note that the [1] is most likely only added for display reason but the real name, in your case the object type is still good.

Also, you could try to create a new project, import your Taskspace app 1st and then inport whatever wasn't imported and still missing

dplaton

I know the type names are not altered, that's why the project fails to install.

Thanks for your suggestion, I will try to do this now.

foroor

The current plan is to introduce the ability to "overwrite matching objects" when importing artifacts from the Repository.

dplaton

I finally succeeded to install the DAR. The plan I followed was something like this:

1. Imported the TaskSpace app

2. Imported the process templates. Something very annoying happens here: if I have roles that are present in two or more process templates and I import them one by one the Composer imports the roles every time (of course, appending the [1].. or [2]). If I import all the process templates at once the roles are not duplicated

3. Imported method, jobs, modules, libraries and whatever I needed in random order.

The DAR installed successfully, the only thing to do now is to test the application to see that is all right.

Thanks for your help.

luke

I totally agree with the complaints expressed by dplaton.

Composer is absoluterly not mature for serious development. What is really missing is some support for "roundtrip" between Composer's local definitions and the repository.

During the development of a standard Taskspace application is (or should be) normal to cycle several times between

a) installation of artifacts defined in Composer into the repository, and

b) import of object (new or modified) back from the repository into Composer project

Working this way is not an option for the Documentum developer: some objects (like forms or processes) can only be defined in the repository, while others (like Lifecycle or Template ACL) can only be defined through Composer.

Currently Composer do not support this concept of roundtrip for two main problems:

1) as described by the opening post (by dplaton), when you import back object from the repository, they will duplicate what you have in your Composer project

2) when installing the composer project into the repository, nothing prevent accidental overwrite of newer objects that might be in the repository. Say that you have a form in Composer which is older than the one that is in the repository. It simply get overridden, silently!

In July Ramin said that EMC was going to addres problem #1. Are there any news from EMC about that? Can you be more precise now about when this feature will be available?

Thanks

-Luca