JHipster Development Platform

JHipster has transitioned from Yeoman's traditional priority notation to an unambiguous API to prevent accidental task queuing.

Traditional Notation (Deprecated/Avoid): Uses standard getters like get initializing(). Any method defined in the class that does not start with an underscore _ is automatically treated as a task and queued at default priority, which can lead to unexpected execution.

Unambiguous Notation (Current): Uses a constant for the getter name, where the constant value is prefixed with # (e.g., #initializing). This ensures that only methods explicitly returned within the priority getter are queued as tasks, while all other class methods remain ordinary members.

// TRADITIONAL (Avoid)
get initializing() {
  return {
    initializingTask() { this._sayHello(); }
  }
}

aTaskQueuedAtDefaultPriority() {
  // This is accidentally queued because it lacks a '_' prefix
}

// UNAMBIGUOUS (Recommended)
get [INITIALIZING_PRIORITY]() {
  return {
    initializingTask() { this.sayHello(); }
  }
}

anOrdinaryClassMember() {
  // This is NOT queued because the priority is defined via the # prefix constant
}

The JHipster Control Center acts as a web application that communicates with JHipster application instances through their management endpoints.

To improve security, it is recommended to expose these management endpoints on a dedicated management port (typically 9999) rather than the standard API port (e.g., 8080). This allows the management traffic to be isolated from the public-facing API traffic.

Architecture Flow:

1. The user accesses the Control Center via a browser (default port 1337).
2. The Control Center proxies requests to the JHipster applications.
3. The JHipster applications respond via their /management endpoints.

/---------\                         +---------------+
| Browser |                   :1337 | JHipster      |
\----+----/-------------+-----------> Control Center|
     |                  |           +----+----------+
     |                  |                | 
     |:8080             |:8081           | 
+----v-----+      +-----v----+           | 
| JHipster |      | JHipster |           | 
|   App 1  |      |  App 2   |           | 
+----------+      +----------+           | 
 :9999/management  :9999/management      | 
  ^                 ^                   | 
  |                 |                   | 
  +-----------------+--------------------+

Starting from version V8, JHipster follows an inclusive syntax pattern for managing properties in the generator and JDL. This means instead of using 'skip' or 'exclude' flags (exclusive syntax), you should use positive flags that define what to include or generate.

Rules for Inclusive Options:

1. Default Behavior: If an option is not explicitly defined by the user, the generator applies a reasonable default (e.g., if generateClient is not specified, it defaults to true).
2. User Specification: If an option is specified, the generator respects the user's explicit choice (e.g., setting generateClient: false will prevent the frontend from being generated).

Why this is used:

• Reduces cognitive overhead by avoiding double negation (e.g., if (!skipClient)).
• Simplifies business logic within the generator.
• Provides more expressive control over specific layers (e.g., using service * with serviceClass instead of ambiguous skip commands).