- • Quickstart
- › Documentation
- • Documentation DevOps
- • Spring Data
- • Spring Data MongoDB
- • Spring REST
- • Frontend
- • Multi-Module
- • IntelliJ Integration
Last updated: 2022-09-23
General tab - backgrounds
The General tab is displayed first when a project is newly started or reopened. Basic settings for the project can be configured here, while the database schema can be created in the next tab.
Changes in the General tab are immediately synchronized with the server in the background. If the project is edited by a team member at the same time, the Bootify Builder will show a synchronization error if there is a conflict. In this case the page has to be refreshed first to load the current state.
Project settings area
Adjusting the Project settings
In the first section your project group and name can be defined. These are used as metadata for the project and are stored in the corresponding build file. In addition, the project group is used as a base package for the generated application.
Maven and Gradle are available as build types - the corresponding wrappers as well as the
build.gradle file will be provided. If Kotlin is selected as the language,
build.gradle.kts (Kotlin Script) is generated instead. Also, the required libraries and extensions for supporting Kotlin are included.
Lombok is available as an option for the Java language. With this, the necessary setup is added and less source code will be generated in the relevant places - the appropriate annotations are used instead (e.g.
@Setter for the entity classes). To use Lombok during development, the corresponding function must be enabled in the IDE - the IntelliJ setup is explained here.
As the last option a frontend stack can be selected. Backgrounds are explained on this page.
Database settings area
In this section you can first choose the database you want to use. For a relational or embedded database Bootify will always include
spring-boot-starter-data-jpa and the relevant JDBC driver as dependencies. In addition, the
spring.datasource... settings are provided in the
application.properties - after downloading the source code, the password usually has to be adjusted first before starting the application. This allows the application to connect directly to the selected database at startup.
If MongoDB was chosen as a document-oriented database,
spring-boot-starter-data-mongodb is included as a dependency - no further driver is necessary. Instead of using JPA / Hibernate, the documents are created using
@DocumentReference. More background on this can be found in the MongoDB section.
If None is selected as a database, all references to Spring Data / Hibernate are removed. Selecting Other will include a dependency on
other.database:jdbcDriver in the build file - so this must be replaced with the actual JDBC driver after download.
For schema generation, None (validate only) and Hibernate (update) are available in the Free plan. If None is selected, Hibernate will compare the existing database schema with the given entity classes at application startup and abort with an exception if there are differences. So here it is expected that the schema already exists in the desired form. With the option Update, Hibernate will recreate or update the database schema to the current state at application startup - beware, this migration does not always work reliably and is not recommended for production use!
Flyway and Liquibase are available as options in the Professional plan. More explanations on the different approaches are available here. For MongoDB, Mongock is available as an option to initialize the collections including a JSON schema.
By activating the last checkbox,
lastUpdated fields can be added to each entity. These are automatically populated by an EventListener at the first persist (
dateCreated) and at the last update (
lastUpdated). For this purpose the
DomainConfig class is extended with the necessary setup to enable auditing.
Developer preferences area
Choice of other preferences for the generated code
In this section further preferences for the generated code can be selected. The application properties can be stored either in an
application.properties - both formats are automatically picked up by Spring Boot. When the package structure is changed to domain driven, the classes are grouped by their respective entities - e.g. a package
car_part is created containing the service, controller, dto, etc. of this entity. Otherwise, the grouping is done according to technical criteria - with packages rest, service, repos, and so on containing all classes of the respective type.
If Swagger UI is enabled for the project, it will be accessible at http://localhost:8080/swagger-ui.html after the application has been launched. For this, Bootify adds the
springdoc-openapi-ui dependency as well as the
pathsToMatch property. Depending on the other setup of the project, the configuration may be further refined - for example, the first method of the
RestControllerAdvice gets the annotation
@ApiResponse(responseCode = "4xx/5xx", description = "Error") to provide general error responses. Security and pagination are reflected as well.
As Java version you can choose between the three Long-Term-Support versions 8, 11 and 17. The selection will lead to an adjustment of the build file - there are currently no further effects, since the new language features are not yet relevant for the generated code. Java 17 is strongly recommended as this is the required version for the upcoming Spring Boot 3.0 release.
Bootify automatically prepares all dependencies so that the application can be directly started after download. In the last input field additional dependencies can be added, which will be included in the build file.
In the Professional plan, the Advanced settings area is also visible. The available options are explained in the next article.
No registration required