Overview

Automation Package Libraries (AP Libraries) extend Step’s Automation Package model by enabling common code, libraries and entities to be packaged, deployed, and referenced independently from individual Automation Packages (APs).
They offer a structured mechanism for sharing logic at scale and optimizing performance across large automation ecosystems.

AP Libraries are reusable, versioned code artifacts that can provide:

• Shared logic across multiple Automation Packages
• Common utilities and helper classes
• Shared libraries
• Shared AP entities (Keywords, Plans)

Important:
AP Libraries complement (and do not replace) existing dependency mechanisms. Automation packages can still embed their own dependencies directly in Java uber-jars or .NET package archives.

Layout and Content of AP Libraries

An AP Library is delivered in one of two supported layouts.

Java Layout

A Java-layout AP Library is an uber-jar that may contain:

• Common Java libraries
• Common Java code
• Common AP entities implemented in Java:
  • Keywords
  • Inline Plans

This layout is technically similar to a Java automation package, but the intent is reusability and central distribution rather than defining a standalone AP.

.NET Layout

A .NET-layout AP Library is a ZIP archive of .NET DLL assemblies that may contain:

• Common .NET libraries
• Common .NET code

The ZIP may include multiple DLLs and other supporting files (PDB, configuration files)

The declaration of AP entities in .NET AP libraries is currently not supported.

Why AP Libraries?

Java automation packages (Java layout) can already embed dependencies directly in their uber-jar — this remains fully supported. However, AP Libraries introduce several important advantages:

1. Reuse shared functionality across multiple APs
2. Reduce AP size by removing duplicated dependencies
3. Improve performance of deployments and executions
4. Allow cross-AP automation (e.g., sharing browser drivers across APs)
5. Provide centralized governance of shared libraries
6. Enable environment-specific versions of shared code
7. Simplify updates of shared functionality (especially via managed libraries)

Scope & Limitations

Supported

• Java automation packages
• .NET automation packages
• Code-based AP entities (Keywords, Plans)

Not Supported

• ZIP-layout automation packages
• JavaScript / TypeScript
• Declarative AP entities defined in YAML (Keywords or Plans declared as YAML are not supported in AP libraries)

Library Types

There are two kinds of AP Libraries, differing mainly in mutability and how they are referenced.

Common Library (Immutable)

With Common Libraries, Automation Packages reference the library artifact directly, either through Maven coordinates or by selecting a specific file.

The reference to the library artifact is defined at deployment time (or during an isolated execution). When such a reference is provided, Step creates (or reuses) a corresponding Library entry that represents this artifact.

How Step handles Common Libraries

• If a library with the same Maven coordinates already exists in the Step instance, the existing Library entry is reused.
• If no matching entry exists, Step creates a new Library entry automatically.
• If a file is uploaded a new entry is systematically created

Common Library entries are immutable: once created, their content cannot be modified. Using a different library artifact requires redeploying the Automation Package with a new reference.

Creating Common Libraries explicitly

Common Libraries can also be created explicitly via the CLI or the UI. The way they are referenced by Automation Packages depends on the artifact type:

• Maven Artifact → referenced by Maven coordinates from the CLI or selected directly in the UI
• File-based Library → selected directly in the UI

The resulting Library entry will appear in the “Package Libraries” view in Step, with the type automationPackageLibrary, whether it was created implicitly or explicitly.

Use Common Libraries when Automation Packages must explicitly control and pin the exact version of the library they depend on.

Managed Library (Mutable)

With Managed Libraries, Automation Packages reference a library via a managed library key.
This key is resolved at deployment time (or during an isolated execution) to the library artifact of the corresponding Library entry.

Managed Libraries are created explicitly in Step, either via CLI or the UI. When creating a Managed Library, the library content can come from:

• Maven coordinates referencing an artifact in a Maven-compatible repository, or
• A local file uploaded directly to Step

Unlike Common Libraries, the content of a Managed Library can be updated after creation.
Uploading a new file or changing the referenced Maven coordinates updates the library for all dependent Automation Packages.

Managed libraries appear in the “Package Libraries” view in Step with the type automationManagedPackageLibrary, regardless of whether they were created from Maven coordinates or an uploaded file.

Use Managed Libraries when shared functionality must be centrally maintained and updated without redeploying dependent Automation Packages.

Working with AP Libraries

This section explains how to build library artifacts and deploy (register) them in Step, as well as how to reference them from Automation Packages.

Building a Library

Before a library can be used or registered in Step, its library artifact must be built.
Building a library refers to producing the actual Java or .NET artifact:

• Java Libraries: build an uber-jar containing Java code, libraries, and optional AP entities
• .NET Libraries: build a ZIP archive containing one or more DLLs and optional supporting files

How the artifact is built depends on your technology stack (e.g., Maven/Gradle for Java, MSBuild/.NET SDK for .NET).

Build instructions and samples:

• Java: The Java library is built just like any regular Java .jar archive. We recommend using maven for this task, but you can use any suitable build toolchain that is capable of producing correct jar files. (Maven/Gradle)
  the Automation Packages with Libraries sample illustrates how to build and use a Java library in details
• .NET: The .NET library consists of a ZIP with a set of DLLs and other supporting files (PDB, configuration files) at its root. Typically, for a .NET project containing Step keywords, it will be a ZIP of all libraries produced with the dotnet build command, excluding the actual DLL of your project.
  Since .NET Automation Packages and libraries only support Keywords as of now, the details on how to configure and build .Net packages and libraries can be found on the general .Net Keyword documentation

Deploying a Library to Step

Once a library artifact is built, it must be registered in Step so it becomes available as an Automation Package Library.
How a library is registered depends on its library type.

Common Library

Common Libraries can be registered explicitly in Step, but are most often created implicitly when deploying an Automation Package that references a library artifact (via Maven coordinates or file selection).

You can explicitly register a Common Library in Step from the UI, with the maven plugin or the CLI

The resulting Library entry appears in the Package Libraries view with type automationPackageLibrary.

Managed Library

A Managed Library must always be registered explicitly and is referenced using a managed library key.
When registering a Managed Library, the library content may come from:

• Maven coordinates, or
• A library file uploaded directly to Step

Managed Libraries are mutable: their content can be updated after registration.
Updating the referenced Maven coordinates or uploading a new file automatically updates all dependent Automation Packages.

Managed Libraries appear in the Package Libraries view with type automationPackageManagedLibrary.

You can deploy and update managed libraries from the UI, with the maven plugin or the CLI

Referencing a Library from an Automation Package

Library references are not stored inside the Automation Package descriptor.
Instead, a library is attached to an Automation Package when it is deployed or during an isolated execution, using the CLI or the UI.

Reference Types

• Common Library

  • Maven coordinates (CLI or UI):
    If a library with the same coordinates already exists, Step reuses it; otherwise, Step creates a new one.
  • File Upload (CLI or UI):
    A new library entry is created for each uploaded file
  • Library selection (UI only):
    Selecting a existing library is only possible form the UI.

• Managed Library

  • Referenced by the managed library identifier.
    The identifier points to an existing managed-library entry, and Step always resolves it to that entry (or fails if it does not exist).

For mode details on how to provide or select a library when deploying or executing Automation Packages refer to the corresponding documentation:

• Deploy an Automation Package from the UI
• Deploy an Automation Package with the maven-plugin
• Deploy an Automation Package with the CLI

Multi-Version Support

Step supports using multiple versions of both common and managed libraries, following the Automation Packages’ multi-version concept:

• Library version binding occurs when deploying or executing an Automation Package in isolation.
  During deployment, the library reference becomes part of the AP version.
  During isolated execution, the library is resolved dynamically in the same way as the package version.

• Different versions of the same Automation Package can reference different library versions, depending on the library type:

  • Common Library: the AP references a concrete library artifact (via Maven coordinates or a library file).
    Using a different library version means referencing a different artifact or file.
  • Managed Library: each version of a managed library is created as a separate library entry with a unique identifier.
    When an AP references such an identifier, it resolves to the correct library version.

• Managed libraries enable central version changes:
  Updating a managed library automatically reloads all Automation Packages that reference its identifier.

• SNAPSHOT artifacts for libraries follow the same explicit refresh behavior as Automation Package artifacts: they are updated only when explicitly refreshed.

• Version selection at runtime applies only to Automation Packages, not libraries.
  Libraries do not evaluate activation expressions.
  They simply follow the version referenced by the AP version selected for the execution.

Best Practices

When Should You Use an Automation Package Library?

Use embedded dependencies (inside the AP) instead of an AP Library when:

• Logic is specific to a single automation package
• Dependency versions must be tightly controlled by the AP’s release cycle
• You want a fully self-contained artifact
• Reuse across APs is not required

This is the simplest packaging strategy and remains fully supported.

Use an AP Library when:

• Multiple APs share the same logic or entities
• You want to reduce duplicated dependencies
• You need to share objects via Session across multiple APs
• You want centralized governance of shared code
• Library updates should be decoupled from AP releases
• Environments require different library versions

AP Libraries are designed for scalable reuse.

When to Use a Common Library vs. a Managed Library

Use a Common Library when:

• You want strict, immutable, version-pinned dependencies
• Each AP should explicitly declare which version it uses
• Updates should occur only when APs are redeployed
• Different APs may use different library versions
• Development teams manage their own dependency lifecycles

This is similar to standard dependency management in software development.

Use a Managed Library when:

• A library should be centrally updated on the Step platform
• All APs referencing the same key should always use the same version
• You want to avoid redeploying dependent APs
• Environments should use environment-specific variants via different keys
• Consistency and governance are more important than AP-specific versioning

Ideal for shared frameworks, platform-level utilities, and common engine components.