Vaadin 14 / Eclipse / Gradle: Missing pieces?

I’m migrating a six year old Vaadin 8 project to Vaadin 14 by re-writing it from scratch. I’m trying to use Gradle as part of the upgrade and have followed the [documenation]
( and [Vaadin Gradle Plugin]
(, starting from the Basic WAR project.

It partially works, but I must be missing something important because there is a lot of unexpected behavior:

  1. Despite Vaadin claiming to install node.js, Eclipse throws up a dialog at each restart “Could not find node.js”. But a node_modules folder exists in the project path. Is it a false message or do I need to modify a PATH variable or something?

  2. node_modules/lit-element/ts3.4/tsconfig.json contains an error. Removing the comment in the middle of the JSON file solves that error.

  3. Selecting Gradle task gretty/appStart, the project loads and works in the browser. For one or two tries, saving code changes in Eclipse and refreshing the browser results in updated results. Nice. But around save #3 gives an NPE in gretty unrelated to my code (Runner.groovy:41). The number of java instances in my development machine increases, and the CPU becomes heavily loaded. The next save brings a “Connection Refused” message from JettyScannerManager. At this stage the Gradle task appStop fails and the only solution (that I have found so far) is to restart Eclipse and manually quit four or five Java instances.

  4. I want to use Tomcat installed in my local machine instead of gretty. Previously this had been enabled by adding a server, adding the project and pressing start. That doesn’t work now. Tomcat can’t find the project in the place it’s looking with an error: Caused by: java.lang.IllegalArgumentException: The main resource set specified [/Users/stevedemy/EclipseMay2020/V14-workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/fleetcaptain] is not valid. Sure enough, my project is not there. How can I make Eclipse/Servers/Add_and_Remove put the resources in a place that Tomcat will find when it starts? Or make Tomcat look in the right place?

  5. No debug. Gradle task gretty appStartDebug gets to “> Task :appStartDebug” then makes no further progress. Browser doesn’t find webapp.

The “missing pieces” are probably between my ears, as I have little experience with build systems. I’ve run out of instructions, so if anyone can provide some clues I will be grateful. I’m looking forward to continuing the discovery of the fascinating new capabilities of Vaadin 14 but it’s slow when the development workflow involves restarting Eclipse every few minutes.

I’ve made some adaptation to the build.gradle file deleting the webjars because I’m not migrating from Vaadin 13. Have I messed something up here?

plugins {
    id 'war'
    id 'org.gretty' version '3.0.3'
    id 'com.vaadin' version '0.8.0'

war {

defaultTasks("clean", "build")

repositories {

gretty {
    contextPath = "fleetcaptain"
    servletContainer = "jetty9.4"

// example of how to configure the Gradle Vaadin Plugin
vaadin {
    productionMode = false
    pnpmEnable = true

dependencies {
    implementation enforcedPlatform('com.vaadin:vaadin-bom:14.3.0')

    // Vaadin 14
    implementation("com.vaadin:vaadin-core") {
//         Webjars are only needed when running in Vaadin 13 compatibility mode
//        ["com.vaadin.webjar", "org.webjars.bowergithub.insites",
//         "org.webjars.bowergithub.polymer", "org.webjars.bowergithub.polymerelements",
//         "org.webjars.bowergithub.vaadin", "org.webjars.bowergithub.webcomponents"]
//                .forEach { group -> exclude(group: group) }
    providedCompile "javax.servlet:javax.servlet-api:3.1.0"

    // logging
    // currently we are logging through the SLF4J API to SLF4J-Simple. See src/main/resources/ file for the logger configuration
    implementation "org.slf4j:slf4j-simple:1.7.30"

Environment: Vaadin 14.3.0, plugin 0.8.0, Eclipse 2020-06 (4.16.0), Vaadin plugin for Eclipse 4.1.6, OpenJDK 14.0.1, Gradle 6.5.1

The solution to getting Eclipse working with Tomcat was to set up “Project Facets”. With that the project runs as expected using Tomcat, one instance of java, low CPU utilization and debug working as expected. I don’t know why the Gretty servlet container is not working, but with Tomcat it’s all good and mirrors the production environment.