Flow: Full Stack App with Spring dev mode packaged war doesn't work in tomcat

[alvarezguille]

When using platform snapshot and flow-maven-plugin snapshot the war resulting from running mvn package (without production mode) fails to deploy in tomcat.
More info in https://github.com/vaadin/bakery-app-starter-flow-spring/issues/824

[caalador]

This need investigation and decisions on what does it mean to run dev mode war.

1. webpack-dev-server can not build the bundles as there are missing files like package.json
2. user has their own webpack-dev-server running and dev-mode should point to that (documentation needed as the possibility at least has been in flow to do this)
3. We have the bundled files, but won't try to use them due to the fact that we are running in dev mode.

What is the advantage of running in dev mode instead of production mode?
How would the user know that creating a war will require productionMode?

[Legioth]

To further complicate things, there are differences between "war" and "war" as well. It might potentially still work when run as an exploded war from the project as happens e.g. when using mvn jetty:run-exploded or when running in Tomcat directly from Eclipse.

A completely standalone .war file would on the other hand not work since those files would then definitely be out-of-reach. I don't know if we have any good way of detecting the difference between those two modes.

Isn't this the reason why some files paths are written into flow-build-info.json? Would it be reasonable to say that a non-production war file only works when run on the same machine where the .war was built, and then only as long as the original files are still available? If the referenced file locations are not available, then we would print an error message that informs the user that they should most likely use a production .war instead.

[Artur-]

If you build a war file and deploy it, there is no reason to run any webpack server at all? If I deploy my demo to a local Tomcat to show to a customer later today, I certainly do not want it to be broken because I changed something in my workspace. There should be no connection between my workspace and my deployed version

[Legioth]

That would mean that any developer using a server for which there isn't any run-in-place Maven plugin or similar would not be able to benefit from the immediate reloading enabled by the webpack dev server.

A related question is whether we have any way of detecting whether the use is running from a .war (which is potentially exploded by the servlet engine) or not? Otherwise, there wouldn't be any good way of knowing whether to start a webpack dev server.

[Artur-]

Indeed, neither will they have Java hot deploy unless the explicitly request it through a debug connection, defined for the external server. Why would we hot deploy static files and use old versions of Java classes?

[Legioth]

Sure, but do we have any way of distinguishing between the situations where hot delpoy is available and not?

[pleku]

Until there is a resolution to this issue, this should explicitly be mentioned in the release notes as a known limitation, linking to this issue.

[caalador]

We could have the build-frontend goal add a conf "dev-server": false, into flow-build-info.json so that then if you do a package the dev-server wouldn't be used, but we would fall on the generated bundles.
This would mean also that the prepare-frontend goal should always remove this configuration so that when running mvn jetty:run we wouldn't be left without the dev-server even if we didn't clean.

[Legioth]

That would mean that any build that explicitly or implicitly uses mvn package would be in an intermediate development mode that does non-production logging and such, but still doesn't use the webpack dev server. I believe that would be a significant improvement over the current situation.

The one situation that would be slightly weird is still if you build a .war or otherwise deploy directly from e.g. Eclipse, since it would then pick a mode based on the last time you did run something through Maven. I think this would still be a relatively good trade-off.

[alvarezguille]

Can be reproduced using latest snapshots for flow and flow-maven-plugin

[caalador]

The latest was a issue with the spring add-on: https://github.com/vaadin/spring/issues/451
Please reopen a ticket with more details if the issue persists.