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.

    DirectoryContent purpose
    jniLibs/LX64binaries for 64bit Linux
    jniLibs/MACOS/aarch64binaries for Mac OS X on M1
    jniLibs/MACOS/x64binaries for Mac OS X on x64
    jniLibs/WIN64binaries for 64bit Windows
    jniLibs/directxcompiled shaders needed for Windows platforms
    resources/network_analystNetwork Analyst resources for closest facility and routing tasks
    resources/pedatadata for grid based transformations
    See note below for download information
    localserver100.14/64binaries 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.

Use dark colors for code blocksCopy
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:

Use dark colors for code blocksCopy
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:

Use dark colors for code blocksCopy
1
2
3
4
// exclude signing files that come from dependencies
exclude "META-INF/*.SF"
exclude "META-INF/*.DSA"
exclude "META-INF/*.RSA"

Your browser is no longer supported. Please upgrade your browser for the best experience. See our browser deprecation post for more details.