BackgroundTogether with the growing number of choices for build-tools and frameworks there are also many opinions for how modules are stored within a repository. Initially, Artifactory supported the Maven layout conventions for dealing with modules (and relying on Maven-specific metadata). However, your build tool should be able to "talk" to the repository "naturally", so if you are using Ivy or Gradle, there is no need to configure them to use the Maven conventions in order to "fit in". Moreover, combining and chaining repositories that use different layouts should work out-of-the-box. This is where the Repository Layouts Add-on comes into play! The Freedom of Custom LayoutsWith the Repository Layouts Add-on you are no-longer limited to Maven-centric module handling - Artifactory allows you to take full control over the layout used by each repository and use layout definitions to identify module artifacts and descriptors. By using repository layouts, Artifactory can offer these smart module management facilities for any build technology:
Bundled LayoutsOut-of-the-box Artifactory comes with a number of default predefined layouts requiring no additional configuration:
Modules and Path Pattens used by Repository LayoutsModule FieldsTo support smart module management, Artifactory must construct module information for stored files. Artifactory construct this information based on path pattern information defined as part of Repository Layout configuration (detailed below). A module is comprised of various sub-elements or fields, which are typically expressed in the path of a stored artifact. The module-sub elements recognized by Artifactory are listed below. At a minimum, there are three mandatory fields required for module identification:
Using Module Fields to Define Path PatternsA path pattern is used in the configuration of a Repository Layout. The pattern is similar to that of the Ivy pattern and is used to define a convention for artifact resolution and publication paths. Artifactory uses path patterns to construct module information for stored files. This module information is then used to facilitate all the features mentioned above (version cleanup, cross-repo path conversions, etc.). Path Pattern TokensA path pattern is constructed of tokens (explained below), path separators (' Path patterns can be defined for every artifact in the repository or you can define a separate path patterns for descriptor-type artifacts (such as, a The following tokens are available:
Artifact Path PatternsAn artifact path pattern represents the typical structure that all module artifacts are expected to be stored in. For example -
Descriptor Path PatternsA descriptor path pattern is used to recognize descriptor files (like Using a specific descriptor path pattern is optional. When not used, Artifactory constructs module information for descriptor file using the artifact path pattern. Even though descriptor paths patterns are optional, usage of them is highly recommended in cases of distinctive descriptors, such as Ivy For example -
ConfigurationRepository layouts are configured on the global level of your Artifactory instance, so that any layout can be shared and reused across any number of repositories. Layout ConfigurationLayout configuration is available to administrator users from the Admin tab and then
Additional layouts can be created from scratch by clicking the "
Path PatternsDefine the artifact path pattern and the descriptor path pattern (optional), as explained above. File and Folder Integration Revision Regular ExpressionsThese fields should contain regular expressions that exactly match and describe the integration revision (excluding the base revision) formats as they are expected in the artifact's file name and path-structure folder name. Folder integration revision regular expression examples:
File integration revision regular expression examples:
Testing LayoutsNow that you have finished configuring your layout, you can test it out via the user interface on an artifact or a descriptor path, and see how Artifactory would build module information from the path, using the layout definitions.
Repository ConfigurationLocal Repository ConfigurationLayouts are mandatory for local repositories, since they define the structure of the artifact storage. NOTE! that repositories configured prior to the introduction of custom repository layouts are auto-configured with the default Maven 2 layout.
Remote Repository ConfigurationLayouts are mandatory only for the remote repository cache configuration. However, you can also define a layout of the remote repository. In this case, if the remote repository itself uses a different layout than the one chosen for the cache, all requests the to the remote target are translated from the path of the cache layout to the path of the remote layout. For example, the remote repository NOTE! that caches of remote repositories configured prior to the introduction of the repository layouts are auto-configured with the default Maven 2 layout.
Virtual Repository ConfigurationYou can also configure a layout for a virtual repository. When configured, all resolution requests can be made according to the virtual repository layout. When trying to resolves requests to the virtual repository Artifactory attempts to translate the request path to the layout of each nested repository, according to the module information constructed from the virtual request. Request path translation is not made and requests pass through to nested repositories with their original path in any of the following scenarios:
|
