migtools/tackle-controls

Project does not start in dev mode

Closed this issue · 0 comments

./mvnw quarkus:dev does not start the project due to java.util.NoSuchElementException: SRCFG00011: Could not expand value IFS+x in property BASH_FUNC__module_raw%%

I've followed the instructions of the Readme file using Docker instead of Podman:

# Start postgresql
docker run -it --rm=true --memory-swappiness=0 \
--name postgres-controls -e POSTGRES_USER=controls \
-e POSTGRES_PASSWORD=controls -e POSTGRES_DB=controls_db \
-p 5432:5432 postgres:10.6
    
# Start keycloak             
docker run -it --name keycloak --rm \
-e KEYCLOAK_USER=admin -e KEYCLOAK_PASSWORD=admin -e KEYCLOAK_IMPORT=/tmp/keycloak/quarkus-realm.json \
-e DB_VENDOR=h2 -p 8180:8080 -p 8543:8443 -v $(pwd)/src/main/resources/keycloak:/tmp/keycloak:Z \
jboss/keycloak:12.0.2

# Start the project in dev mode
./mvnw quarkus:dev

The log console gives:

2021-02-25 11:21:48,838 ERROR [io.qua.run.Application] (Quarkus Main Thread) Failed to start application (with profile dev): java.util.NoSuchElementException: SRCFG00011: Could not expand value IFS+x in property BASH_FUNC__module_raw%%
        at io.smallrye.config.ExpressionConfigSourceInterceptor.lambda$getValue$0(ExpressionConfigSourceInterceptor.java:44)
        at io.smallrye.common.expression.ExpressionNode.emit(ExpressionNode.java:22)
        at io.smallrye.common.expression.CompositeNode.emit(CompositeNode.java:22)
        at io.smallrye.common.expression.Expression.evaluateException(Expression.java:56)
        at io.smallrye.common.expression.Expression.evaluate(Expression.java:70)
        at io.smallrye.config.ExpressionConfigSourceInterceptor.getValue(ExpressionConfigSourceInterceptor.java:37)
        at io.smallrye.config.ExpressionConfigSourceInterceptor.getValue(ExpressionConfigSourceInterceptor.java:18)
        at io.smallrye.config.SmallRyeConfigSourceInterceptorContext.proceed(SmallRyeConfigSourceInterceptorContext.java:20)
        at io.smallrye.config.SmallRyeConfig.getConfigValue(SmallRyeConfig.java:192)
        at io.quarkus.vertx.http.runtime.devmode.ConfigDescriptionsSupplier.get(ConfigDescriptionsSupplier.java:44)
        at io.quarkus.vertx.http.runtime.devmode.ConfigDescriptionsSupplier.get(ConfigDescriptionsSupplier.java:13)
        at io.quarkus.vertx.http.runtime.devmode.DevConsoleRecorder.addInfo(DevConsoleRecorder.java:37)
        at io.quarkus.deployment.steps.DevConsoleProcessor$runtimeTemplates-308161071.deploy_24(DevConsoleProcessor$runtimeTemplates-308161071.zig:54963)
        at io.quarkus.deployment.steps.DevConsoleProcessor$runtimeTemplates-308161071.deploy(DevConsoleProcessor$runtimeTemplates-308161071.zig:160)
        at io.quarkus.runner.ApplicationImpl.doStart(ApplicationImpl.zig:1026)
        at io.quarkus.runtime.Application.start(Application.java:90)
        at io.quarkus.runtime.ApplicationLifecycleManager.run(ApplicationLifecycleManager.java:97)
        at io.quarkus.runtime.Quarkus.run(Quarkus.java:66)
        at io.quarkus.runtime.Quarkus.run(Quarkus.java:42)
        at io.quarkus.runtime.Quarkus.run(Quarkus.java:119)
        at io.quarkus.runner.GeneratedMain.main(GeneratedMain.zig:29)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at io.quarkus.runner.bootstrap.StartupActionImpl$3.run(StartupActionImpl.java:134)
        at java.base/java.lang.Thread.run(Thread.java:834)

This seems to be the same bug mentioned in quarkusio/quarkus#15269 and it was fixed in Quarkus 1.12.0