Montage Activity Overview

Montage’s software ecosystem infrastructure enables one-click setup of software development activities that could take hours or days to properly set up and configure. These Montage activities are thus highly portable, and address issues related to both installation and license management across multiple installation targets and ecosystems.

The general concept of the installation target was introduced in the Montage overview page here (link to montage-software.com/montage-overview). An installation target abstractly represents any place where packages need to be installed. The Montage activity defines a set of requests for packages to be installed into any number of installation targets. These are the “root installation requests” of the activity, and these installation requests also involve dependencies which must be installed. A user finds activities listed as a package on the Montage Launcher and can click to have it installed to the user’s machine. The Montage Launcher is a client application that is used to find packages and products and manage licenses.

Consider the example activity below, involving a C# desktop application with four packages. The activity is delivered as its own separate package consisting of an activity file along with the C# desktop application project, but without the Montage package components installed. This is because the activity represents a composition of packages, each with their own download and execute polices that must be evaluated within the context of the user. When the user clicks to install the activity, all root installation requests and dependencies must be unified with the user’s system. The Montage Launcher’s job is to figure out what best versions of all packages satisfy the “unification domain” of the dependency graph. If this new activity graph fails to unify with the system, for example due to a version conflict or due to a policy deficiency, the activity installation fails.

In the example activity above, there are only three root installation requests, and they all reference the C# desktop application project installation target. A fourth package must also be installed into the C# project installation target, due to the Touch Screen LCD package’s dependency on the Third Party Component package. Since this dependency is on another package in the same installation target instance, this is referred to as a “homogeneous” dependency.

Three of these packages depend on packages to be installed into the user’s common “Installed Applications” installation target. This is the installation target that represents the applications installed to the user’s computer. Because these packages are in a different installation target from the original packages, they are referred to as “heterogeneous” dependencies. This is valid in Montage. An ecosystem is able to support packages that make reference to installation targets of other ecosystems, if prior knowledge of that ecosystem installation target exists.

When the user requests the above activity, the Montage Launcher first performs unification and validates that licensing requirements are met. It then copies the activity to the requested location, installs all required packages into the C# desktop application project, and installs the software needed for the project to properly build.

This gives users extremely rapid setup of activities, with a clear expectation that if the activity successfully unifies and installs, it is guaranteed to build and run without problems. The graph also potentially represents composable software from multiple vendors. Montage leverages this graph to combine licensing requirements and provide a consolidated pricing for all products needed to be purchased to run the activity if premium packages are referenced.

For more details on the mechanics of package management and package dependency notagion, see Montage Package Dependency Notation

Each programming language and developer environment obviously represents an ecosystem, such as C#, Java, ASP.NET, python, etc... Each of these generally have their own adopted package management system, such as Nuget, Maven, pip, and others. Montage’s purpose is not to replace these package management systems, but rather to enhance their portability using a standardized and more robust activity-based construct.

For an overview of Montage licensing, see www.montage-software.com/montage-licensing-overview