Generator-jhipster: Building prod JAR with mvn runs webpack:dev in the process

[ruddell]

Overview of the issue

When running the documented command to build a prod JAR file, webpack:dev runs before webpack:prod. The webpack:prod build clears the static build folder, so the webpack:dev build is useless and wastes time.

Affects Maven only, I do not see dev logs in a Gradle prod build

Running with -Pprod,-webpack works and saves 100 seconds in my CI. Local times:

time ./mvnw -Pprod clean verify -DskipTests
191.24s user 14.78s system 240% cpu 1:25.67 total

``` time ./mvnw -Pprod,-webpack clean verify -DskipTests 99.90s user 7.30s system 184% cpu 57.988 total ``` ##### **Motivation for or Use Case** Building for prod should not run a dev step. ##### **Reproduce the error** Generate an app and run: - `./mvnw -Pprod clean verify -DskipTests` You will see in the logs that `npm run webpack:dev` runs during the build process

Prod Build Logs

[INFO] --- frontend-maven-plugin:1.8.0:npm (webpack build dev) @ mono ---
[INFO] npm not inheriting proxy config from Maven
[INFO] Running 'npm run webpack:build' in /private/tmp/jh/oldv6test
[INFO] 
[INFO] > [email protected] webpack:build /private/tmp/jh/oldv6test
[INFO] > npm run cleanup && npm run webpack:build:main
[INFO] 
[INFO] 
[INFO] > [email protected] cleanup /private/tmp/jh/oldv6test
[INFO] > rimraf target/classes/static/ target/classes/aot
[INFO] 
[INFO] 
[INFO] > [email protected] webpack:build:main /private/tmp/jh/oldv6test
[INFO] > npm run webpack -- --config webpack/webpack.dev.js --env.stats=minimal
[INFO] 
[INFO] 
[INFO] > [email protected] webpack /private/tmp/jh/oldv6test
[INFO] > node --max_old_space_size=4096 node_modules/webpack/bin/webpack.js "--config" "webpack/webpack.dev.js" "--env.stats=minimal"
[INFO] 
[INFO] Webpack: Starting ...
[INFO] Starting type checking service...
Webpack: Starting ...
[INFO] 
[INFO]    ✔ Compile modules
[INFO]    ✔ Build modules
[INFO]    ✔ Optimize modules
[INFO]    ✔ Emit files
[INFO] 
[INFO] Webpack: Finished after 32.233 seconds.
[INFO] 
[INFO]  DONE  Compiled successfully in 32249ms1:57:04 PM
[INFO] 
[INFO]    588 modules
[INFO] 
[INFO] --- frontend-maven-plugin:1.8.0:npm (webpack build prod) @ mono ---
[INFO] npm not inheriting proxy config from Maven
[INFO] Running 'npm run webpack:prod' in /private/tmp/jh/oldv6test
[INFO] 
[INFO] > [email protected] webpack:prod /private/tmp/jh/oldv6test
[INFO] > npm run cleanup && npm run webpack:prod:main && npm run clean-www
[INFO] 
[INFO] 
[INFO] > [email protected] cleanup /private/tmp/jh/oldv6test
[INFO] > rimraf target/classes/static/ target/classes/aot
[INFO] 
[INFO] 
[INFO] > [email protected] webpack:prod:main /private/tmp/jh/oldv6test
[INFO] > npm run webpack -- --config webpack/webpack.prod.js --profile
[INFO] 
[INFO] 
[INFO] > [email protected] webpack /private/tmp/jh/oldv6test
[INFO] > node --max_old_space_size=4096 node_modules/webpack/bin/webpack.js "--config" "webpack/webpack.prod.js" "--profile"

Suggest a Fix

Have not had time to look into it other than the workaround above (excluding webpack profile with -Pprod,-webpack)

JHipster Version(s)

Master, tested v6.5.0+

JHipster configuration

.yo-rc.json file

{
  "generator-jhipster": {
    "promptValues": {
      "packageName": "com.mycompany.myapp",
      "nativeLanguage": "en"
    },
    "jhipsterVersion": "6.6.0",
    "applicationType": "monolith",
    "baseName": "reproduction",
    "packageName": "com.mycompany.myapp",
    "packageFolder": "com/mycompany/myapp",
    "serverPort": "8080",
    "authenticationType": "jwt",
    "cacheProvider": "ehcache",
    "enableHibernateCache": true,
    "websocket": false,
    "databaseType": "sql",
    "devDatabaseType": "h2Disk",
    "prodDatabaseType": "mysql",
    "searchEngine": false,
    "messageBroker": false,
    "serviceDiscoveryType": false,
    "buildTool": "maven",
    "enableSwaggerCodegen": false,
    "jwtSecretKey": "bXktc2VjcmV0LXRva2VuLXRvLWNoYW5nZS1pbi1wcm9kdWN0aW9uLWFuZC10by1rZWVwLWluLWEtc2VjdXJlLXBsYWNl",
    "embeddableLaunchScript": false,
    "useSass": true,
    "clientPackageManager": "npm",
    "clientFramework": "angularX",
    "clientTheme": "none",
    "clientThemeVariant": "",
    "creationTimestamp": 1580062230993,
    "testFrameworks": [],
    "jhiPrefix": "jhi",
    "entitySuffix": "",
    "dtoSuffix": "DTO",
    "otherModules": [],
    "enableTranslation": true,
    "nativeLanguage": "en",
    "languages": ["en"],
    "blueprints": []
  }
}

Browsers and Operating System

Affect all OSs

• [X] Checking this box is mandatory (this is just to show you read everything)

[vishal423]

It's an interesting issue and has also seen it before.

I consider the current approach (to check for the existence of a file) as a deviation from reproducible builds. As an example, if you have built the front-end code and later did some UI changes, you wouldn't be able to view those unless you cleanup the target directory/specific file before the next start or you start a separate front end dev server to sync the UI. It's not an issue with users familiar with the limitation, however, often for new users, it causes unnecessary debugging to understand the flow.

I think to replace the conditional activation with default activation (similar to the dev profile). It solves both the issues -- reproducible development builds and avoids execution of the webpack profile in production builds.

[PierreBesson]

I consider the current approach (to check for the existence of a file) as a deviation from reproducible builds. As an example, if you have built the front-end code and later did some UI changes, you wouldn't be able to view those unless you cleanup the target directory/specific file before the next start or you start a separate front end dev server to sync the UI. It's not an issue with users familiar with the limitation, however, often for new users, it causes unnecessary debugging to understand the flow.

Yes, it is a deviation from reproducible builds but this was done for the dev build to work out of the box and trigger the webpack build if needed (and see the frontend on localhost:8080).
I can totally see how it can confuse users in more advanced cases but I don't think that we need a "reproducible build" in dev mode, because, when using with hot-reloading, it will never be reproducible...
If it can be replaced with "default activation", then it would be even better but at the time the only way I found to make it work "out of the box" with maven was thanks to "file activation". Maven has definitely more limitations than Gradle in this area of build customization.