install4j의 새로운 소식

기본적으로 캐시는 사용자별 캐시 디렉터리에 저장됩니다. Linux 및 Unix에서는 $XDG_CACHE_HOME/install4j/aot 또는 ~/.cache/install4j/aot, macOS에서는 ~/Library/Caches/install4j/aot, Windows에서는 %LOCALAPPDATA%\install4j\aot입니다. 런처 마법사에서 사용자 지정 기본 경로를 구성할 수 있습니다. 캐시 파일 이름에는 애플리케이션 빌드와 Java 런타임에서 파생된 키가 포함되므로, 애플리케이션 업데이트 및 Java 런타임 변경 후에는 캐시가 자동으로 재생성됩니다. 이전 빌드의 캐시는 자동으로 정리되며, 언인스톨러가 해당 설치의 캐시를 제거합니다.

install4j IDE 자체도 AOT 캐시를 사용하며, 이제 두 배 이상 빠르게 시작됩니다.

네 가지 액션이 제공됩니다:

• "Read value from a YAML file" 액션은 경로에 해당하는 값을 읽어 인스톨러 변수에 저장합니다. 스칼라 값은 YAML 타입을 그대로 유지하며, 매핑은 옵션에 따라 최상위 항목마다 하나의 인스톨러 변수로 분해할 수 있으므로 YAML 파일의 한 섹션만으로 구성 폼을 손쉽게 초기화할 수 있습니다.
• "Count entries in a YAML file" 액션은 리스트 또는 매핑의 항목 수를 계산하고 그 결과를 인스톨러 변수에 저장합니다.
• "Modify YAML files" 액션은 하나 이상의 YAML 파일에서 경로로 지정된 위치의 값을 변경, 삽입 또는 제거합니다. 편집은 텍스트 수준에서 수행되므로 주석과 서식이 유지됩니다. 읽기 액션에서 분해된 변수와 읽기 액션의 "Overlay installer variables" 옵션과 함께 사용하면 스크립트 없이도 완전한 읽기-수정-쓰기 주기를 구현할 수 있습니다.
• "Write YAML file" 액션은 YAML 파일에 값을 기록하며, 파일을 생성하거나 기존 파일을 덮어씁니다.

모든 액션은 공통의 경로 문법으로 노드를 지정합니다. $.key는 매핑 키를, $['key']는 마침표나 특수 문자가 포함된 키를, $[0]는 리스트 인덱스를 지정합니다. 세그먼트는 조합할 수 있습니다. 예를 들어 $.servers[0].host와 같습니다. 여러 YAML 문서가 포함된 파일은 문서 인덱스를 통해 지원됩니다.

SBOM 생성은 "General Settings->Media File Options" 단계에서 구성됩니다. 다음 두 가지 독립적인 출력을 사용할 수 있습니다:

• 외부 SBOM은 각 미디어 파일 옆에 JSON 및 XML 형식으로 기록됩니다. 미디어 파일 이름이 myapp_windows-x64_1_0.exe인 경우 myapp_windows-x64_1_0.exe.install4j_runtime.cdx.json 및 myapp_windows-x64_1_0.exe.install4j_runtime.cdx.xml 파일이 생성되므로, 릴리스와 함께 보안 스캐너에 업로드할 수 있습니다.
• 임베디드 SBOM은 설치된 애플리케이션 내부, 즉 배포 트리의 구성 가능한 경로에 배치되며, 역시 JSON 또는 XML 형식을 사용합니다. 해당 경로에 파일이 존재하지 않으면 install4j가 런타임 전용 SBOM을 그곳에 배치합니다.

임베디드 SBOM 경로가 기존 CycloneDX SBOM을 가리키는 경우, 예를 들어 애플리케이션용으로 자체 빌드에서 생성한 SBOM이 있다면, install4j는 install4j 런타임 컴포넌트와 그 의존성 그래프로 이를 보강합니다. 기존 내용은 그대로 유지되고 BOM 버전이 증가하므로, 설치된 아티팩트가 하나의 완전한 SBOM을 포함하게 됩니다. CycloneDX 사양의 1.2부터 1.7까지 버전이 지원됩니다.

MSIX는 MSI와 완전히 별개입니다. MSI의 경우 install4j는 install4j가 생성한 인스톨러를 감싸는 래퍼만 생성합니다. 화면, 액션, 스크립트 같은 install4j 개념은 MSI 모델에 매끄럽게 매핑될 수 없기 때문입니다. 반면 MSIX는 선언적 방식이므로 서비스, 파일 연결, 시작 작업과 같은 개념이 매니페스트 항목으로 직접 변환됩니다.

MSIX 패키지는 .msix 파일을 두 번 클릭하거나 PowerShell에서 Add-AppxPackage를 실행하여 설치하며, 설치 시점에 install4j 인스톨러 마법사는 실행되지 않습니다.

이 미디어 파일 유형을 배포하려면 코드 서명이 필수라는 점에 유의하십시오. 서명되지 않은 MSIX 패키지는 Windows의 개발 모드에서만 설치할 수 있기 때문입니다.

MSIX 관련 설정은 모두 미디어 파일 마법사의 전용 하위 단계에서 구성합니다. "MSIX 옵션" 단계에서는 패키지 ID 이름, 패키지 버전, 테스트된 최소 및 최대 Windows 버전을 설정합니다. 또한 런처를 로그인 런처로 지정할 수 있습니다. 로그인 런처는 사용자가 로그온할 때 자동으로 실행되며, 사용자는 나중에 Windows의 "시작 앱" 설정에서 이를 비활성화할 수 있습니다.

패키지 아이콘은 "패키지 아이콘" 하위 단계에서 사용자 지정합니다. 이 아이콘은 Windows 설치 대화 상자에 표시됩니다. 배경색을 지정하면 투명도가 있는 아이콘에 불투명한 타일이 적용됩니다. 시작 메뉴와 작업 표시줄에는 런처 마법사에서 구성한 아이콘이 사용됩니다.

서비스는 생성된 서비스 런처에서 선택되며 매니페스트를 통해 Windows 서비스로 등록됩니다. 시작 유형과 서비스 계정은 "서비스" 하위 단계에서 런처별로 구성합니다.

파일 연결은 하나 이상의 파일 확장자를 런처에 바인딩하여, 해당 파일을 두 번 클릭하면 애플리케이션이 열리도록 합니다. 연결마다 설명, 선택 사항인 MIME 유형, 사용자 지정 아이콘을 구성할 수 있습니다.

URL 스킴 핸들러도 같은 방식으로 선언되며, myapp://와 같은 사용자 지정 스킴이 런처로 라우팅됩니다. 두 기능 모두 "파일 연결 및 URL 핸들러" 하위 단계에서 설정합니다.

App URI 핸들러를 사용하면 런처가 특정 호스트에 대한 일반 https:// 링크를 처리할 수 있습니다. 일치하는 링크가 열리면 Windows는 브라우저 대신 애플리케이션으로 라우팅할 수 있습니다. 사이트의 링크는 해당 사이트의 동의 없이는 등록할 수 없으므로, 호스트는 이 패키지를 나열하는 생성된 windows-app-web-link.json 파일을 /.well-known/ 아래에 게시해야 합니다.

앱 실행 별칭(app execution aliases)은 선택한 런처를 사용자의 PATH에서 실행 파일 이름으로 노출하므로, 명령 프롬프트나 실행 대화 상자에서 이름으로 호출할 수 있습니다. 별칭은 패키지 범위로 한정되며 패키지와 함께 제거됩니다. 별칭은 "PATH의 애플리케이션" 하위 단계에서 선택합니다.

자동 업데이트의 경우 MSIX 패키지는 install4j 업데이트 아키텍처가 아닌 Windows에 내장된 App Installer 메커니즘에 의존합니다. 필요한 .appinstaller 파일은 install4j가 생성하며, 이후 Windows가 호스팅 URL을 주기적으로 확인하여 새 패키지 버전이 백그라운드에서 설치되도록 합니다. 호스팅 URL과 확인 빈도, 사용자에게 확인 메시지를 표시할지 여부 등 업데이트 동작은 "자동 업데이트" 하위 단계에서 구성합니다.

프로젝트에 구성된 모든 언어는 매니페스트에 자동으로 선언됩니다.

스킬은 자체 완결형 지식 패키지입니다. 여기에는 프로젝트 파일 스키마, 사용 가능한 모든 빈 클래스의 카탈로그(화면, 액션, 폼 컴포넌트, 화면 및 위젯 스타일), 실행 가능한 샘플 프로젝트, install4j API, 전체 문서가 일반적인 워크플로우에 대한 지침과 함께 AI 친화적인 형식으로 담겨 있습니다. 이를 통해 어시스턴트는 정확한 정보를 근거로 검증할 수 있으며 추측에 의존할 필요가 없습니다.

호환되는 어시스턴트는 install4j와 관련된 작업을 요청받으면 스킬을 스스로 로드합니다. 예를 들어 hello 샘플에 이미 설치된 버전을 감지하고 두 번째 설치 전에 확인 메시지를 표시하는 시작 검사를 추가하라고 요청하면, 어시스턴트가 적절한 레지스트리 API를 찾아 새 액션을 프로젝트 파일에 삽입하고 프로젝트가 여전히 컴파일되는지 확인합니다.

스킬을 설치하려면 도구 모음에서 "AI 스킬 설치" 버튼을 클릭합니다. 대화 상자에서 AI 에이전트의 스킬 디렉터리에 스킬을 저장할 수 있습니다. 지원되는 에이전트로는 Claude Code, Claude Desktop, Cursor, Codex CLI, Gemini CLI, OpenCode, Junie가 있습니다.

스킬은 전역으로 설치해 컴퓨터의 모든 프로젝트에서 사용할 수 있게 하거나, 프로젝트별로 설치해 에이전트가 해당 프로젝트에서 실행될 때만 사용할 수 있게 할 수 있습니다. 스킬은 정확한 install4j 버전을 기준으로 생성되므로 스키마, 빈 카탈로그, 샘플이 항상 설치된 컴파일러와 일치합니다.

XML 편집기에서 .install4j 파일에 이 스키마를 연결하면 편집하는 동안 자동 완성, 인라인 문서, 유효성 검사 기능을 사용할 수 있습니다. 또한 이제 명령줄에서 컴파일할 때마다 프로젝트 파일이 스키마에 대해 유효성이 검사되므로 구조적 오류를 정확한 메시지와 함께 조기에 잡아낼 수 있습니다.

세션은 세션 빌더 중 하나로 시작합니다. 생성된 인스톨러를 테스트하려면 InstallerSessionBuilder.forMediaFile(...)를, 언인스톨러를 테스트하려면 UninstallerSessionBuilder.forInstallation(...)를, 업데이트 다운로더와 같은 사용자 지정 인스톨러 애플리케이션에는 InstallerApplicationSessionBuilder.forInstallation(...)를 사용합니다. 빌더 옵션에는 타임아웃, 추가 명령줄 인수, 시스템 속성, 작업 디렉터리, 로그 파일, 그리고 브레이크포인트로 쉽게 디버깅할 수 있도록 인스톨러를 프로세스 내에서 실행하는 디버그 모드가 있습니다.

세션 내에서는 ID로 화면을 기다리고, 다음, 이전, 취소, 마침 버튼으로 탐색하고, 폼 컴포넌트와 대화 상자에 대해 강력한 형식의 핸들로 상호 작용하며, 마지막으로 인스톨러 변수, 설치 디렉터리, 로그, 종료 코드를 검증합니다:

InstallerSession session = InstallerSessionBuilder
    .forMediaFile(new File("media/myApp_windows-x64.exe"))
    .installationDirectory(targetDirectory)
    .start();

session.waitForScreenId("welcome").nextScreen();

// Accept the license, then fill in a custom form screen
session.currentScreen().checkBox("acceptCheckBox").setSelected(true);
session.currentScreen().nextScreen();
session.currentScreen().textField("port").setText("8443");
session.currentScreen().nextScreen();

// Modal dialogs can be handled when they appear
session.alert().clickYes();

session.currentScreen().finish();

// Verify the outcome after the installer has exited
int exitCode = session.awaitExit(Duration.ofMinutes(2));
assertEquals(0, exitCode);

Kotlin 사용자를 위해 API를 더 관용적으로 사용할 수 있도록 확장 함수가 포함되어 있습니다. useSession { } 블록은 세션을 시작하고 자동으로 닫으며, onScreen과 onAlert 같은 헬퍼는 화면이나 대화 상자에서 코드 블록을 실행하고, session["name"] 접근자는 인스톨러 변수를 읽습니다:

InstallerSessionBuilder
    .forMediaFile(File("media/myApp_windows-x64.exe"))
    .useSession {
        onScreen("welcome") { nextScreen() }
        onCurrentScreen {
            checkBox("acceptCheckBox").setSelected(true)
            nextScreen()
        }
        onAlert { clickYes() }
        onCurrentScreen { finish() }
        awaitExit()
    }

Test API는 com.install4j:install4j-test로 Maven Central에 게시되며, install4j 설치 디렉터리의 resource 디렉터리에 install4j-test.jar로도 함께 제공됩니다.

이러한 GUI 테스트는 CI에서 헤드리스로 실행할 수도 있습니다. GitHub Actions 러너처럼 디스플레이가 없는 Linux에서는 인스톨러 하위 프로세스가 자동으로 xvfb-run과 가벼운 창 관리자로 감싸져, 인스톨러가 가상 프레임버퍼에 렌더링되고 물리적인 화면 없이 테스트가 실행됩니다. 컴퓨터에 필요한 것은 xvfb-run과 지원되는 창 관리자(metacity, mutter, openbox, fluxbox, marco) 중 하나뿐입니다.

인스톨러가 Java 25 이상에서 ANSI를 지원하는 터미널로 실행되면 콘솔 모드는 이제 현대적인 대화형 UI를 렌더링합니다:

• 색상이 적용된 출력으로 성공 및 오류 메시지가 한눈에 들어옵니다.

  
• 백분율이 표시되는 실시간 진행 표시줄: 상태 및 세부 행이 스크롤되어 사라지지 않고 제자리에서 업데이트됩니다. 긴 파일 경로는 가운데를 줄여 표시되므로 경로의 앞부분과 끝부분이 계속 보입니다.

  
• 소요 시간을 알 수 없는 작업을 위한 스피너.

  
• 화살표 키로 탐색하는 단일 선택 목록: 옵션 메뉴와 예/아니요, 확인/취소 확인에 사용됩니다.

  
• 체크박스 목록에서의 다중 선택.

  
• 텍스트 및 마스킹된 비밀번호 입력, 탭 완성이 지원되는 파일 및 디렉터리 입력 프롬프트.

  
• 라이선스 계약과 같은 긴 텍스트를 위한 내장 페이저: 사용자가 끝까지 스크롤하도록 요구할 수도 있습니다.

  

고급 렌더러는 이전 Java 버전에서 실행되거나 충분한 기능을 갖춘 터미널이 없는 경우, 예를 들어 출력이 파일로 리디렉션되거나 다른 프로세스로 파이프되는 경우 자동으로 단순 콘솔로 폴백합니다. 인스톨러에 -J-Dinstall4j.plainConsole=true를 전달하면 단순 렌더러를 강제로 사용할 수 있습니다.

이 기능 덕분에 이제 install4j IDE를 모든 OpenJDK 변형 및 모든 HiDPI 해상도의 Linux에서 실행할 수 있습니다. 이전에는 HiDPI 해상도의 Linux에서 JetBrains 런타임만 지원되었습니다.