A year ago, I tried Composer when my first project began to upgrade to D6. Without going into too much detail, it sucked. I loaded my DocApp and Composer completely rejected it. After a couple of days, I gave up. If I had been creating a new application, maybe it would have been fine, but I wasn’t. After talking to David Louie, I sent the DocApp in question to EMC and got the report, “it works in the new version”. Well, it was too late and I wasn’t changing my developer’s environment mid-process.
Now that project is progressing down the D6.5 path. I thought I would try again, and document the process for everyone.
I’m writing this post “live”. Which means I won’t post it live, but I won’t edit the post to disguise steps and my thoughts as I try things.
Lots of “warnings” in the project, 49 to be precise. This isn’t too bad as I had errors with D6. 48 of the warnings are:
Search operators for attribute ‘custom_attribute_1’ are not defined…….custom_type1.type
No big deal. I’ll get a developer to enter that into the system to clear the warnings. The users don’t use any Documentum-driven search so it isn’t an issue. The last warning was interesting:
Content Type must be ‘jar’ instead of ‘java’. Please contact technical support for further assistance….shared_utilities.jar.jardef
That may be a problem. I know it works, but I am curious as to why it is an issue, or if it is, why it works. I am also worried about the urging to contact technical support. I suspect that is partially CYA. Mind you, this file seems to be happy as a clam sitting under the Java Libraries group as well. (See note below*)
I’m feeling adventurous. I have decided to throw the project into a clean repository. This is one thing that I like about Composer, the ability to install into multiple repositories, assuming they share a connection broker, without restarting. Of course, the downside it that I get tired of logging into the repository every time I want to interact with it. On the other hand, I can work offline. (See note below**)
And it installed. Now for a test. (Imagine a long pause with lunch) EUREKA! It worked. So I’ll ignore those warnings for now as they don’t seem critical and clean them up later.
For my next trick…
Adding Source Code
In the old days, I wrote TBOs in Notepad and compiled them on the command line before ingesting them into the Application Builder. Then I evolved, with a push from my developers, into developing in Eclipse before dragging them into Documentum. When D6 came out, I tried to combine development into Composer. It didn’t go well.
The biggest problem, for there were a few, was Subversion. For those not familiar with it, Subversion is an open source code control system. It is fairly useful and I have used it for clients and personal projects. The problem we encountered was that the hidden directories that are used by Subversion to track code, .svn, were copied around by Composer and created havoc that we did not encounter in standard Eclipse.
To see how things have changed, I have loaded the source code for the TBOs, and supporting java POJOs, into Composer from Subversion. I haven’t added the plugin to Composer yet as that effort is for another day. I just used Tortoise SVN.
At first glance, things are fine. I build/compile everything, and aside from having to go back and add dfc.jar to my library path (which should be automatic), it works fine. Of course, my classes didn’t show-up anywhere. When I look under the covers, I see that the .svn folders have been copied to the compiled location. Ugh!
Time to look at using ANT to do the build and to then update the jar object. After a little research, I quickly find a couple of Paul Warren’s posts on the topic. The first post appears to focus on integrating BOF development into Composer, so I’ll start there.
Hmmm, instructions are solid, but the UI seems resistant to remembering my changes. Changing the location is actually not working, but I’ll pass for now, or not. Finally got it to work by removing the DFS Builder from my builder list. Not ideal for long-term, but for now it’ll do. While I was getting the the relocation to work, I added an exclude **/.svn/ which got all the Subversion directories out of my way as well.
Back on track…pause while I follow Paul’s post…and I have a jar file! It is a little bigger than I want, so let’s see what I can do about that. Ah, adding the include/exclude tags allows me to filter what I want created. I’ll need to spend some time on my build file to get all my specific jar files I need, but I may pass that off to my development team.
The directions are simple, but I’m not starting from scratch, so instead of test.jar I have jarFile in the artifact. I make the quick change and then.
That should do it. So I make a change to my base java file and rebuild and the install my application. The result…everything seems okay. Time to make a substantive change and see the impact. I’ll cancel a validation and then reinstate it.
The Verdict: Composer WORKS! Life is good and I’m going to start pushing it out to my teams as they move to D6.5.
Some other thoughts from using Composer recently…
- The DAR installer worked quite nicely with the Records Manager DAR files. Shame it has such a large footprint.
- I created a new object type with a fair amount of parameters and it worked just fine.
- Paul’s second post, Using Documentum Composer to streamline the BOF2 Development Process, outlines a way to test BOF code within Composer. That is a task for another day.
- * I fixed this easily. I opened the jardef as text, like I did to associate it with a local jar file when following Paul’s directions. I replace the existing, incorrect contentTypeFormat tag with <contentTypeFormat href=”urn:com.emc.ide.artifact.format/jar?name=jar#//@dataModel”/> . When I installed the application, again, it worked.
- ** Okay, this is pretty sweet. I was able to change the dfc.properties file and it took effect without restarting Composer. I forgive the constant authentications now.
- One annoying thing, I have to install everything when I make one small change. I wish I could just install selected artifacts.
- No issues throwing my Artifacts into Subversion.
7 thoughts on “My Journey from DocApp to DAR”
Many thanks for the post on Composer and the links to my blog. I am extermely glad you second expereience was considerably better than the first appeared to be!
Hi Paul we’re facing the same journey to DAR, and the experience is being pretty similar,
The most annoying thing is that every little change in a TBO implies a reinstallation of all the artifacts.
We’ve tried to replace the jar through DA (in System/Modules/TBO/customtype.jar) but is not working, and we can’t afford “(Imagine a long pause with lunch) EUREKA!” 20 times a day
There’s also a tool called dar installer, but we really don’t know how to generate/export individual dars as TBO’s or SBO’s, to be able to install them.
Have you used the Dar installer or know about any workaround to avoid installing the complete “Docapp”?
Anyway thanks for sharing your experience and congrats for your blog.
I understand the whole “reinstall” the world. We haven’t determined a workaround yet. I have toyed with multiple applications, but that just creates issues with configuration management. Installer select objects is my top feature request that I’ll be bugging the Composer guys at EMC World for this year.
Oh, and it’s Pie. Paul is the intelligent previous commenter.
There is still the option of the bof development mode i.e. one initial deployment to the target repository and then you subsequently test your TBO locally without any re-deployments necessary.
(Well, as described in the 2nd link to Paul’s blog)
How do you get Composer to pick up on changes to dfc.properties without restarting? I change plugins\com.emc.ide.external.dfc_1.0.0\documentum.config\dfc.properties and go to “Import” “Artifacts From Repository” and it does not register the change until I restart.
don’tthink that you can. I’ve started a thread on the Developer Network that will either validate that answer or give tips on how to make it work.
Comments are closed.