Artifact Concerns
As most of you will be aware every Documentum Composer workspace with at least one Documentum Project in it also has an additional project called the Documentum Core Project. In this blog post I wanted to investigate this special project a bit.
The core project is created when you create your first regular project. When using the Documentum Artifacts perspective it is hidden from the navigator view so you dont normally see it.
But if you switch to the java perspective or something similar you will be able to.
It is a read-only project and also unlike regular projects it does not have an artifact builder. So whilst it contains a set of artifacts. They are never built and the core project can never installed. So what is its purpose?
As you will undoubtedly be well aware when you install a new Repository it is not completely empty. It contains a set of objects; type definitions, a folder structure, some document templates, some default access controls, some formats, etc. The core project then acts as a reference project for this set of artifacts. Every Documentum Project that you create references this core project.
This in turn allows you to reference any artifact in that core project. So, for example, you could create a new type definition whose supertype is the core project’s dm_sysobject. Moreover when the dar installer installs your project and therefore your type artifact into the Repository as a docbase object, it will resolve the type’s supertype DM_ID reference to the r_object_id of the dm_sysobject type in that Repository.
A type’s supertype is just one example. Every Documentum object model exhibits these object references and therefore each instance of an object model forms a complex graph of objects knitted together by these references. And the core project helps Developers to build on top of and extend these core object models which together make up Documentum platform.
This referential project model is also an indication of several other important concepts.
- We expect Developers to create many, small, cross referencing projects as opposed to a single large, monolithic, all encompassing project.
- We expect an artifact to exist in one project only. And we expect it to be referenced when required. This is in contradiction to DAB’s drag it in model.
- Projects, and in fact references to projects, should be versioned.
Of course in some ways Composer support the referential project model very well. Install suffers from a general lack of error checking around pre-requisite projects. It shouldn’t, for example, be possible to install project B without a compatible version of project A being installed already. We also don’t support project versioning very well. This support was planned for v1 but it unfortunately fell off of the list due to time and resource constraints. My hope is and expectation is that we will be addressing this soon.
Composer also doesn’t support a full development lifecycle either. In the majority of cases I would argue that it is not particularly desirable for us, or for our partners, to have to distribute source projects (for one thing it contravenes rule 2 above) just to enable Developers to extend ours and our partners offering. But this is exactly what has to happen today. For this reason I have always wanted projects to reference binary dars as well as or, in fact, instead of projects. This would allow us and our partners to distribute Dar which makes much more sense. To this end a few months ago I completed an elaboration/proof of concept demonstrating this capability so my hope is again that this will also be added soon.
DFS
Another aspect to the core project is DFS Development. At the moment a DocumentumProject is overloaded. It is both an artifact project, supporting artifact development, and it is also a DFS project, supporting consumer and service DFS development.
This DFS development occurs against the DFS SDK which is not, unfortunately, a freely available, standalone distributable, like the JDK for example. So we ship it with Composer inside one of our plug-ins. Therefore to support the development of a DFS consumer or a service we have to deploy the SDK from the plug-in to a known location. We chose to deploy the SDK to the core project as this was a location we know will always exist.
Over time we should see this design move towards the design most all IDEs employ to manage the JDK, where each project may be associated with one of potentially many external SDK installations registered with the IDE itself. This will decouple Composer from a particular version of the SDK and allow for managed separate upgrades of Composer and the DFS SDK giving developers more freedom to upgrade Composer but stay developing against their current DFS SDK or vice versa. The majority of the code is in place for this in the dfs plug-ins. We just need to enhance the UI to support registering DFS SDKs and associating them with (DFS) projects. Oh and we need to promote the DFS SDK itself as a freely available and downloadable distributable, on EDN 🙂
Conclusion
In this article we’ve taken a look at the Documentum Core Project, a part of Composer we have not looked at before but of some significance. We have discussed some of its implications and touched upon some of the (hopefully) not too distant enhancements.
As always, questions gratefully received.
Happy Composing!
Paul Warren 