Deployment

Create a deployment

This topic takes you through the process of deploying your application to your end user machines. Before creating a deployment you need to ensure that you have licensed your app correctly for the functionality you are using. For help on this subject see the License topic.

1. Create a new directory you'll use to build the application deployment.

2. Compile your application as a runnable .jar file and place the file in the directory you created above.

3. Create directories called jniLibs and resources next to your runnable .jar and inside this you will need to selectively copy over the directories in your IDE project. The purpose of the files in each directory is explained below. From this you can decide which directories need to be deployed with your app.

   Directory	Content purpose
   jniLibs/LX64	binaries for 64bit Linux
   jniLibs/MACOS/aarch64	binaries for Mac OS X on M1
   jniLibs/MACOS/x64	binaries for Mac OS X on x64
   jniLibs/WIN64	binaries for 64bit Windows
   jniLibs/directx	compiled shaders needed for Windows platforms
   resources/network_analyst	Network Analyst resources for closest facility and routing tasks
   resources/pedata	data for grid based transformations See note below for download information
   localserver100.14/64	binaries for 64bit Local Server

When creating the Local Server binary directories, you can use the ArcGIS Runtime Local Server Deployment Builder to build deployments that only contain the functionality you require for your app. The ArcGIS Runtime Local Server Deployment Builder comes as part of the Local Server SDK.

Local Server deployments cannot be cross platform deployments. For example, if you make a Local Server deployment for Linux it can only be used on Linux.

Local Server deployments on Linux cannot be shared between multiple users. Each deployment much be used by only one Linux user.

In addition, if you will run local services based on map documents, and those map documents use third-party fonts, then you must make sure that those third-party fonts are installed on each client machine where those services will run. Otherwise, the corresponding local service may fail to start or may fail to render symbols that use those fonts.

Apache HTTP5 dependency

The Apache HTTP 5 dependency also requires the use of the SLF4J (Simple Logging Facade for Java) library which will result in the following warnings in your console output when starting your application.

1
2
3
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

Please refer to the SLF4J documentation about this warning and how to prevent it.

If you are not using the logging, you could include the following dependency in your build script. The example below shows how this can be achieved with Gradle:

1
2
dependencies {
    runtimeOnly 'org.slf4j:slf4j-nop:1.7.32'

This Apache HTTP dependency will cause runtime errors if you deploy your application in a fat jar, as it is a signed library. If you are using a fat jar deployment, then you will need to exclude the signing files from within the application jar. In Gradle this can be achieved by adding the following to the jar task:

1
2
3
4
// exclude signing files that come from dependencies
exclude "META-INF/*.SF"
exclude "META-INF/*.DSA"
exclude "META-INF/*.RSA"