Jython on Documentum part 3

March 12, 2009 at 5:44 pm | Posted in Continous Integration, Jython | Leave a comment
Tags: , ,

It’s been a while since I’ve blogged and even longer since I blogged about Jython on Documentum. Sadly excessive work schedules have prevented me from blogging as much as I would like and it’s unlikely to change for the forseeable future. Anyway I’m waiting for a build to run so I’ve got 5 minutes for a coffee and a swift blog.

Since my last Jython on Documentum post I’ve been using jython in a real-live project as part of a build system. The next couple of posts will record some things that I found out.

First up is organising script files. In my previous posts I had just been using jython by changing to the installation directory, saving a .py file and running it from the installation directory. This is not really a great way to organise your script files. I’ve found the following organisation to work well though no doubt there are other ways to do the same thing.

First I have my jython installation in say c:\jython2.2.1. So anytime I want to kick off a jython script I do the following:

  • Start a cmd prompt
  • set path=%path%;c:\jython2.2.1
  • jython

Next I organise my jython scripts in the source code repository in their own folder structure. Something like /scripts/jython/dctm or something similar. The scripts can then be included in builds or deployments as necessary.

A useful object to know about is the sys.path object. This is represents the classpath that jython uses to pickup python libraries, this includes libraries you write yourself (just standard jython code files). You can easily import an external library using the following code snippet (which I have seared into my brain!):


import sys
sys.path.append('scripts/jython/dctm')
import dctm

sys is a standard python library that contains a lot of useful system functions/features. One of them is the aforementioned sys.path. The append method allows you to add extra paths that jython can use to look for libraries. In this case the relative path script/jython/dctm is where I keep my standard dctm.py library. After these lines I can use the dctm object to access any of the methods in dctm.py.

So my standard dctm.py is stored scripts/jython/dctm, my project specific jython file (e.g. myfile.py) is also stored in this folder structure. By navigating to the top-level folder (the one containing the scripts folder) I can run jython like this:

jython myfile.py
Advertisements

Why DocApps are bad

January 27, 2009 at 5:23 pm | Posted in Continous Integration, Development | 4 Comments
Tags: , ,

A recent comment on one of my posts pointed out that you could script DocApp installs using an unsupported ant task. This is certainly a useful facility however it doesn’t overcome the basic problem with Documentum Application Builder and DocApps – they don’t integrate well with source code control systems that are used to maintain all the other code and artefacts needed to develop a working system.

Think how you probably develop code for your system. You probably store your source code in a repository (Visual SourceSafe, Subversion, CVS, etc.). You probably have integrations in your IDE to allow you to automatically checkout and checkin code. You probably build your code automatically from the source code system. This is is all fairly standard development practice (hopefully!).

If you are a little more advanced then maybe you also package and deploy your application automatically and you store automated tests in your source code control system. The tests would be automatically executed whenever you build and deploy from your souce code control system.

Basically the source code control system is the lynchpin of your whole development effort. Using version control and labelling you can see how different releases have progressed and maybe track where and when bugs were introduced.

DocApps sit completely outside of this setup, you are effectively using a development docbase as an alternative source code control system – without all the benefits of a properly featured SCC! In an ideal world all your Documentum configuration assets would live in the source code control system – that includes things like type definitions. Now all the source artefacts for your development live in one place. Hopefully this is exactly what Composer will allow you to do.

Momentum 2008 – Composer

December 3, 2008 at 10:26 pm | Posted in Architecture, D6, Momentum | 7 Comments
Tags: ,

Ever since I got back from Momentum it’s been work, work, work. That’s what happens when you take 4 days off to look around at what’s going on. I recall that I was going to post some more thoughts on some of the other products that I saw.

I went to David Louie’s presentation on Composer. Have to say I was impressed with what I saw. This maybe because I’ve been developing with Eclipse for a while now, so having something that integrates natively with this environment is a big plus. Whilst there are many interesting functional features of Composer I was most interested in a single slide that compared Composer with Application Builder.

First Composer doesn’t require a connection to the docbase to get your work done. You can of course import objects from a docbase, but you can also import from a docapp archive.

Secondly Composer can install your application (a DAR, similar to a DocApp in concept) into a docbase via a GUI installer but you can also use something called Headless Composer which is a GUI-less installer that runs from the command line. Not absolutely sure on the specifics at this point but possibly uses ant. David said that there are details in the documentation – I will be sure to try it out and post my findings at a later date.

This last point was of great interest to me as I’m currently investigating how to run Documentum development using a continuous integration approach. Being able to deploy your artifacts from the command line, and therefore from some overall automated controlling process is essential to making continuous integration a reality. On this note I also spoke to Erin Samuels (Sharepoint Product Manager) and Jenny Dornoy (Director, Customer Deployments). I hope that the sharepoint web parts SDK that is likely to integrate into MS Visual Studio will also have support for a headless installer, and also that Documentum/EMC products generally support the continuous integration approach.

Create a free website or blog at WordPress.com.
Entries and comments feeds.