skip to content

How does applicationName affect installDist, and how do you change the name of the install directory and the launcher executables?

level: middleimportance: should knowfreq 35%

answer

  1. application { applicationName }
  2. defaults to project name
  3. names dir + both scripts
  4. <APP>_OPTS derives from it
  5. set once, propagates

basics

~10 s

applicationName (set in the application { } block) drives the install folder name (build/install/<applicationName>/) and the base names of the generated scripts (bin/<applicationName> and bin/<applicationName>.bat). It defaults to the project name.

solid answer

~40 s

`application.applicationName` is the single property that names your distribution. By default it equals the project name, but you set it explicitly when the project name isn't a good CLI command. Changing it affects three things at once: the `installDist` output directory becomes `build/install/<applicationName>/`, the POSIX launcher becomes `bin/<applicationName>`, and the Windows launcher becomes `bin/<applicationName>.bat`. It also influences the per-app env var the script reads (`<APP_NAME>_OPTS`, derived from the upper-cased name). Set it in the `application { }` extension; the value propagates to the `startScripts` (`CreateStartScripts`) task and the distribution tasks. Because the name is a single source of truth, you avoid having a mismatched folder name and command name.

code

kotlin · 7 lines
kotlin
application {
    applicationName = "payments"
    mainClass.set("com.acme.payments.Main")
}
// ./gradlew installDist ->
//   build/install/payments/bin/payments
//   build/install/payments/bin/payments.bat

go deeper

for a junior

Know applicationName sets the install folder and launcher names and defaults to the project name.

for a middle

Explain it's a single source of truth feeding the install dir, both scripts, and the <APP>_OPTS env var, set in application { }.

for a senior

Discuss when to override on the startScripts task vs the extension, and how the shared name keeps archive/install/command consistent.

for a principal

Establish naming conventions across many service repos so command names and env-var contracts are predictable for operators.

## What applicationName controls The Application plugin exposes `applicationName` on its `application { }` extension. It is the **canonical name** of your runnable distribution and feeds several outputs: 1. **Install directory** — `installDist` writes to `build/install/<applicationName>/`. 2. **Launcher file names** — the start scripts are `bin/<applicationName>` and `bin/<applicationName>.bat`. 3. **Per-app JVM-options env var** — the generated script reads `<UPPERCASED_NAME>_OPTS` (e.g. `MYAPP_OPTS`), so the name also defines that contract. 4. **Distribution archives** — `distZip`/`distTar` base their archive base name on it too (sibling topic, but worth knowing the name is shared). ## Default value If you set nothing, `applicationName` defaults to the **project name** (the directory/`rootProject.name`). That's fine when the project name is a sensible command, but often it isn't (e.g., `payments-service-cli` → you want the command `payments`). ## How to set it ```kotlin plugins { application } application { applicationName = "payments" mainClass.set("com.acme.payments.Main") } ``` After this, `./gradlew installDist` produces: ``` build/install/payments/ ├── bin/payments ├── bin/payments.bat └── lib/... ``` ## Overriding only on the task The value propagates to the `startScripts` task, but you *can* override there if you ever need the script name to differ from the install dir name: ```kotlin tasks.named<CreateStartScripts>("startScripts") { applicationName = "pay" // bin/pay, bin/pay.bat } ``` This is rarely needed — keeping one `applicationName` in the extension is the clean approach. ## Why interviewers ask It tests whether you understand that the *folder name*, the *command name*, and the *env-var contract* all derive from one property — a common source of confusion when someone's install dir says one thing but the executable is named another.

  • What is the default value of applicationName?
    The project name; you override it in the application { } block when the project name isn't a good command name.
  • Does applicationName also affect the env var for JVM options?
    Yes — the per-app options var is the upper-cased applicationName plus _OPTS, e.g. PAYMENTS_OPTS.

saying these in an interview costs you the question

  • Thinking you must rename the project directory to change the command name — applicationName does it independently.
  • Assuming the script name and install-dir name can't be the same property — they both come from applicationName.

context

resolving links…