In this blog, we'll show you how to minimize dependencies in Vaadin add-ons, use Spring Boot for easy development and testing, and set up a clean Maven project for compatibility with various tech stacks.
It's crucial to keep the number of transitive dependencies in your add-ons to a minimum. This approach ensures that your add-ons are compatible with various stacks and reduces the likelihood of version conflicts in actual applications. For instance, avoid adding direct dependencies on libraries like Spring unless your add-on specifically requires them for a particular functionality.
But even if you are unfamiliar with the Spring ecosystem, my recommendation today is to use the Spring Boot-based project setup to develop and test your Vaadin add-ons. This doesn’t mean your add-on pulls in Spring dependencies when used in actual applications. Still, you can utilize the sleek development environment and other helpful libraries when testing your add-on.
Here are some benefits compared to using the “official add-on project starter” (which uses Jetty-based tooling):
- Faster startup: While the exact reason is unclear, Spring Boot projects tend to start quicker.
- Simplified debugging: Instead of configuring IDE server integrations or Maven plugins, you can simply hit the play button on the
TestServerclass's main method. - Efficient live reload: Vaadin’s development mode tooling works best with Spring Boot. If you're not using JRebel or HotSwap Agent,
spring-boot-devtoolshelps you iterate faster during development.
- Useful for testing: While it's best to avoid dependency injection (DI) frameworks in your add-ons, they can be very handy when testing. The Spring ecosystem also provides powerful testing tools that are easily accessible when you base your add-on project on Spring Boot.
How to set up Vaadin add-ons using a custom parent project
Some might initially assume that a Spring Boot project setup works fine for libraries, as they are "just JAR files." However, the "fat-jar" created by a typical Spring Boot project is not suitable when building libraries. Additionally, Spring dependencies, which are typically needed at the compile scope for web projects, should be placed in the test scope for Vaadin add-ons (or other libraries). Therefore, do not use spring-boot-starter-parent as the project parent for your add-on!
In some of my earlier projects, I hand-crafted the entire build process. However, inspired by other parent projects I've created, I now have a more streamlined and effective parent project for add-ons. By using this parent project, your add-on's build file remains clean and minimal, allowing you to focus on writing actual code.
Key features of the current project parent include:
- Defines generic Java project settings such as UTF-8 encoding and sets the Java version to 17, which is the minimum required for the current version of Vaadin.
- This configuration brings in the
vaadin-coredependency in the provided scope, ensuring that no Spring dependencies or Viritin components are included in your add-on. You can also override the Vaadin version by setting thevaadin.versionproperty in your project. - Brings in a bigger set of dependencies from Vaadin and Spring Boot to test scope, so you can utilize them when building test UIs and automated tests.
- Configures the Maven Flatten plugin so that the generated/published
pom.xmllooks as clean as possible. For example, references to this parent project or any other “build-related details” will not be present when the project is pushed to the Maven Central or Vaadin Directory.
The easiest way to get started is by generating a project stub with a Maven archetype. This will create a basic project with a simple “Hello World” add-on and an example setup for testing and development, including a test UI accessible via a browser, unit tests, and an end-to-end test using Playwright/Mopo. You can either provide the archetype coordinatesin.virit:viritin-vaadin-addon-archetype:2.0.1 (or the latest version) through your favorite IDE, or run the following command in the CLI:
mvn archetype:generate -DarchetypeArtifactId=viritin-vaadin-addon-archetype -DarchetypeGroupId=in.virit
Open the generated project with your IDE, and you will be ready to start crafting the add-on.
Note that the parent project (at least for now) doesn’t include “directory packaging” by default. If you plan to publish your add-on primarily through Vaadin Directory, you’ll need to manually add those configurations to your own pom.xml. While this could potentially be added as a feature to the parent project, I personally prefer publishing via Maven Central for several reasons, while simply listing the add-on in the Directory.
Preparing a project without an archetype
If you prefer doing it manually, you can get started by adding the following Maven snippet to the beginning of your pom.xml:
<parent>
<groupId>in.virit.sb</groupId>
<artifactId>viritin-addon-project-parent</artifactId>
<version>0.0.5</version>
</parent>
In existing projects, you can remove unnecessary dependencies and plugin configurations. However, one essential addition is a @SpringBootApplication annotated class with a main method to launch a development server for your test UIs. This class should be placed in the test sources, as the relevant dependencies won’t be available in the compile scope. Additionally, you’ll want to exclude the test server class from your add-on artifact.
@SpringBootApplication
public class TestServer {
public static void main(String[] args) {
SpringApplication.run(TestServer.class, args);
}
}
When writing this post, I dropped it to one older add-on, so you can pretty easily see how to get started with it. In addition to the above, I tend to also configure my add-on projects to start the development server to a special port (9998). This allows me to run the add-on test server easily at the same time as some actual web project is running on the 8080 port. Check out the full change-set from Github.
For those looking to build everything from the ground up, it’s worth checking out how the viritin-addon-project-parent is built.
If you have some enhancement ideas or bugs to report, feel free to post them for the viritin-sb project. That project also contains project parents for normal web apps that are more “cloud native” than the default Vaadin project stubs. Don’t hesitate to try them as well!