Skip to main content

Repository layout

installation/
├── DeepPhe-and-Launcher.install4j   # the install4j project (source of truth)
├── build-all.sh                     # build all platforms
├── build-mac-local.sh               # local Mac DMG build + run
├── sign-windows-assets.sh           # Authenticode-sign the Windows payloads
├── piperfiles/                      # pipeline overrides overlaid at install time
│   ├── DefaultDeepPhe.piper
│   ├── DefaultLimits.piper
│   ├── SmallJsonPrefs.piper
│   └── README.md
├── icons/                           # installer + launcher artwork
├── keys/                            # signing containers (git-ignored)
├── build/                           # generated installer output (git-ignored)
└── website/                         # this documentation site

What belongs in Git​

Commit:

  • install4j project files (*.install4j) after reviewing their diffs
  • README and repository metadata such as .gitignore / .gitattributes
  • icons and other small source assets used by the installer
  • the piperfiles/ overrides
  • this website/ documentation

Do not commit:

  • generated installer output (build/, old output/ dirs, *.dmg, *.exe, *.exe.zip)
  • downloaded/unpacked JDK or runtime bundles (jdk/, .jdk/)
  • install4j editor backups (*.install4j~) or scratch backups (save/)
  • local generated config and logs (viz.cfg, *.log, *.varfile)
  • signing certificates, private keys, keystores, or notarization credentials (keys/, old_keys/, *.p12, *.pfx, *.pem, *.key, …)

Signing and secrets​

Treat *.p12, *.pfx, *.jks, *.keystore, *.pem, and *.key as secrets — they can contain private signing keys even when password-protected, so they live outside Git history. Local machines keep active containers in keys/ and retired ones in old_keys/; both are git-ignored.

Not secrets by themselves: Apple IDs, publisher names, and public project URLs that appear in install4j files; the public .cer chain certificates in keys/certchain/.

Historical key references

The repo history contains references to DeepPhe.p12 / DeepPhe.pfx that were pushed to origin/main before the ignore rules existed. .gitignore stops new containers from being added, but does not remove files already in history. Whether to rotate those certificates and scrub history is a separate decision.

Line endings​

.gitattributes pins line endings so tools don't churn the files:

  • *.install4j → CRLF in the working copy (install4j writes CRLF), stored as a normalized LF blob. Whitespace checks may still flag trailing whitespace on generated project-file lines.
  • *.sh → LF, so the scripts run on macOS/Linux.

Build-machine paths inside the project​

DeepPhe-and-Launcher.install4j references some local absolute paths for payloads and signing files. These are build-machine configuration, not portable source. On a fresh clone, update them inside install4j (or make them relative) before building.