Vaadin 14 Plugins - under the hood
Both Maven and Gradle Vaadin Plugins do pretty much the same thing; they both have two goals/tasks:
Note: If you feel lost at any point, please read the Vaadin: the missing guide article first.
Important: that this article discusses the npm mode only: since the compatibility/bower mode is deprecated, we’re not going to discuss that anymore.
The prepare-frontend goal/task does the following things (you can follow the text below and look into the sources of the Vaadin Gradle Plugin prepare-frontend task implementation if you’d like):
First, the plugin will prepare the very important
flow-build-info.json file into
the classpath, into the
build/ folder (depends on whether you use Maven or Gradle).
By placing it into the
target/ folder, the file will then later on be packaged
correctly into the target artifact, be it WAR, EAR or SpringBoot jar. This way
it is also visible to Vaadin when launching Vaadin with embedded Jetty.
Important: Since the
flow-build-info.jsonfile is removed when running the
cleantask, it’s really good to remember to run the
prepare-frontendtask after the
The next step is for the Vaadin Plugin to validate that the npm and node.js is of acceptable
version, and will warn or fail if either one is too old. If either of the npm or node.js is missing,
Vaadin plugin will automatically download both, into the
Afterwards, Vaadin plugin will generate the necessary npm and webpack configuration files:
package.json. Note that the
package-lock files are not generated at this point:
they will be generated later on:
- In development mode: Vaadin Servlet will run npm and webpack automatically, before the app is started, to populate those folders.
- In production mode, you run
prepare-frontend finishes, you’re all set to run the Vaadin application
in the development mode.
build-frontend builds on the outcome of the
prepare-frontend task, and thus
it requires the
prepare-frontend task to be run beforehand.
Note: The Gradle Vaadin Plugin configures Gradle to handle this automatically, so if you run
vaadinPrepareFrontendtask is going to be run, too.
You can again follow the Vaadin Gradle plugin build-frontend task implementation.
flow-build-info.json file is modified. Since we are targeting production mode here,
the Vaadin Servlet will no longer start embedded webpack and will serve precompiled
enableDevServer to false and remove
all npm-related settings like
We can also remove
files were produced. Also we remove
require.home.node since in production mode
we do not need
files will be produced by the Plugin and packaged into the WAR/EAR/JAR archive.
Next, we will run
npm install to make sure all packages are available in
in plugin’s sources).
webpack is run, to package everything from
If this task succeeds, it should produce the following outputs:
package-lockin the project root folder;
META-INF/VAADIN/config/flow-build-info.jsonfile into the folder where generated resources go;
META-INF/VAADIN/config/stats.jsoninto the folder where generated resources go;
The placement of generated resources depends on whether the project is built by
Maven (then the folder is somewhere in
target/classes/) or Gradle (then it’s in
It is now the job of the packaging plugin (WAR/EAR/JAR) to package those files
and folders properly, so that Vaadin can use ClassLoader to load those files as
resources from the classpath. For example:
- When building JAR without Spring Boot (see vaadin14-embedded-jetty example project), those folders are simply located in the root of the jar file;
- When building WAR (see e.g. skeleton-starter)
then the folders are located in
- When building JAR+Spring Boot (e.g. skeleton-starter-flow-spring, those folders are located in
BOOT-INF/classes/in the Spring Boot jar file.
Please see Vaadin: the missing guide on the example contents of those files and folders.
What to read next
See the Vaadin: Troubleshooting guide when something goes wrong.