Generator-jhipster: bootRun on Windows should use main (instead of test) classpath

[abenneke]

Overview of the issue

When you try to run gradlew bootRun right after gradlew test, Spring is using the src/test/resources/config/application.yml configuration instead of the src/main/resources/config/application.yml. The later is used when you run gradlew bootRun after gradlew clean (because the test configuration then simply does not yet exist).

Reproduce the error

• Have configuration in src/test/resources/config/application.yml that does not allow a Spring Boot startup. In our case the default spring.security.oauth2.client.provider.oidc.issuer-uri: http://DO_NOT_CALL:9080/auth/realms/jhipster was enough
• run gradlew test
• run gradlew bootRun right afterwards

Startup fails with java.net.URISyntaxException: Illegal character in hostname at index 9: http://DO_NOT_CALL:9080/auth/realms/jhipster/.well-known/openid-configuration

Related issues

The fix for #9713 introduced the line in question into the build.gradle.

Suggest a Fix

Replace sourceSets.test.runtimeClasspath with sourceSets.main.runtimeClasspath in classpathJar in build.gradle

JHipster Version(s)

Checked version 6.1.x up to 6.3.0

JHipster configuration, a .yo-rc.json file generated in the root folder

.yo-rc.json file

{
  "generator-jhipster": {
    "promptValues": {
      "packageName": "eu.eurogate.project.backend",
      "nativeLanguage": "en"
    },
    "jhipsterVersion": "6.1.2",
    "applicationType": "microservice",
    "baseName": "projectBackend",
    "packageName": "eu.eurogate.project.backend",
    "packageFolder": "eu/eurogate/project/backend",
    "serverPort": "8081",
    "authenticationType": "jwt",
    "cacheProvider": "ehcache",
    "enableHibernateCache": true,
    "websocket": false,
    "databaseType": "sql",
    "devDatabaseType": "h2Memory",
    "prodDatabaseType": "oracle",
    "searchEngine": false,
    "messageBroker": false,
    "serviceDiscoveryType": "eureka",
    "buildTool": "gradle",
    "enableSwaggerCodegen": true,
    "jwtSecretKey": "...",
    "testFrameworks": [],
    "jhiPrefix": "jhi",
    "entitySuffix": "",
    "dtoSuffix": "DTO",
    "otherModules": [],
    "enableTranslation": true,
    "clientPackageManager": "npm",
    "nativeLanguage": "en",
    "languages": [
      "en",
      "de"
    ],
    "skipClient": true,
    "skipUserManagement": true
  }
}

JDL for the Entity configuration(s) entityName.json files generated in the .jhipster directory

JDL entity definitions

Environment and Tools

openjdk version "11.0.3" 2019-04-16
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.3+7)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.3+7, mixed mode)

git version 2.23.0.windows.1

node: v10.16.0

npm: 6.9.0

yarn: 1.16.0

Docker version 19.03.2, build 6a30dfc

docker-compose version 1.24.1, build 4667896b

[atomfrede]

Thanks @abenneke for reporting this. I noticed it too, but as I have no windows machine at hand its hard for me to test that ugly workaround. Could you do a PR and maybe check if continuous compilation and restart via bootDevTools work fine for you?

[abenneke]

Added https://github.com/jhipster/generator-jhipster/pull/10458

Restart via bootDevTools (still) work like a charm for me - but only once the class files are changed (explicit build in IDEA).

With "continous compilation" we are talking about gradle -t bootRun? I never could this get to work properly - with or without this issue.

[atomfrede]

Thanks @abenneke for the PR. Exactly I was talking about -t. You have to use multiple terminals to make it work via cli:

• ./gradlew bootRun and
• ./gradlew compileJava -t in the second one.

[abenneke]

Ah, thank you for this insight! I always tried bootRun -t, which does not work as expected...

Well, I would suppose that it works - just because a restart is nicely triggered by bootRun on class file changes. But without synchronization between these two terminals I see A LOT OF ClassNotFoundExceptions in the bootRun part...

It however does not work in our project: Gradle runs into an endless loop with compileJava -t because of the openApiGenerate generation task compileJava is depending on. The flow is something like:

1. openApiGenerate
2. compileJava
3. detect new files just generated by openApiGenerate
4. start over

If you ask me, this could be a problem with openApiGenerate which seems to have no working change detection and is ALWAYS generating new output files... :-/

[pascalgrimaud]

Closing this as the PR has been merged

[kaidohallik]

Thanks @abenneke for reporting this. I noticed it too, but as I have no windows machine at hand its hard for me to test that ugly workaround. Could you do a PR and maybe check if continuous compilation and restart via bootDevTools work fine for you?

I tested in my Windows 10 and after this change continuous compilation and restart via bootDevTools started to work in command line in Windows, so #10458 fixed this issue too for me. Thanks @abenneke !

[atomfrede]

@kaidohallik Great to hear! Thanks @abenneke for fixing this.