How is the classpath management for SetupTasks done? If I follow the Wiki page about setting up an IDE in IntelliJ, I can have the setupTasks classes found in the classpath. It works fine for org.openremote.setup.demo.DemoSetupTasks. But if I do the following from the command line, no setup tasks are found, because the setupTasks classes are not found in the classpath.
export OR_SETUP_TYPE=demo
export OR_DEV_MODE=true
./gradlew demoClasses run
The only difference between the IntelliJ Ide and the Gradle wrapper script is that in IntelliJ, I need to specify explicitly not to use the Gradle script but to use the “IntelliJ Idea” for that task. This information is found on this wiki page: “Setting up an IDE”, the following instruction:
“Verify build settings: Settings/Preferences → Build,Execution,Deployment → Build Tools → Gradle. Choose for the options ‘Build and run using’ and ‘Run tests using’ the option ‘IntelliJ IDEA’ and click on ‘Apply’.”
If I ignore this step and leave the default “Graddle”, I have the same issues as described on the command line.
The same is true for other setup tasks. They are not loaded in the classpath. If I want to build the load1 setup tasks, I do the following steps:
./gradlew load1Classes run
I have the same issues on the command line as the Demo setup tasks. They are not found. If I run the procedure through IntelliJ, they are not found either.
I can fix all these issues myself, but I want to understand why this is made like it is.
Indeed you are correct that the gradle run task does not have a dependency on setup and the reason it isn’t managed as a standard dependency is because the setup jar is put into a different folder in the final docker image (/deployment/manager/extensions/) compared with other dependencies (/opt/app/lib).
A custom project would then volume map over the /deployment folder providing a custom SetupTasks implementation.
Historically you could only have 1 SetupTasks on the classpath but I made a change a while back to allow multiple (i.e. demo SetupTasks can be on the classpath alongside a custom SetupTasks) and OR_SETUP_TYPE=demo was introduced to allow people to optionally start the standard image with the demo setup or completely empty.
Based on the above change it would simplify things to include the demo SetupTasks as a regular dependency now which I will create an issue for.
As for using the SetupTasks in the IDE; you’ve probably seen that our gradle build adds custom run configurations to IntelliJ which then includes the classes on the classpath.
I raised a bug against IntelliJ which seems to have issues with multiple gradle sourcesets in a module; there is a workaround mentioned in my comments (need to look at whether I can include this workaround in our gradle build config which generates the run configurations).
Thank you for your explanation. I understand now why the choice has been made to exclude the SetupTasks as a Graddle dependency. Architectural-wise, it looks like a wise decision to me. It extends the flexibility for adding modules to the stock docker hub openremote/manager docker image.
This will answer my main question about running the full manager app with ./gradlew run. Another possible solution can be the following. If you build the SetupTasks for demo, you execute ./gradlew demoClasses. Due to the dependencies of this task, the manager is also built. If you run ./gradlew run, check first which SetupTasks has been built, and add it upfront to the classpath at runtime. This possible solution will pick up the SetupTasks at runtime each time but will not hamper the manager build for your docker image. There you do not want to have a fixed dependency on any setuptask.
I am using IDEA for building in IntelliJ. The SetupTasks are given as a module with the build configuration. That works most of the time fine when I build and run. But sometimes, the SetupTasks module is not loaded in the classpath or recognised by the manager. I do not know why. Very likely, it will be something I do wrong. If I do the full reset, it works but consumes time. It would ease development friction to have an easy command line command to execute the manager and its corresponding setup task. If I want to run the manager, I must start each time Intellij. I prefer having a build system and way of running wholly separated from any IDE.
