| Distro Page | A Distro Page is a non-technical view of a virtual distro available at Cloudsmith. Distro Pages are used as landing pages for "indirect" Cloudlinks (i.e. where materialization is not directly triggered by clicking the Cloudlink) and provide a simplified view of publisher-provided info and materialization functions. |
|---|---|
| Publishing space | A publishing space holds configuration meta-data for virtual configurations published at Cloudsmith. Read more about publishing spaces here. |
| Distro/View | Cloudsmith organizes information relating to a virtual distro into a "distro view" and a " distro page". The distro view provides information and links relating to the type and content of the distro, as well as a link to the relevant distro page as the quickest route to materializing the distro. |
| Cloudlink Wizard | The Cloudlink Wizard generates styled Cloudlinks for a range of common linking scenarios. A Cloudlink can be generated for a specific distro by selecting Cloudlink from the distro page menu. This will trigger the Cloudlink Wizard which will guide through the process of creating a Cloudlink according to the users requirements. |
| Materialization Wizard | The Materialization Wizard allows users to trigger materialization of distros directly from within a browser. |
| Troubleshooting Wizard | The Troubleshooting Wizard diagnoses common problems in running the Materialization Wizard resulting from a user's browser and Java environment. |
| Cloudlink | A Cloudlink ™ is a distro-specific URL used to link to launch the Materialization Wizard (either directly or through a Distro Page). It comes in the form of HTML/JavaScript code snippets ready for inclusion in a web page, blog, email or similar. A Cloudlink Wizard assists you in generating Cloudlinks. |
| Repo mapping | Users can add new content to the Cloudsmith map by using Cloudsmith's mapping wizard, which can traverse repositories of a supported type (for example, Maven 2), extract available configuration metadata and fold it into the map. Read more about repo mapping here. |
| Component | A component is a completely abstract and flexible representation of what developers commonly think of as a "component," i.e. a unit of software functionality. A "component" is basically just a unique reference to all the different versions of whatever a developer wants to include in this functional unit. |
|---|---|
| Distro | In Cloudsmith terms, a distro is just a "product" (or configuration of components) in a form that can be consumed (i.e. materialized) by an end-user. A distro can be static or dynamic. |
| Virtual Distro |
A virtual distro is a product (i.e. something a developer intends to
distribute) that is specified as a configuration of components and materialized, instead of
packaged and downloaded by conventional means.
Unlike a conventionally distributed product, the components that make up a virtual distro can be: (a) assembled from any number of locations in a single operation; (b) built and assembled dynamically, and with contextual variability; and (c) shared with collaborators as a fully or partly abstract configuration. |
| Distro Type | A distro can be static or dynamic. A static distro is a concrete realization of a component stack with materialization yielding always the same result. A dynamic distro is best described as a dynamic request for a stack of components rather than a bill of materials that is fixed upfront. The result of this request is allowed to vary within certain predefined boundaries. |
| Configuration | Often used interchangeably with distro. A component configuration is a component with listed dependencies to one or more components of specified version(s) or version ranges. |
| Virtual Configuration | A virtual configuration is a configuration of one or more components that are represented by metadata content (i.e. references to component name, location, etc.), instead of the actual artifacts. All configurations published at Cloudsmith are "virtual configurations," in this sense. |
| Materialize | A virtual distro
is materialized when all of the artifacts that it
calls for are found, retrieved and assembled on the user's deployment machine
specified by the user. A good analogy would be that "materialize" is to
"virtual distro" as "download" is to a "binary package."
Read more about materialization here. |
| Resolve | Resolving a component means recursively parsing its structure so that all references to other components on which it depends are translated into the form requested for materialization. Typically, this means translating abstract component references into concrete artifacts, making sure the correct version of each is used. |
| Top Component | The "top component" of a given distro is the component the resolving mechanism starts with during the resolution process, meaning all dependencies of this component can be traced recursively from the top component. Typically, the top component is the collection of assets a publisher has decided "go well together" and intends consumers to think of as a product. |