| layout | title | permalink | redirect_from | sitemap | |||||
|---|---|---|---|---|---|---|---|---|---|
default |
Creating an application |
/creating-an-app/ |
|
|
Please check our [video tutorial]({{ site.url }}/video-tutorial/) on creating a new JHipster application!
- Quick start
- Questions asked when generating an application
- Using a blueprint
- Command-line options
- Tips
First of all, create an empty directory in which you will create your application:
mkdir myapplication
Go to that directory:
cd myapplication/
To generate your application, type:
jhipster
Answer the questions asked by the generator to create an application tailored to your needs. Those options are described in the next section.
Once the application is generated, you can launch it using Maven (./mvnw on Linux/MacOS/Windows PowerShell, mvnw on Windows Cmd) or Gradle (./gradlew on Linux/MacOS/Windows PowerShell, gradlew on Windows Cmd).
Note if you are using Maven and changed front end files after first run of the ./mvnw command then you must run ./mvnw -Pwebapp to see the latest front end version (Gradle detects front end changes automatically and recompiles front end if needed).
The application will be available on http://localhost:8080
Important if you want to have "live reload" of your JavaScript/TypeScript code, you will need run npm start. You can go to the [Using JHipster in development]({{ site.url }}/development/) page for more information.
If you are using "live reload" then you can speed up server start up by excluding client side tasks by ./mvnw -P-webapp or ./gradlew -x webapp. It speeds up especially Gradle.
Some questions change depending on the previous choices you have made. For example, you won't need to configure an Hibernate cache if you didn't select an SQL database.
Your type of application depends on whether you wish to use a microservices architecture or not. A full explanation on microservices is [available here]({{ site.url }}/microservices-architecture/), if unsure use the default "Monolithic application".
You can either use:
- Monolithic application: this a classical, one-size-fits-all application. It's easier to use and develop, and is our recommended default.
- Microservice application: in a microservices architecture, this is one of the services.
- Microservice gateway: in a microservices architecture, this is an edge server that routes and secures requests.
This is the name of your application.
Your Java application will use this as its root package. This value is stored by Yeoman so that the next time you run the generator the last value will become default. You can override it by providing a new value.
Here are all the possible options:
- JWT authentication: use a JSON Web Token (JWT), which is the default choice and what most people use.
- OAuth 2.0 / OIDC Authentication: this uses an OpenID Connect server, like Keycloak, Auth0, or Okta, which handles authentication outside the application. This is more secured than JWT, but it requires to set up an OpenID Connect server, so it's a bit more complex. Please note that by default JHipster will synchronize the user data from the OpenID Connect server, and for this it will need a database.
- HTTP Session Authentication: the classical session-based authentication mechanism, which is what people usually do with Spring Security.
You can find more information on our [securing your application]({{ site.url }}/security/) page.
You can choose between:
- An SQL database (H2, MySQL, MariaDB, PostgreSQL, MSSQL, Oracle), which you will access with Spring Data JPA
- [MongoDB]({{ site.url }}/using-mongodb/)
- [Cassandra]({{ site.url }}/using-cassandra/)
- [Couchbase]({{ site.url }}/using-couchbase/)
- [Neo4j]({{ site.url }}/using-neo4j/)
- No database (only available when using a [microservice application]({{ site.url }}/microservices-architecture/) with JWT authentication)
This is the database you will use with your "production" profile. To configure it, please modify your src/main/resources/config/application-prod.yml file.
If you want to use Oracle, you might need to be aware of current limitations when [using Oracle database]({{ site.url }}/using-oracle/).
This is the database you will use with your "development" profile. You can either use:
- H2, running in-memory. This is the easiest way to use JHipster, but your data will be lost when you restart your server.
- H2, with its data stored on disk. This is a better option than running in-memory, as you won't lose your data upon application restart.
- The same database as the one you chose for production: it's a bit more complex to set up, but it should be better in the end to work on the same database as the one you will use in production. This is also the best way to use liquibase-hibernate as described in [the development guide]({{ site.url }}/development/).
To configure it, please modify your src/main/resources/config/application-dev.yml file.
The Spring cache abstraction allows to use different cache implementations: you can use ehcache (local cache), Caffeine (local cache), Hazelcast (distributed cache), Infinispan (distributed cache), Memcached (another distributed cache) or Redis (configured as a single server cache). This can have a very positive impact on your application's performance, and hence it is a recommended option.
This option will only be available if you selected to use an SQL database (as JHipster will use Spring Data JPA to access it) and selected a cache provider in the previous question.
Hibernate is the JPA provider used by JHipster, and it can use a cache provider to greatly improve its performance. As a result, we highly recommend you to use this option, and to tune your cache implementation according to your application's needs.
You can build your generated Java application either with Maven or Gradle. Maven is more stable and more mature. Gradle is more flexible, easier to extend, and more hype.
This is a multi-select answer, to add one or several other technologies to the application. Available technologies are:
This option lets you do [API-first development]({{ site.url }}/doing-api-first-development) for your application by integrating the Swagger-Codegen into the build.
Elasticsearch will be configured using Spring Data Elasticsearch. You can find more information on our [Elasticsearch guide]({{ site.url }}/using-elasticsearch/).
By default, JHipster uses a HTTP session only for storing Spring Security's authentication and authorisation information. You can choose to put more data in your HTTP sessions. Using HTTP sessions will cause issues if you are running in a cluster, especially if you don't use a load balancer with "sticky sessions". If you want to replicate your sessions inside your cluster, choose this option to have Hazelcast configured.
Websockets can be enabled using Spring Websocket. We also provide a complete sample to show you how to use the framework efficiently.
Use [Apache Kafka]({{ site.url }}/using-kafka/) as a publish/subscribe message broker.
Use [Apache Pulsar]({{ site.url }}/using-pulsar/) as a publish/subscribe message broker.
The client-side framework to use.
You can either use:
- Angular
- React
- Vue
The client theme to use.
You can use any themes from Bootswatch or keep the default one.
Sass a great solution to simplify designing CSS. To be used efficiently, you will need to run a Webpack dev server, which will be configured automatically.
By default JHipster provides excellent internationalization support, both on the client side and on the server side. However, internationalization adds a little overhead, and is a little bit more complex to manage, so you can choose not to install this feature.
Please note that JHipster covers only UI internationalization. For data internationalization, you will need to code it yourself in JPA/Hibernate layer.
By default JHipster provide Java unit/integration testing (using Spring's JUnit support) and JavaScript unit testing (using Jest). As an option, you can also add support for:
- Performance tests using Gatling
- Behaviour tests using Cucumber
- Angular integration tests with Protractor
You can find more information on our ["Running tests" guide]({{ site.url }}/running-tests/).
JHipster optionally creates incremental changelogs for you, so you don't need to recreate the database or to manually generate Liquibase diff.
Run JHipster using --incremental-changelog option anytime to enable it.
When executing JHipster, entities contain two states:
- The old state which is already saved to disk
- The new state, which is in the memory (generated from jdl or prompts)
A diff is generated between them and changelogs are created.
Supported features:
- Create/remove fields
- Create/remove relationships
- JDL and prompts
Doesn't support attribute changes like type and constraints.
Conflicts with:
--forkoption, since it saves to disk overriding the old state.
The [JHipster Marketplace]({{ site.url }}/modules/marketplace/) is where you can install additional modules, written by third-party developers, to add non-official features to your project.
JHipster 5 introduces the concept of a blueprint. Blueprints are JHipster modules that can provide custom client/server side templates that will override the ones from JHipster. For example, the Kotlin blueprint replaces most of the Java server side code with Kotlin.
For example, to use the Kotlin blueprint pass the name of the blueprint like below while generating an app.
jhipster --blueprint kotlinThe name of the blueprint is saved in the .yo-rc.json and will be automatically used while executing sub-generators like entity, spring-controller and spring-service.
If a blueprint doesn't implement a specific sub-generator, it will be skipped and the JHipster templates for the same sub-generator will be used.
Note: An application can use only one blueprint, multiple blueprints are not supported yet.
You can also run JHipster with some optional command-line options. Reference for those options can be found by typing jhipster app --help.
Here are the options you can pass:
--help- Print the generator's options and usage--blueprint- Specify a blueprint to use. For examplejhipster --blueprint kotlin--skip-cache- Do not remember prompt answers (Default: false)--skip-git- Do not add the generated project to Git automatically (Default: false)--skip-install- Do not automatically install dependencies (Default: false)--skip-client- Skip the client-side application generation, so you only have the Spring Boot back-end code generated (Default: false).--skip-server- Skip the server-side application generation, so you only have the front-end code generated (Default: false).--skip-user-management- Skip the user management generation, both on the back-end and on the front-end (Default: false)--i18n- Disable or enable i18n when skipping client side generation, has no effect otherwise (Default: true)--auth- Specify the authentication type when skipping server side generation, has no effect otherwise but mandatory when usingskip-server--db- Specify the database when skipping server side generation, has no effect otherwise but mandatory when usingskip-server--skip-checks- Skip the check of the required tools (Default: false)--jhi-prefix- Add prefix before services, components and state/route names (Default: jhi)--entity-suffix- Add suffix after entities class names (Default: empty string)--dto-suffix- Add suffix after DTOs class names (Default: DTO)--prettier-java- Use prettier-java for formatting all Java classes (Default: false)--experimental- Enable experimental features. Please note that these features may be unstable and may undergo breaking changes at any time--skip-fake-data- Skip generation of fake data for development--creation-timestamp- Set a timestamp for reproducible build. Timestamp should be a parsable js date ex: 2019-01-01. Must be used with --with-entities or import-jdl (generator-jhipster > 6.5.1)
You can also use the Yeoman command-line options, like --force to automatically overwrite existing files. So if you want to regenerate your whole application, including its entities, you can run jhipster --force.