Configuration
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:
<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:
<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.
|
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:
{
"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 commercial (i.e., professional) components. They’re shipped in separate npm packages: @vaadin/react-components
, which is only free; and @vaadin/react-components-pro
, which is only commercial. Vaadin adds both of these packages to package.json
if com.vaadin:vaadin
artifact is in the project’s configuration:
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin</artifactId>
</dependency>
It adds only @vaadin/react-components
if com.vaadin:vaadin-core
is used:
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-core</artifactId>
</dependency>