Artifactory lets you define a virtual repository that is a collection of local, remote and other virtual repositories under a single logical URL.
A virtual repository hides the underlying repositories and lets users work against a single well-known URL, while allowing you to change the participating repositories and their rules without requiring any client-side changes.
The main features supported by a virtual repository are:
From the UI go to Admin:Configuration:Repositories:Virtual Repositories and create a new virtual repository.
Add the repositories you wish to be part of the virtual repositories to the virtual repository list of selected repositories.
The actual list of effectively resolved repositories (after expanding nested virtual repositories) will be displayed and automatically updated.
The search/resolution order when requesting artifacts from a virtual repository is always: local repositories, remote repository caches and finally remote repositories themselves.
Nesting Virtual Repositories
The ability to nest virtual repositories is unique to Artifactory. It allows for greater reuse of virtual repositories between themselves.
Artifactory will detect when overly nesting repositories ends up in an infinite loop and will warn against that.
Include Exclude Patterns in Virtual Repositories
The coupling of Include/Exclude patterns of Artifactory Configuring Repositories to virtual repositories nesting provides a powerful feature.
You can now define in a single virtual repository "remote-repos" the company groupId exclusion, and it will ensure that no requests for internal artifacts will be sent outside.
Another example for this feature, is defining virtual repository for a project, and filter undesirable groupId, sources or versions, that won't be visible to developers.
Serving Requests from Other Artifactory Instances
By setting the 'Artifactory Requests Can Retrieve Remote Artifacts' flag, you can instruct Artifactory whether the virtual repository should include remote repositories in artifacts resolution when answering requests coming from other Artifactory instances. This is useful when deploying Artifactory in a mesh (grid) architecture, where you do not want all remote Artifactories to act as remote proxies for other Artifactory instances.
Currently, to control remote artifacts resolution for other Artifactory instances for the global virtual repository 'repo', you'd have to use the artifactory.artifactoryRequestsToGlobalCanRetrieveRemoteArtifacts system property, which is set to false by default.
Making Sure Artifactory is Your Sole Artifacts Provider
One very bad practice (sadly heavily used on public POMs), is to add a direct reference to external repository in a POM. When any of
or
are present, Maven will dynamically add external repository URL to the build. This will shortcut Artifactory.
The solution until now was the usage of mirrorOf like described here.
Artifactory provide at the virtual repository level, an automatic cleanup of POM file. Three level of cleanup policy are configurable:
Discard Active References - Will removes repository elements that are declared directly under project or under a profile in the same pom that is activeByDefault.
Discard Any References - Will removes all repository elements regardless of whether they are included in an active profile or not.
Nothing - Don't removes any repository elements declared in the POM.