Issues migrating from submodules to versioned artifacts

Hi guys,
We have working an old version of OR for months, however some of the new features are needed and we want to migrate to the new version. Some of the problems are that custom java code has stopped working, and trying to start from scratch some changes are not reflected when deploying the application, sometimes. That’s why I wanted to run through the steps to see if I missed anything.
I started from the Reschool version, to which I have added in the code a realm for the city of Girona, customising icons and the map.
I open the project in IntelliJ, in theory it’s correctly configured, and compile the code using:
./gradlew clean installDist

All OK, perfect, then I mount the images, first:

docker build -t openremote/deployment:custom ./deployment/build/

(now I don’t mount the image docker build -t openremote/manager:custom ./openremote/manager/build/install/manager/ anymore because the openremote directory doesn’t exist, right?)

So second:

OR_ADMIN_PASSWORD=secret OR_HOSTNAME=localhost docker-compose -f docker-compose.yml -p custom up -d

and then I’m able to see the app in the browser.

In fact, it seems I’m using version 1.5.0 according to the Appearance tab:

And I can see from the beginning I have 2 realms: Master and Girona, it’s strange because Amsterdam it’s defined too (in CustomKeycloakSetup.java and CustomManagerSetup.java) but I can’t see it. Well, it’s not very important, maybe it’s something related to previous versions, let’s continue…

I’m a bit confused, since the gradle.properties contains:

version = 1.0-SNAPSHOT
openremoteVersion = 1.2.1

Should I type there 1.5.0? And use yarn up -E "@openremote/*@^1.5.0"

Why does version 1.5.0 appear when 1.2.1 is still written in part of the files? I guess I’ve skipped a step. The documentation is not clear, I would even say obsolete.

Ok, let’s say that now I want to add some java code (agents, assets…). I stop the application with:
OR_ADMIN_PASSWORD=secret OR_HOSTNAME=localhost docker-compose -f docker-compose.yml -p custom down
I even remove the image:
docker volume rm custom_deployment-data
I add the new code and recompile and mount the application following the same steps as at the beginning and fine, I can see and add my custom agent.
So, have I been doing the right steps or am I missing something? What about the questions above?

And another problem I would like to solve, I can deploy the application with docker-file, but I can’t run it from IntelliJ. I would like to do it when I am developing new java code, to debug it, but it doesn’t work.

Basically, before I used to run the instruction:

npm run serve -- --env config=../../../../deployment/manager/app

inside the openremote folder, but it doesn’t exist anymore, and run the ‘Custom deployment’ configuration. In the case of the version with artifacts, what are the steps to follow?

I add below my docker-compose.yml, just in case.
I would need to be clear that I’m on solid ground before proceeding with the next steps: how to deploy the new version on our server without losing one year of data, and how to deploy the smartphone app, well, step by step…

Thanks in advance, sorry for this rather long literary piece :wink:

version: '2.4'

volumes:
  proxy-data:
  deployment-data:
  postgresql-data:
  manager-data:

services:

  # This service will only populate an empty volume on startup and then exit.
  # If the volume already contains data, it exits immediately.
  deployment:
    image: openremote/deployment:custom
    volumes:
      - deployment-data:/deployment

  proxy:
    image: openremote/proxy:${PROXY_VERSION:-latest}
    restart: always
    depends_on:
      manager:
        condition: service_healthy
    ports:
      - "80:80"
      - "443:443"
      - "8883:8883"
    volumes:
      - proxy-data:/deployment
      - deployment-data:/data
    environment:
      LE_EMAIL: ${OR_EMAIL_ADMIN}
      DOMAINNAME: ${OR_HOSTNAME?OR_HOSTNAME must be set}
      DOMAINNAMES: ${OR_ADDITIONAL_HOSTNAMES:-}

  postgresql:
    image: openremote/postgresql:${POSTGRESQL_VERSION:-latest}
    restart: always
    volumes:
      - postgresql-data:/var/lib/postgresql/data
      - manager-data:/storage
    ports:
      - "5432:5432"        

  keycloak:
    image: openremote/keycloak:${KEYCLOAK_VERSION:-latest}
    restart: always
    depends_on:
      postgresql:
        condition: service_healthy
    volumes:
      - deployment-data:/deployment
    environment:
      KEYCLOAK_ADMIN_PASSWORD: ${OR_ADMIN_PASSWORD:?OR_ADMIN_PASSWORD must be set}
      KC_HOSTNAME: ${OR_HOSTNAME:-localhost}
      KC_HOSTNAME_PORT: ${OR_SSL_PORT:--1}

  manager:
    image: openremote/manager:${MANAGER_VERSION:-latest}
    restart: always
    logging:
      options:
        max-size: "10m"
        max-file: "10"
    depends_on:
      keycloak:
        condition: service_healthy
    volumes:
      - manager-data:/storage
      - deployment-data:/deployment
      - ./deployment/map:/deployment/map

    environment:
      OR_ADMIN_PASSWORD: ${OR_ADMIN_PASSWORD?OR_ADMIN_PASSWORD must be set}
      OR_SETUP_TYPE: # Typical values to support are staging and production
      OR_SETUP_RUN_ON_RESTART:
      OR_EMAIL_HOST:
      OR_EMAIL_USER:
      OR_EMAIL_PASSWORD:
      OR_EMAIL_X_HEADERS:
      OR_EMAIL_FROM:
      OR_EMAIL_ADMIN:
      OR_HOSTNAME: ${OR_HOSTNAME?OR_HOSTNAME must be set}
      OR_ADDITIONAL_HOSTNAMES: ${OR_ADDITIONAL_HOSTNAMES:-}
      OR_SSL_PORT: ${OR_SSL_PORT:--1}
      OR_DEV_MODE: ${OR_DEV_MODE:-false}
      OR_MAP_TILES_PATH: ${OR_MAP_TILES_PATH:-/deployment/map/mapdata.mbtiles}
      OR_MAP_SETTINGS_PATH: ${OR_MAP_SETTINGS_PATH:-/deployment/map/mapsettings.json}
      OR_FORECAST_SOLAR_API_KEY:
      WEBSERVER_LISTEN_HOST: 0.0.0.0
      IDENTITY_NETWORK_WEBSERVER_PORT: 443
      OR_FIREBASE_CONFIG_FILE: /deployment/manager/fcm.json

Hi @pacogam!

That’s right you should no longer use the openremote directory in your custom project and move/remove it to prevent any confusion.

Yes that’s what you should do to use OpenRemote v1.5.0 in your custom project.

It’s because the version number shown in the UI is part of the OpenRemote Manager Docker image specified in your docker-compose.yml file:

The version numbers specified in the gradle.properties and package.json files are used for defining the OpenRemote artifact versions used when compiling your custom project Java and TypeScript code. You should update them to make sure your custom project code keeps compiling correctly.

Did you use this for running a custom UI in your custom project or for running the manager?
Did you also update your project.gradle file?

If you run the “Custom Deployment” of a custom project in IntelliJ IDEA it will run the manager using this directory as OR_CUSTOM_APP_DOCROOT:

When developing a custom app you can also run npm run serve in the directory of a custom app when the package.json file is similar to:

All the recent changes should not remove any data. It is always good to have backups and a staging environment where you can test upgrades.

Hi, thanks for your reply.
I was resistant to use yarn because I already did it a few days ago and it stopped compiling. Now it happened again, here’s what I did:
I changed the OR version in gradle.properties and package.json, I tried 1.5.0, 1.4.0 and 1.3.5.
I ran yarn up -E "@openremote/*@^x.x.x" (where x.x.x is the version)
And finally tried to compile with ./gradlew clean installDist

The error messages say, among other things:

* What went wrong:
A problem occurred configuring project ':deployment'.
> Could not create task ':deployment:installDist'.
   > Could not resolve all dependencies for configuration ':deployment:runtimeClasspath'.
      > Could not resolve io.openremote.ui:openremote-console_loader:1.3.5.
        Required by:
            project :deployment > project :setup
         > No matching variant of io.openremote.ui:openremote-console_loader:1.3.5 was found. The consumer was configured to find a runtime of a library compatible with Java 17, packaged as a jar, preferably optimized for standard JVMs, and its dependencies declared externally but:
             - Variant 'apiElements' capability io.openremote.ui:openremote-console_loader:1.3.5 declares a library, packaged as a jar, and its dependencies declared externally:
                 - Incompatible because this component declares an API of a component compatible with Java 21 and the consumer needed a runtime of a component compatible with Java 17
                 - Other compatible attribute:
                     - Doesn't say anything about its target Java environment (preferred optimized for standard JVMs)
             - Variant 'javadocElements' capability io.openremote.ui:openremote-console_loader:1.3.5 declares a runtime of a component, and its dependencies declared externally:
                 - Incompatible because this component declares documentation and the consumer needed a library
                 - Other compatible attributes:
                     - Doesn't say anything about its target Java environment (preferred optimized for standard JVMs)
                     - Doesn't say anything about its target Java version (required compatibility with Java 17)
                     - Doesn't say anything about its elements (required them packaged as a jar)
             - Variant 'runtimeElements' capability io.openremote.ui:openremote-console_loader:1.3.5 declares a runtime of a library, packaged as a jar, and its dependencies declared externally:
                 - Incompatible because this component declares a component compatible with Java 21 and the consumer needed a component compatible with Java 17
                 - Other compatible attribute:
                     - Doesn't say anything about its target Java environment (preferred optimized for standard JVMs)
             - Variant 'sourcesElements' capability io.openremote.ui:openremote-console_loader:1.3.5 declares a runtime of a component, and its dependencies declared externally:
                 - Incompatible because this component declares documentation and the consumer needed a library
                 - Other compatible attributes:
                     - Doesn't say anything about its target Java environment (preferred optimized for standard JVMs)
                     - Doesn't say anything about its target Java version (required compatibility with Java 17)
                     - Doesn't say anything about its elements (required them packaged as a jar)

I’m not sure if it’s related to the Java version.

Regarding the use of npm, I just wanted to use it like the submodule versions, from intelliJ, to debug code that doesn’t work right now. I’ve separated the problems into different topics.

EDIT: mmm… I just see I have a lot of problem with imports, for example:

import com.fasterxml.jackson.databind.node.**ObjectNode**;
import org.openremote.agent.**protocol**.AbstractProtocol;

I need to find out more about this.
Thanks again