Only dev and prod profiles work

[agilob]

Overview of the issue

I'm trying to access swagger but noticed that only prod and dev profiles can be used. Starting app with -P dev,swagger starts only dev profile:

        Application 'jhipster' is running! Access URLs:
        Local:                  http://localhost:8080
        External:               http://localhost:8080
        Environment(s):         [dev]

Swagger-ui resource contains invalid content:

[atomfrede]

You are using gradle? Can you try -Pdev -Pswagger ?

[agilob]

$./gradlew -Pdev -Pswagger
....
----------------------------------------------------------
        Application 'jhipster' is running! Access URLs:
        Local:                  http://localhost:8080
        External:               http://localhost:8080
        Environment(s):         [dev]

and the same result when visiting swagger-ui/index.html

[atomfrede]

It is a bug. The dev config does not set micronaut environments at all while the prod config does still set the spring property.

[atomfrede]

Just to make sure, the flags on maven/gradle are mostly used for changing the build/packaging. But to support switching the environment via gradle properties you could do in profile_dev.gradle. I guess the more severe issue is, that when building with prod profile the environment is not compiled into the jar.

if (project.hasProperty("swagger")) {
    profiles += ",swagger"
}

tasks.withType(JavaExec) {
    classpath += configurations.developmentOnly
    jvmArgs('-XX:TieredStopAtLevel=1', '-Dcom.sun.management.jmxremote')
    systemProperties(
        'micronaut.environments':profiles
    )
    if (gradle.startParameter.continuous) {
        systemProperties(
            'micronaut.io.watch.restart':'true',
            'micronaut.io.watch.enabled':'true',
            "micronaut.io.watch.paths":"src/main"
        )
    }
}

[atomfrede]

I think the issue larger than I thought. We build the jar e.g. via -Pprod. This e.g. removes h2 and other dev dependencies from the jar. Starting the jar now fails as it tries to access the database via h2 (but depencies are missing). Setting the micronaut environment via system properties works just fine.

@JasonTypesCodes Correct my if thats wrong, but there is no property like spring.profiles.active to set the environment via properties. So I would propose to write the active profiles into a plain text file (e.g. environment) which is processed during the build to set the active profiles. This file is than read in the main method and set the environment accordingly, what do you think?

[JasonTypesCodes]

micronaut.environments is the property you would use. They can also be set using an environment variable (MICRONAUT_ENVIRONMENTS) and in some cases passed in as a arg (-micronaut.environments).

More info here: https://docs.micronaut.io/latest/guide/index.html#environments

[atomfrede]

We use either MICRONAUT_ENVIRONMENTS or micronaut.environments from system properties and set it in the application context builder. So I think we must read it from a third source in case neither the environment variable nor the system property is provided. Right now the code just uses dev if no environments are provided from the outside.

[agilob]

MICRONAUT_ENVIRONMENTS=dev,swagger ./mvnw

----------------------------------------------------------
        Application 'mhipster' is running! Access URLs:
        Local:                  http://localhost:8080
        External:               http://localhost:8080
        Environment(s):         [dev, swagger]
----------------------------------------------------------

./mvnw -Dmicronaut.environments=dev,swagger
----------------------------------------------------------
        Application 'agileb' is running! Access URLs:
        Local:                  http://localhost:8080
        External:               http://localhost:8080
        Environment(s):         [dev]
----------------------------------------------------------

profile needs to be set using env variable, maven -D doesnt work.

[atomfrede]

Yes. Same for gradle right now, but see above how to extend the gradle file. Nevertheless when building the jar with prod profile it should use prod configuration out of box.