Creating an application

Please check our video tutorial on creating a new JHipster application!

Generating an application quickly

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:

yo jhipster

And answer the questions asked by the generator to create an application taylored to your needs. Those options are described in the next section.

Once the application is generated, you can launch the Java server within your IDE, by running the Application class at the root of your application's Java package.

As it is a simple "Main" class, it is the easiest and quickest way to run and debug the application.

If you prefer to use Maven, you can also run your application by typing:

mvn

(this will run our default Maven task, spring-boot:run)

If you prefer to use Gradle, you can also run your application by typing:

gradlew

(this will run our default Gradle task, bootRun)

The application will be available on http://localhost:8080

Options available when generating an application

What is the base name of your application?

This is the name of your application.

What is your default Java package name?

Your Java application will use this as its root package.

Which *type* of authentication would you like to use?

You can either use:

  • A classical session-based authentication mechanism, like we are used to do in Java (this is how most people use Spring Security). You can use this option with Spring Social, which will enable you to use "social login" (such as Google, Facebook, Twitter): this is configured by Spring Boot's support of Spring Social.
  • An OAuth 2.0 authentication mechanism (JHipster then provides the necessary OAuth2 server code and database tables).
  • A token-based approach (similar to OAuth 2.0, but uses a custom token system that does not require database tables).
The OAuth 2.0 and the token approaches allow to use a stateless application architecture (they do not rely on the HTTP Session). You can find more information on our securing your application page.

Which *type* of database would you like to use?

You can choose between a classical SQL database, which you will access with Spring Data JPA, or a NoSQL approach with MongoDB or Cassandra.

Which *production* database would you like to use?

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 will need to install the Oracle JDBC driver manually.

Which *development* database would you like to use?

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 currently in BETA test (and not working on Windows), but this would eventually be 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.
To configure it, please modify your src/main/resources/config/application-dev.yml file.

Do you want to use Hibernate 2nd level cache?

Hibernate is the JPA provider used by JHipster. For performance reasons, we highly recommend you to use a cache, and to tune it according to your application's needs.
If you choose to do so, you can use either ehcache (local cache) or Hazelcast (distributed cache, for use in a clustered environnement)

Do you want to use a search engine in your application?

Elasticsearch will be configured using Spring Data Elasticsearch. You can find more information on our Elasticsearch guide.

Do you want to use clustered HTTP sessions?

By default, JHipster uses a HTTP session only for storing Spring Security's authentication and autorisations information. Of course, 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.

Do you want to use WebSockets?

Websockets can be enabled using Spring Websocket. We also provide a complete sample to show you how to use the framework efficiently.

Would you like to use Maven or Gradle?

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.

Would you like to use Grunt or Gulp.js for building the frontend?

Grunt is the most widely used and most mature build tool for your JavaScript and CSS assets. Gulp.js is a more recent alternative, which is easier to use and learn.

Would you like to use the LibSass stylesheet preprocessor for your CSS?

Node-sass a great solution to simplify designing CSS. To be used efficiently, you will need to run a Grunt or Gulp server, which will be configured automatically.

Would you like to enable translation support with Angular Translate?

By default JHipster provides excellent internationalization support, both on the client side with Angular Translate 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.

Which testing frameworks would you like to use?

By default JHipster provide Java unit/integration testing (using Spring's JUnit support) and JavaScript unit testing (using Karma.js). As an option, you can also add support for:

  • Performance tests using Gatling
  • Behaviour tests using Cucumber
You can find more information on our "Running tests" guide.