CSIDE 22.4 taking FOREVER to compile

HFCDev

Hi,

I had this in the past with older versions of CS and CSIDE, but this started up recently with my CSIDE 22.4 deployment on Eclipse 22-12 on Windows Server 2019. I think it may be related to a Windows update that was foisted on me, but have no way to prove it or back it out. This is also a Virtual Machine on VMWare 15.

Anyone else getting anything like this? If I save a file with Autocomplete turned on, I will be hung for 90 seconds to 2 minutes. If I turn autocomplete off, I still have to manually build and it takes that time still. I tried setting thread sockets timeout down to 10 seconds from 30 to see if that would make any difference. It did not.

-Hugh

David Henshaw

@HFCDev Hugh -

A) Do you have the Admin service running in the VM and if so, have you suspended indexing?

B) If you're on 22.4, you could try using OBuild for the build rather than the Eclipse plugin. This looks promising - I've even containerized this so I can run a docker container on my desktop when I want to do a build. To do that, I've got my own Dockerfile to do a build with….looks something like following:

FROM registry.opentext.com/otxecm:22.4.2


WORKDIR /tmp


COPY OBuild/ ./


RUN mkdir -p ./src


RUN cp -R /opt/opentext/firstruncopy/config/* /opt/opentext/cs/config


ENTRYPOINT ["./obuild.sh", "--OTHOME /opt/opentext/cs --SRCDIR src --DSTDIR build-output"]

Obviously you'll need to authetnicate to the OT registry prior to doing the Docker build, and to also retrieve OBuild from OT Support and place in relevant folder under where the Dockerfile is.

The docker build creates an image derived from the otxecm image, copies the OBuild files into it (in /tmp) and then copies the relevant config file “baselines” into the config directory. I found that OBuild will run even if there's no DB connection defined etc, but only if there's a valid config file, even if only a “scratch” one that you'd usually finalise during install.

I'm tagging the built image from above with the same version as the otxecm image - i.e. I'd build the image and tag as “obuild:22.4.2”

This was sufficient that I can then navigate to my source code (we use Git, so I simply checkout the project into a working directory and ensure I'm in the equivalent of srcmodules, which in turn contains one folder per module. The module folders must contain a valid module.ini file.

I can then fire up powershell and run

docker run --rm -it -v "$(pwd):/tmp/src" -v "$(pwd)/../build-output:/tmp/build-output" obuild:22.4.2

This creates a container from the image, maps the current directory to /tmp/src in the container. It also maps a build-output location.

The ENTRYPOINT in the build file above defines that when the container runs that OBuild is to be run, using /opt/opentext/cs (which is were CS is installed in the OT images) as the OTHOME location, use the source located in src (which is mapped back to my local machine) and put the build outputs into build-output.

Voila! Build (OSCript) code without CSIDE!

I would point out I've noted some areas for improvement in OBuild.

It doesn't copy all the folders from your module into the final build. Rather it seems that OpenText have defied a set of “known good” folders that OBuild should pick up from your source and place into the build output - e.g. html, support, help, adminhelp etc. But folders like ojlib which contains JAR libraries you may be using in your module seem to be missing from the build output.

I've flagged this on another forum and am hoping @Juliano_Ghisi picks these up.

It's also a shame that there's a dependency on the module.ini file. I would argue that this should be an output of the build process since it fundamentally echoes content in the module's OSpace anyway!

Otherwise, I'm going to eventually look at using Ant or something to arrange the build.

My eventual goal is to hook this up such that when code checkins take place, an automated build occurs and any errors are reported. IT also ensures that the build takes place with no other modules installed - so if someone has made an accidental reference to a function that isn't part of the core install base the build should fail.