Dr. Stefan Winkler
freier Softwareentwickler und IT-Berater

This article is part of a series to help newcomers to get started with Eclipse Theia development by setting up a local docker-based development environment for Theia.

After having written the previous article Getting started with Eclipse Theia (1): Starting Theia Development in a Docker Dev Environment, I have tried the same setup on a different machine which does not have a Docker Desktop installation, but which uses docker-machine to manage its containers in a boot2docker VM.

My goal was to achieve a similarly easy startup on this machine (and also on Linux machines for which Docker Desktop is not available). By digging a bit deeper into the inner workings of the Docker Dev Environments feature, I have learned that most of the functionality is also available in VS Code directly via the Remote Containers Extension.

Similar to the Docker Dev Environments feature, you can add a folder .devcontainer to a repository containing a file called devcontainer.json. Then, anyone can directly clone this repository and start working on it inside a docker container with VS Code. This is how my devcontainer.json file looks like:

{
	"name": "theia-dev",
	"context": "../docker-container",
	"dockerFile": "../docker-container/Dockerfile",
	"forwardPorts": [3000],
	"postCreateCommand": "yarn && yarn theia build",
	"remoteUser": "node"
}

The Dockerfile referenced here is the same we have used for the Docker Dev Environments in the last article.

To get started, after installing the Remote Containers Extension in VS Code, follow these steps:

  1. From the Command Palette (F3), run "Remote-Containers: Clone Repository in Container Volume“.
  2. Enter the URL to the repository (or clone my repository github.com/xpomul/theia-boilerplate.git) and follow the navigation to select your GitHub repository
  3. Now wait. The container will be built, the repository will be cloned in a volume, and even the yarn and yarn theia build commands will be executed automatically (as specified in the devcontainer.json).
  4. After everything is done, you can close the Terminal, open a new one and just run yarn theia start --plugins=local-dir:plugins and your Eclipse Theia instance will come up at http://localhost:3000 

Again, from here, you can follow the usual Theia tutorials and start experimenting.

Have fun!

This article is part of a series to help newcomers to get started with Eclipse Theia development by setting up a local docker-based development environment for Theia.

So here it is. After over 10 years of Eclipse development, I wanted to get my hands dirty on something entirely new. I have followed the developments of Orion, Che, and Theia for a long time, but only from a distance; and I just didn’t have the time to actually try out, let alone to get involved with, these projects.

I have used Gitpod a few times, but merely to have a quick look into a GitHub repository when I didn’t have a local development environment and didn’t want to get one up and running.

Yet, I have noticed an increasing interest from my customers in web-based environments and so, I wanted to finally play around with Eclipse Theia.

But how? I have found this article which provides several options to run Eclipse Theia in different ways, but none of those options really hit the spot for me. I wanted to run a Theia instance in my browser, so Theia Blueprint was not an option. I wanted to be able to work offline, so using Gitpod was not possible. And I didn’t want to install nodejs on my machine. But still the goal was to get a basic Theia product up and running that should be ready to start hacking and customizing it, and then to jump in and create my first Theia extension.

I had started, and aborted again, several attempts to create a Docker container in which I could do that. But so far, I had not managed to create a smooth environment.

Domain specific languages are a great tool when we want to give our users control over complex aspects in our applications; and in most cases, experienced uses can learn syntax and semantics of a well-designed DSL quickly. But on the other hand, there are also inexperienced users, who usually struggle with DSLs and do not want to deal with textual input. Instead, they are used to graphical user interfaces which help them to grasp the structure of information and to enter new data.

Last week, I had a project, in which I needed to provide both groups of users with a suitable user interface. In other words, I needed to create an editor, which provides both an Xtext source editor for my DSL, and a GUI editor for the model behind the DSL.

I started to search the Internet for some hints on how to do this but I did not find a complete example. Basically, to combine multiple editors into a single one, we have to subclass and implement an org.eclipse.ui.part.MultiPageEditorPart. But I did not find more than hints about how to share the model between an Xtext editor and another editor. So, I started experimenting and after some time I was successful, and I wanted to let you participate in my results. Maybe this helps someone who is looking for an example as well.

For the rest of this post, I will use the state machine example that comes with the Xtext distribution as a starting point. To demonstrate the solution I will add a GUI editor for events to the generated Xtext editor. For brevity, I will only show the relevant parts. The full modified example source code is available on GitHub.

Sometimes I need to test something in a VM which has an independent system time. Usually, this has to do with server applications which react time-based (think of a system in which users may enter information until a certain day is reached, after which only read-only is allowed). 

On a standard installation of VirtualBox and Ubuntu 16.04, the system time is automatically synced to the host. When trying to change the date using date -s 2015-01-01 the date will be updated but will revert to the host's date after a few seconds.

Since I end up googling the correct way to disable the time synchronization in an Ubuntu VirtualBox client every time I set up my VM from scratch, I am posting the steps here as my personal reminder (it is always nice to get one's own article in a google result because one has forgotten ;)) - and maybe someone else also finds this useful:

  1. Disable host time access (this is mentioned here - no idea if this is really required...):
    On the host, execute: 
    VBoxManage setextradata "vm-name" "VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" 1
  2. Disable client time sync:
    On the client, edit /opt/VBoxGuestAdditions-5.1.2/init/vboxadd-service  and in start() replace
    daemon $binary --pidfile $PIDFILE > /dev/null
    with
    daemon $binary --disable-timesync --pidfile $PIDFILE > /dev/null

    and also look for the definition of daemon() and add the fourth argument
    if which start-stop-daemon >/dev/null 2>&1; then
      daemon() {
        start-stop-daemon --start --exec $1 -- $2 $3 $4
      }
    ...
  3. Just to be sure, remove the Ubuntu timesyncd as well:
    On the client, execute:
    rm /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service

Reboot and from now on, changed system dates stay as intended.

BTW, I would like to be able to decouple the system time in docker as well, but from my understanding this is not possible because docker uses the host RTC directly and the only way to differ here is to set a different timezone, which has its limitations. But if someone knows a way to simulate a different system time in docker, I would love to hear about it!