자바로 네이티브 인스톨러나 네이티브 패키징(윈도우즈의 경우 exe와 msi), 맥의 경우 앱스토어에 등록하는 방법

자바로 네이티브 인스톨러나 네이티브 패키징(윈도우즈의 경우 exe와 msi), 맥의 경우 앱스토어에 등록하는 방법

* 기본 필요 프로그램 : 자바 JDK 1.7u6 이상, JRE7, Java7, NetBeans(넷빈즈) 7.4 이상, 맥 OS X 10.8 

* JSmooth나 Exe4j보다 훨씬 간결하고 편하게 배포가 가능하다.

https://netbeans.org/kb/docs/java/native_pkg.html?print=yes
http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/packagingAppsForMac.html
https://developer.apple.com/library/mac/documentation/IDEs/Conceptual/AppDistributionGuide/DistributingApplicationsOutside/DistributingApplicationsOutside.html#//apple_ref/doc/uid/TP40012582-CH12-SW2

Native Packaging in NetBeans IDE

Written by Petr Somol and Alyona Stashkova

Native packaging was first introduced as a part of the JavaFX 2.2 SDK enabling you to package an application as a native bundle and then installing and running the application without any external dependencies on a system JRE or JavaFX SDK. Next it became usable for Java SE projects as well.

Native packaging does not change the deployment model of your application: it takes your application as it is, packages it together with Java runtime, and produces an installer that is common for the operating system you are using. The point is to make the whole thing independent on whatever Java runtime users have or do not have on the target machine. You can take such an installer and run it on a machine where there is no trace of Java, and it will install both the application and the necessary Java runtime bits.The size of such installers is quite big, because even a "Hello world" application will carry with itself a large portion of Java runtime artifacts.

In this tutorial you will create an EXE installer for a Java SE application and an MSI installer for a JavaFX application for the Windows operating system based on the sample applications bundled with the IDE.

Note:
•The EXE and MSI installers you get are platform-specific, they will run only on a system that is compatible with the target Java platform for which the EXE/MSI installable packages have been created. (For example, if an EXE or MSI installer has been created on a machine with a 64-bit JDK installed, it must be run on a machine with 64-bit Windows installed.)
•On Windows, both the applications are installed into the C:\Users\<username>\AppData\Local\ directory and are available in the Start menu.

Contents

Content on this page applies to NetBeans IDE 7.4 or 8.0
•Installing and Adding Required Tools to the Path
•Native Packaging in Java SE Projects •Setting Up a Java SE Project
•Enabling Native Packaging for the Project
•Building an Application
•Making an EXE Installer

•Self-Contained Application Packaging in JavaFX Projects •Creating a JavaFX Project
•Enabling Native Packaging for the Project
•Building an Application
•Making an MSI Installer

•Verifying the Installable Applications
•See Also

To follow this tutorial, you need the following software and resources.

Software or Resource

Version Required

NetBeans IDE 7.4 or 8.0 
Java Development Kit (JDK) 7 update 25 (or more recent) or 8 
Inno Setup 5.5 or more recent 
WiX 3.7 or more recent 

Installing and Adding Required Tools to the Path

To use the IDE's support for native packaging, the following additional tools need to be installed:
•Inno Setup 5.5 (or more recent) for producing EXE installers on Windows is required.
•WiX 3.7 (or more recent) for producing MSI installers on Windows is required.

Note: For a list of tools required for making installers for different platforms, see "Packaging an Application as a Native Installer" in Developing Applications with NetBeans IDE.

To install Inno Setup:
1.Download ispack-5.5.3.exe from the Inno Setup Downloads page.
2.Double-click the file to launch the installer.
3.Accept the Inno Setup license agreement and click Next.
4.Follow the instructions in the install wizard for installing Inno Setup.

To install WiX:
1.Download wix37.exe from the WiX Toolset - Download page.
2.Double-click the file to launch the installer.
3.Follow the instructions in the install wizard for installing WiX.

To add Inno Setup and/or WiX to the system Path variable:
1.On Windows 7, select Start > Computer > System Properties > Advanced system settings.
2.Select the Advanced tab and click the Environment Variables button.
3.In the System Variables pane, double-click the Path variable.
4.In the Edit System Variable dialog box, add a semicolon followed by a new path to the Variable value field (for example, C:\Program Files (x86)\Inno Setup 5  or C:\Program Files (x86)\WiX Toolset v3.6\bin).
5.Click OK to close all the open dialog boxes.

Notes:
•To check if the installed tool is in the Path, open the Command Prompt window and type iscc.exe for Inno Setup or candle.exe for WiX. (In case the Command Prompt closes instantly, try specifying cmd.exe /c cmd.exe /k iscc.exe or cmd.exe /c cmd.exe /k candle.exe respectively.)
 The following figure shows what the Command Prompt should display if Inno Setup is added to the system Path variable
* 이미지

•Make sure the IDE is restarted after the tools are added to the system Path variable

Native Packaging in Java SE Projects

To utilize the native packaging support in the IDE, you need to complete the following:
•create an IDE project
•enable the native packaging actions in the project
•clean and build the project
•package the application in an installer

Setting Up a Java SE Project

Before packaging an application in an installer an application itself needs to be created.

You will create a new Java SE project with the Anagram game example which is shipped with NetBeans IDE.

To create an IDE project:
1.In the IDE, choose File > New Project.
2.In the New Project wizard, expand the Samples category and select Java.
3.Choose Anagram Game in the Projects list. Then click Next.
Creating a Java SE project

4.In the Name and Location panel, leave the default values for the Project Name and Project Location fields.
5.Click Finish.
 The IDE creates and opens the Java SE project.

To test that the created project works fine, run it by choosing Run > Run Project from the main menu.
 The Anagrams application should launch and display on your machine.

Anagrams application running

Enabling Native Packaging in the IDE

The native packaging actions are disabled in the IDE by default.

Right-click the AnagramGame project in the Projects window, to check the actions available for the created Java SE project in the IDE: there are no package related actions in the project's context menu.

To enable native packaging actions for the project:
1.Right-click the project node in the Projects window and select Properties from the context menu.
2.In the Project Properties dialog box, choose the Deployment category and select the Enable Native Packaging Actions in Project Menu option.
Enable Native Packaging selected

3.Click OK.
A Package as command is added to the project's context menu.
Package as actions enabled in the Context menu

Building an Application

It is time to clean and build your application for deployment.

To clean and build your project:
•Choose Run > Clean and Build Project from the main menu.
The IDE displays the results in the Output window.
Output window

A dist folder that contains a jar file is created in the project folder.

Making an EXE Installer

The application can now be packaged in an installer for Windows.

To build an EXE installer:
•Right-click the AnagramGame project and choose Package as > EXE Installer from the context menu.

Note: The IDE creates an EXE installer only if Inno Setup is installed and added to the system Path variable.

The IDE displays the progress and result of the packaging process in the Output window.

Output window displays the progress of building an EXE installer

Note: The IDE first logs some progress and then for some time it looks as if nothing is happening - this is exactly the moment when Inno Setup is working in the background. It takes a while for the packaging to get completed.

When the EXE installer is ready, it is placed in the AnagramGame/dist/bundles/ directory.

Output window displays the progress of building an EXE installer

Self-Contained Application Packaging in JavaFX Projects

To build an installable JavaFX application using the native packaging support in the IDE, you need to complete the following:
•create a JavaFX project in the IDE
•enable native packaging support for the project
•clean and build a JavaFX application
•build an installable JavaFX application

Creating a JavaFX Project

You begin by creating a JavaFX project using the BrickBreaker sample project bundled with the IDE.

To create a JavaFX project in the IDE:
1.In the IDE, choose File > New Project.
2.In the New Project wizard, expand the Samples category and select JavaFX.
3.Choose BrickBreaker in the Projects list. Then click Next.
4.In the Name and Location panel, leave the default values for the Project Name, Project Location, and JavaFX Platform fields.
Creating a JavaFX project

5.Click Finish.
 The BrickBreaker JavaFX project displays in the Projects window in the IDE.

To test that the created project works fine, run it by choosing Run > Run Project(BrickBreaker) from the main menu.
 The Brick Breaker application should launch and display on your machine.

Brick Breaker application running

Enabling Native Packaging in the Project

To use the native packaging support in the IDE for your project, you need to enable it first.

If you right-click the Brick Breaker project, you will see no native packaging related actions in it.

Context menu without Package as actions

To enable native packaging actions in the project context menu:
1.Right-click the project node in the Projects window and select Properties from the context menu.
2.In the Project Properties dialog box, choose Deployment in the Build category and select the Enable Native Packaging option.
Enable Native Packaging selected in a JavaFX project

3.Click OK.
The Package as item is added to the project's context menu.
Package as actions enabled in the context menu of the JavaFX project

Building an Application

Your JavaFX application is now ready to be cleaned and built.

To clean and build your project:
•Choose Run > Clean and Build Project from the main menu.
The IDE displays the results in the Output window.

Note: If the build is successful but the IDE displays warning: [options] bootstrap class path not set in conjunction with -source 1.6 in the Output window, the Source/Binary format needs to be set to JDK 8 in the project properties and the project needs to be cleaned and built again as follows:
1.Right-click the BrickBreaker project in the Projects windows and choose Properties.
2.In the Project Properties dialog box, select the Sources category.
3.Set the Source/Binary format to JDK 8 and click OK.
4.Right-click BrickBreaker in the Projects window and choose Clean and Build from the context menu.

Making an MSI Installer

The application can now be wrapped into a Windows-specific installable package.

To build an MSI installer:
•Right-click the BrickBreaker project and choose Package as > MSI Installer from the context menu.

Note: The IDE creates an MSI installer only if WiX is installed and added to the system Path variable.

The IDE displays the progress and result of the packaging process in the Output window.

Output window displays the progress of building an MSI installer

Note: The IDE first logs some progress and then for some time it looks as if nothing is happening - this is exactly the moment when WiX is working in the background. It takes a while for the packaging to get completed.

The installable JavaFX application is located in the BrickBreaker/dist/bundles/ directory.

MSI installer

Verifying the Installable Applications
When the AnagramGame-1.0.exe and BrickBreaker-1.0.msi installers are done, you need to check which directory the Anagram and BrickBreaker applications are installed natively into.
To check the installers:
1.Browse to the installer file (AnagramGame-1.0.exe or BrickBreaker-1.0.msi) on your hard drive.
2.Double-click to run the installer.

Both the applications should be installed into the C:\Users\<username>\AppData\Local\ directory and be available in the Start menu.

See Also
•Packaging an Application as a Native Installer in Developing Applications with NetBeans IDE
•Deploying JavaFX Applications: Self-Contained Application Packaging
•Packaging a Java App for Distribution on a Mac

http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/packagingAppsForMac.html

Packaging a Java App for Distribution on a Mac

This page shows you, step by step, how to convert a simple Java application to a version you can distribute on a Mac. To follow along, download the  ButtonDemo (.zip) example from the Java Tutorial. This example was created using NetBeans which uses the Ant utility. You can run all necessary tools and make all necessary edits from the command line, without launching NetBeans. The Ant tool is required.

You have created a Java application and want to bundle it for deployment. This requires the following steps:
##Create a JAR File
##Bundle the JAR File into an App Package
##Bundle the JRE with the App Package
##Sign the App
##Submitting an App to the Mac App Store

Create a JAR File

This step creates the ButtonDemo.jar file.

Execute ant jar in the high-level project directory to create the dist/ButtonDemo.jar file. This jar file is used to create the .app package.
 
Bundle the JAR File into an App Package

To create the ButtonDemo.app package, use the appbundler tool. The appbundler is not shipped with the 7u6 version of the Oracle JDK for the Mac. You can download it from the Java Application Bundler project on java.net. There is also AppBundler Documentation available.

As of this writing, the most recent version is appbundler-1.0.jar, which is used by this document. Download the latest version available and substitute the file name accordingly.
1.Install the appbundler-1.0.jar file. In this case, create a lib directory in the high-level project directory and add the appbundler-1.0.jar file.
2.Modify the build.xml file in the high-level project directory as follows. (The added code is shown in bold.) <?xml version="1.0" encoding="UTF-8"?>
<project name="ButtonDemo" default="default" basedir=".">       
    <import file="nbproject/build-impl.xml"/>

    <taskdef name="bundleapp"
             classname="com.oracle.appbundler.AppBundlerTask"  
             classpath="lib/appbundler-1.0.jar" />

    <target name="bundle-buttonDemo">
        <bundleapp outputdirectory="dist"
            name="ButtonDemo"
            displayname="Button Demo"
            identifier="components.ButtonDemo"
            mainclassname="components.ButtonDemo">
            <classpath file="dist/ButtonDemo.jar" />
        </bundleapp>
    </target>

</project>

3.Invoke the appbundler by typing ant bundle-buttonDemo from the high-level project directory. This creates the ButtonDemo.app package in the dist directory.
4.You should now be able to launch the application by double clicking ButtonDemo.app in the Finder, or by typing open ButtonDemo.app at the command line.

Bundle the JRE with the App Package

In order to distribute a Java application, you want to avoid dependencies on third party software. Your app package should include the Java Runtime Environment, or JRE. In fact, the Apple Store requires the use of an embedded JRE as a prerequisite for Mac App Store distribution. The runtime sub-element of the <bundleapp> task specifies the root of the JRE that will be included in the app package.

In this example, the location of the JRE is defined using the JAVA_HOME environment variable. However, you might choose to bundle a JRE that is not the same as the one you are using for development. For example you might be developing on 7u6, but you need to bundle the app with 7u4. You will define runtime accordingly.

Since this example defines the runtime sub-element using JAVA_HOME, make sure it is configured correctly for your environment. For example, in your .bashrc file, define JAVA_HOME as follows:
export JAVA_HOME=`/usr/libexec/java_home`

Use the following steps to modify the build.xml file at the top of the project directory:
1.Specify an environment property, named env: <property environment="env" />

2.In the target that creates the bundle, specify the location of the JRE on your system, using the env property: <runtime dir="${env.JAVA_HOME}" />

 

The resulting build.xml file should look like the following. (The new lines are shown in bold.)
<?xml version="1.0" encoding="UTF-8"?>
<project name="ButtonDemo" default="default" basedir=".">
    <import file="nbproject/build-impl.xml"/>

<property environment="env" />

<taskdef name="bundleapp"
         classname="com.oracle.appbundler.AppBundlerTask"
         classpath="lib/appbundler-1.0ea.jar" />

<target name="bundle-buttonDemo">
    <bundleapp outputdirectory="dist"
        name="ButtonDemo"
        displayname="Button Demo"
        identifier="components.ButtonDemo"
        mainclassname="components.ButtonDemo">
        <runtime dir="${env.JAVA_HOME}" />
        <classpath file="dist/ButtonDemo.jar" />
    </bundleapp>
</target>

</project>

Create a fresh version of ButtonDemo.app, using the ant bundle-buttonDemo command. The resulting version includes the JRE in the app package. You can confirm this by examining the Contents/PlugIns directory inside of the app package.

Sign the App

The Gatekeeper feature, introduced in Mountain Lion (OS X 10.8), allows users to set the level of security for downloaded applications. By default, Gatekeeper is set to allow only OS X App Store and Developer ID signed applications. Unless your app is signed with a Developer ID certificate provided by Apple, your application will not launch on a system with Gatekeeper's default settings.

For information on the signing certificates available, see Code Signing Tasks on developer.apple.com.

The signing certificate contains a field called Common Name. Use the string from the Common Name field to sign your application.

Sign your app using the codesign(1) tool, as shown in the following example:
% codesign -s "Developer ID Application: CommonNameFromCertificate" ExampleApp.app

To verify that the app is signed, the following command provides information about the signing status of the app:
% codesign -d --verbose=4 ExampleApp.app

To check whether an application can be launched when Gatekeeper is enabled, use the spctl command:
% spctl --assess --verbose=4 --type execute ExampleApp.app

If you leave off the --verbose tag, and it does not print any output, indicates 'success'.

For more information, see Distributing Outside the Mac App Store on developer.apple.com.

Submitting an App to the Mac App Store

Packaging an app for the Mac App Store is similar to packaging for regular distribution up until the step of signing the app. Signing the app for the Mac App Store requires a few more steps, and a different kind of certificate.

You will need to create an application ID and then obtain a distribution certificate for that application ID. Submit your app using Application Loader. For more information, see the following links (on developer.apple.com):
##Submitting to the Mac App Store
##Submit Your Application Using Application Loader

Mac Developer Library : Distributing Applications Outside the Mac App Store

In some cases, you may want to distribute an application outside the Mac App Store. Because that application won’t be distributed through the Mac App Store, use a Developer ID certificate to give your users assurance that you’re an Apple-identified developer.

Mac users have the option of turning on Gatekeeper, a security feature that gives users the ability to install software only from the Mac App Store and identified developers. If your application isn’t signed with a Developer ID certificate issued by Apple, it won’t launch on a Mac that has Gatekeeper enabled. To avoid this situation, sign your applications and installer packages using a Developer ID certificate. Also, thoroughly test the end-user experience using a Gatekeeper-enabled Mac before distributing your application outside of the Mac App Store.

This chapter describes the Xcode steps to create and test Developer ID-signed applications for distribution outside of the Mac App Store.

Creating Developer ID-Signed Applications or Installer Packages

Creating a Developer ID-signed application or installer package is a multistep process. First you tell Xcode that you intend to distribute your application outside of the Mac App Store and then request Developer ID certificates. There are two types of Developer ID certificates: a Developer ID Application is used to sign applications, and a Developer ID Installer is used to sign installer packages. Using Xcode, you export and sign an archive of your application using the Developer ID Application certificate. You can also use command-line utilities to sign an installer package using the Developer ID Installer certificate.

Important: Before you begin, enroll in the Mac Developer Program, as described in “Adding a Developer Program to Your Team.” Only Mac Developer Program members are eligible to request Developer ID certificates and sign applications or installer packages using them.

Setting the Code Signing Identity to Developer ID

First set the code signing identity in the General pane to Developer ID.

bullet
To set the signing identity to Developer ID

../Art/14_developerid_option_2x.png

You can’t use key technologies and services if you distribute outside of the Mac App Store. If you enable a capability in the Capabilities pane, as described in “Adding Capabilities,” the Signing radio button reverts to Mac App Store.

Requesting Developer ID Certificates

You use signing certificates that begin with the text “Developer ID” to distribute your application outside the Mac App Store.

When you refresh provisioning profiles for the first time, as described in “Refreshing Provisioning Profiles in Xcode,” Xcode asks whether to request all types of certificates on your behalf. Be sure to select the Developer ID certificates from the Certificates Not Found dialog and click Request.

../Art/14_certificates_not_found_dialog_2x.png../Art/14_certificates_not_found_dialog_2x.png

Otherwise, use Accounts preferences to specifically request any missing Developer ID certificates, described in “Requesting Signing Identities.”

To use these certificates, you also need the Developer ID Certification Authority intermediate certificate that Xcode installs in your keychain for you, to use these certificates. If you’re missing this intermediate certificate, read “Installing Missing Intermediate Certificate Authorities” to restore it.

You should immediately backup your Developer ID signing identities after creating them, as described in “Exporting Your Developer Profile.”

If you want multiple Developer ID certificates, read “Requesting Additional Developer ID Certificates.”

Note: Only a team agent can request Developer ID certificates. If you’re an individual developer, you’re the team agent and can request these certificates. Contact product-security@apple.com if you want to revoke Developer ID certificates.

Verifying Your Steps

To verify your steps, view your Developer ID certificates in Accounts preferences, as described in “Viewing Signing Identities and Provisioning Profiles.”

../Art/14_mac_developerIDcerts_2x.png../Art/14_mac_developerIDcerts_2x.png

Code Signing Your Application

Optionally, code sign your application during development and testing using the Developer ID Application certificate. Later, you re-sign the application with this certificate when you archive and export it from Xcode.

bullet
To code sign an application with your Developer ID Application certificate

Exporting a Developer ID-Signed Application

To export your application for distribution outside of the Mac App Store, use the Archives organizer.

bullet
To create a Developer ID-signed application

../Art/14_archivesorganizer_2x.png

../Art/14_selectsavesignedapp_2x.png

../Art/14_selectsigningidentity_2x.png

Signing an Installer Package

If you want to distribute your application outside the Mac App Store as part of an installer package, create the package as you normally do. One way to create the installer package is to use the packagemaker(1) command-line utility. Code sign the package with your Developer ID Installer certificate with the productsign command. To test your installer package, use the following command and replace MyPackageName.pkg with the filename of your package:

spctl -a -v --type install MyPackageName.pkg

Warning: Make sure you sign the installer package using your Developer ID Installer certificate. The productsign command-line utility allows you to sign an installer package using your Developer ID Application certificate. Although this approach may appear to work, the resulting installer archive will fail on the destination Mac.

If your development process includes code signing from the command line, read Code Signing Guide.

Verifying Your Steps

Before you distribute your application, test the end-user experience by launching your application with Gatekeeper enabled and disabled. You can enable and disable Gatekeeper using System Preferences. Use the spctl(8) command-line utility for verifying and testing Gatekeeper too. To simulate the end-user experience, you need to quarantine your application and test it again with Gatekeeper enabled.

Enabling and Disabling Gatekeeper

You turn on and off Gatekeeper by using the Security & Privacy preferences in System Preferences. You can turn off Gatekeeper and verify the status of Gatekeeper using the spctl(8) command-line utility.

bullet
To enable or disable Gatekeeper using the Security & Privacy preferences

../Art/14_securitypreferences_2x.png../Art/14_securitypreferences_2x.png

bullet
To disable Gatekeeper using the spctl command

bullet
To confirm that Gatekeeper is enabled using the spctl command

Testing Gatekeeper Behavior

After signing your application with a Developer ID certificate, you can test whether it was signed correctly and simulate the launch behavior of your application when Gatekeeper is enabled. On a Mac with Gatekeeper enabled, a quarantined copy of your application launches only if it’s Developer ID signed. (Learn about quarantine in this Knowledge Base article.) You can also test the behavior of Gatekeeper for an application that isn’t Developer ID signed.

Testing a Developer ID-Signed Application

You can use the spctl command-line utility to test whether your application is signed correctly using a Developer ID certificate.

bullet
To test your Developer ID-signed application

Testing the Launch Behavior

To thoroughly test your Developer ID-signed application, simulate launching the application on a Mac not used for development.

bullet
To prepare for testing Gatekeeper behavior

bullet
To test Gatekeeper behavior for your Developer ID-signed application

../Art/14_identified_developer_2x.png

tip icon

bullet
To test Gatekeeper behavior for blocking applications that aren’t Developer ID signed