It looks like OpenText has released Documentum 24.2, and I say “looks like” because current access in (our “beloved”) support page is a mess. I guess there’s still confusion even on OT regarding the new X plans, which are supposed to be in place for accessing 24.2 release.

Currently I have:

• No access to on premise downloads other than xCP 24.2 (?)
• Access to cloud images
  • Can’t download cmis (not entitled)
  • Can download everything else 😀

I guess this will be sorted out in the coming weeks (or months…). However, as I have access to the cloud images, I’ve been able to install 24.2 locally. I won’t explain the whole process, but as it is quite simple, you can do something like:

• Extract content server binaries from the cs image
• Copy those to an image similar to the one described on the 23.4 install guide, using Java 17.0.10
• Remove not needed folders
• Replace /opt/dctm locations with your own $DOCUMENTUM path
• Install normally 🙂

With these done, some impressions (as I don’t have access to release notes, I have no idea what’s new). On the positive side:

• Cloud images now support both PostgreSQL and Oracle
• Most of the (web) applications are supported in the “decoupled” mode (which is still non-sense, as a war file is not a container and it should not be anything else that an artifact outside of the image mapped in /webapps or wherever…)
• No more breaking changes added to what we had on 23.4 (Tomcat 10, OTDS)

On the negative side:

• The Oracle / PostgreSQL configuration is implemented very poorly. The image contains both “documentum_postgresql” and “documentum_oracle” binaries and these are configured from a script with an if statement and a “mv documentum_xxx documentum”. Maybe a symbolic link to the binaries being configured on startup would have look more… professional.
• In an absurd move only understood because I’m sure OT has different people building the images and some of them are juniors, we’re back at the stupid-size containers (OT engineering, please check again the post on how to build a container image). Why I say this?
  • dctm-tomcat image is 800mb. Why? Because it contains TWICE the JDK (+300mb that could be saved), so this image should be around 500mb on size
  • dctm-admin image is 900mb (bigger than Tomcat… without Tomcat!!). Why? Because it contains THREE TIMES da.war plus TWICE the OS packages cache, so this image should be around 200-300 mb on size
  • dctm-rest is properly build, and dctm-rest.war is only present once in the container’s layers (good job whoever did this).

Here you can see the dctm-server image layers:

And here the (disaster) of dctm-admin:

I guess we can expect for 24.4 again the “decrase on containers image size” that was presented as a brand new feature in earlier versions…