Documentum Composer: What’s in a Documentum Project and what should I check in?

Documentum Composer: What’s in a Documentum Project and what should I check in? 【copied】

I have received a few comments asking what resources are in a Documentum Project, what needs to go into version control and what doesn’t?   I think because Composer contributes some “source” artifacts to the project it is not immediately obvious what the set that needs source control actually is.  So, let’s have a look.

Create a new Documentum Project and then open the Navigator view.  For those new to eclipse the Navigator view will give you an unfiltered view of the projects in your workspace.  You should see something like this:-

Let’s start at the bottom and work up.  All the dot files hold metadata about the project; .project and .classpath are managed by eclipse itself; .dmproject, .dfsproject are managed by the Documentum Artifact project system and .dfsproject is managed by the DFS (Documentum Foundation Services) project system.  Please feel free to have a look inside these but unless you know what you are doing I wouldn’t necessarily modifying them.  They are system managed and modification (of the Documentum ones at least) by hand isn’t a supported operation.

Artifacts is artifact source folder.  It contains a default folder structure for you to store your source artifacts in.  Artifacts must be stored in this folder but it is totally up to you how it is structured.  We chose to mirrored DABs folder structure so it was familiar to migrating user’s.  At some point in the future I am hoping we will be able to add a project template facility that may show other structures and include sample artifacts for a specific problem domain.

As the project is also a regular java project src is the registered java source folder.  Java source can go in here.  If your project contains a module artifact, for example, as per this post and this one .

The resources in both of these folders get “built” into bin .   From here the set of built artifacts get packaged into the dar in bin-dar , normally hidden.  Some artifacts can also have content which is stored in content , again hidden.  The dar folder, also again normally hidden, contains the source dardef artifact (i.e. dar manifest – system managed) and the dmc_dar type; instances of which store information about the installed application (artifact URN->OID mappings, etc).  This will be the subject of my next post actually.

Installation Parameter Files is an optional place to store parameter/value maps for installing into different docbases.

Lastly, Web Services/src is the source folder for DFS Web Services (described in this post and this one ).  Web Services/gen-src contains the java source of the generated JAX-WS web service (a DFS web service produces a JAX-WS web service which is then built) and Web Services/bin contains the built version of that web service along with all of its associated web resources.

So, to the check-in question.  A derived resource is any resource that is generated from source artifacts as part of the build process.  That also includes new source that is generated from your source; i.e. Web Services/gen-src.  These don’t need to be checked in because they will get re-built.  So the set of resources that you do need to check-in is highlighted in red:-

For those that asked I hope that helps clarify the situation.

Happy Composing!