Docs

Docs

Configuration

Customizing a Hilla application configuration for both the development environment and for execution.

Configure the Endpoint Generator

To allow the endpoint generator to use the correct parameter names when building TypeScript files, you need to configure the Java compiler not to omit them by using the javac -parameters option. For example, the following shows how to configure the Maven plugin to include this compiler option:

Source code
pom.xml
<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.10.1</version>
            <configuration>
                <encoding>UTF-8</encoding>
                <parameters>true</parameters>
            </configuration>
        </plugin>
    </plugins>
</build>

Multi-Module Projects or External Dependency Endpoints

By default, Hilla searches only for endpoints in your application. You can extend the search, though, to other modules in your project, or even to dependencies, like the SSO Kit.

The Hilla Maven plugin can be configured to list the Java packages that contain the endpoints. That list should always include the main application package and can include other packages as needed.

If your application is in a package named com.example.application, and you have another module containing endpoints in com.example.module, and you want to use some third-party endpoints in com.acme.module, you can configure the plugin as follows:

Source code
XML
<plugin>
    <groupId>com.vaadin.hilla</groupId>
    <artifactId>hilla-maven-plugin</artifactId>
    <version>${hilla.version}</version>
    <!-- Add this configuration -->
    <configuration>
        <parser>
            <packages>
                <package>com.example.application</package>
                <package>com.example.module</package>
                <package>com.acme.module</package>
            </packages>
        </parser>
    </configuration>
    <!-- ... -->
</plugin>
Note
Endpoints & Spring Dependencies
If endpoints external to the main application have autowired Spring dependencies, make sure that Spring can find them. Otherwise, Hilla tries to instantiate them using a default no-arguments constructor, which won’t trigger dependency injection.

Explicit Endpoint Discovery

During code generation, Hilla discovers browser-callable classes — classes annotated with @BrowserCallable or @Endpoint — automatically. The discovery relies on detecting the Spring Boot application class on the module’s classpath. In some setups, such as multi-module projects where the application class resides in a different module, this auto-detection fails.

In these cases, you can configure endpoint discovery explicitly with the mainClass and sourceClasses plugin parameters. They are available on the prepare-frontend, build-frontend, and generate goals of the Hilla Maven plugin:

mainClass

The fully qualified name of the Spring Boot application class to use for discovering browser-callable classes.

sourceClasses

A list of fully qualified names of Spring configuration classes that declare the browser-callable beans. The classes are passed to the Spring AOT processor as --spring.main.sources, and are used when no Spring Boot application class is found on the classpath.

For example, to set the application class explicitly:

Source code
XML
<plugin>
    <groupId>com.vaadin.hilla</groupId>
    <artifactId>hilla-maven-plugin</artifactId>
    <version>${hilla.version}</version>
    <configuration>
        <mainClass>com.example.application.Application</mainClass>
    </configuration>
</plugin>

Alternatively, if there is no Spring Boot application class available, list the Spring configuration classes that declare the browser-callable beans:

Source code
XML
<plugin>
    <groupId>com.vaadin.hilla</groupId>
    <artifactId>hilla-maven-plugin</artifactId>
    <version>${hilla.version}</version>
    <configuration>
        <sourceClasses>
            <sourceClass>com.example.application.ApplicationConfiguration</sourceClass>
            <sourceClass>com.example.module.ModuleConfiguration</sourceClass>
        </sourceClasses>
    </configuration>
</plugin>
Note
 When either mainClass or sourceClasses is set, Hilla discovers browser-callable classes with the Spring AOT-based finder, and skips the default lookup-based auto-detection.

TypeScript Compiler Options

The TypeScript compiler requires a tsconfig.json file. If there is no tsconfig.json in the project root, the vaadin-maven-plugin generates one.

The default configuration looks similar to the following:

Source code
tsconfig.json
{
  "compilerOptions": {
    "sourceMap": true,
    "inlineSources": true,
    "module": "esNext",
    "target": "es2017",
    "moduleResolution": "node",
    "strict": true,
    "noFallthroughCasesInSwitch": true,
    "noImplicitReturns": true,
    "noImplicitAny": true,
    "noImplicitThis": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "experimentalDecorators": true,
    "baseUrl": "frontend",
    "paths": {
      "Frontend/*": [
        "*"
      ]
    }
  },
  "include": [
    "frontend/**/*.ts",
    "frontend/index.js",
    "types.d.ts"
  ],
  "exclude": []
}

Core & Pro Vaadin React Components

Vaadin React components include free core components and Pro (commercial) components. They’re shipped in separate npm packages: @vaadin/react-components, which contains only free components; and @vaadin/react-components-pro, which contains only commercial components. Vaadin adds both of these packages to package.json if the com.vaadin:vaadin artifact is used in the Java project configuration. By default, this is done in the Maven pom.xml.

Source code
pom.xml
<dependency>
	<groupId>com.vaadin</groupId>
	<artifactId>vaadin</artifactId>
</dependency>

If the com.vaadin:vaadin-core dependency is used, only the free @vaadin/react-components package is added:

Source code
pom.xml
<dependency>
	<groupId>com.vaadin</groupId>
	<artifactId>vaadin-core</artifactId>
</dependency>

Updated –