Artifactory User Guide 3.0.2

Artifactory
User Guide

1. Installing Artifactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 OS Service or Standalone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Installing on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Installing on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.3 Standalone Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 RPM Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Deployment on Other Servlet Containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.1 Deploying the WAR File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.2 Deploying on JBoss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4.3 Deploying on IBM Websphere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5 Running Behind HTTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5.1 Running Behind Apache HTTPd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5.2 Running Behind nginx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.6 Changing the Default Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.6.1 Running Artifactory on MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.6.2 Running Artifactory on Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.6.3 Running Artifactory on PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.7 Upgrading Artifactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2. Administering Artifactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.1 General Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2 Managing Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.1 Understanding Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.2 Configuring Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2.3 Local and Remote Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2.4 Local Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.2.5 Remote Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.2.5.1 Managing Caches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.2.5.2 Handling Offline Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.2.5.3 Handling Checksums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.2.5.4 Going Through Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.2.5.5 Advanced Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.2.5.6 Importing Shared Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.2.6 Virtual Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.3 Managing Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.3.1 Managing Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.3.1.1 Recreating the Default Admin Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.3.2 Managing Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.3.3 Managing Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
2.3.4 Managing Security with LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.3.5 Centrally Secure Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.3.6 Access Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
2.4 Managing Backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.5 Importing and Exporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
2.6 Mail Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
2.7 Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
2.7.1 Global Configuration Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
2.7.2 Security Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
2.7.3 System Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
2.8 Exposing Maven Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
2.9 Clustering Artifactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
2.10 The Artifactory Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
2.11 System Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
2.12 Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3. Working with Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.1 Configuring Artifacts Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.2 Configuring Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4. Working with Gradle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.1 Gradle Artifactory Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.1.1 Gradle 1.6 Publishing Artifactory Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.1.2 Gradle Artifactory Plugin using the snapshot version . . . . . . . . . . . . . . . . . . . . . . . . . 95
5. Working with Ivy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6. Using Artifactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.1 Browsing Artifactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.2 Deploying via the Web UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.3 Searching Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.3.1 Quick Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6.3.2 Class Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6.3.3 Property Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.3.4 GAVC Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.3.5 Checksum Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.3.6 Bintray remote search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.4 Manipulating Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.4.1 Deleting Single Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.4.2 Cleaning-up Complete Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
6.4.3 Moving Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
6.5 Updating Your Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.6 Content-Type Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
6.7 Artifactory REST API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
6.7.1 Repository Configuration JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
6.7.2 Security Configuration JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
6.7.3 System Settings JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
7. Artifactory Pro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
7.1 Installing the Artifactory Pro Power Pack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
7.2 Artifactory Version Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
7.3 Build Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
7.3.1 Jenkins (Hudson) Artifactory Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
7.3.2 TeamCity Artifactory Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
7.3.2.1 TeamCity Artifactory Plugin - Release Management . . . . . . . . . . . . . . . . . . . . . . . 183
7.3.3 Bamboo Artifactory Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
7.3.3.1 Bamboo Artifactory Plugin - Release Management . . . . . . . . . . . . . . . . . . . . . . . . 194
7.4 License Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
7.5 Black Duck Code Center Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
7.6 LDAP Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
7.7 Repository Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
7.8 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
7.8.1 Using Properties in Deployment and Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
7.9 User Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
7.10 YUM Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
7.11 P2 Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
7.12 NuGet Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
7.13 RubyGems Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
7.14 Repository Layouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
7.15 Smart Searches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
7.16 Atlassian Crowd Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
7.17 Single Sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
7.18 SAML SSO Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
7.19 Filtered Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
7.20 Watches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
7.21 WebStart and Jar Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
8. Bintray Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
8.1 Bintray info panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
8.2 Push To Bintray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
8.3 Deploying Maven and Gradle snapshots to OJO (oss.jfrog.org) . . . . . . . . . . . . . . . . . . . . . 272
9. Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
10. Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
10.1 Artifactory 2.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
10.1.1 1.3.0-RC2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
10.1.2 1.3.0-RC1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
10.1.3 1.3.0-beta-6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
10.1.4 1.3.0-beta-5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
10.1.5 1.3.0-beta-4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
10.1.6 1.3.0-beta-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
10.1.7 Artifactory 2.1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
10.1.8 Artifactory 2.2.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
10.1.9 Artifactory 2.2.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
10.1.10 Artifactory 2.3.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
10.1.11 Artifactory 2.3.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
10.1.12 Artifactory 2.3.4.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
10.1.13 Artifactory 2.1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
10.1.14 Artifactory 2.1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
10.1.15 Artifactory 2.2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
10.1.16 Artifactory 2.2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
10.1.17 Artifactory 2.2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
10.1.18 Artifactory 2.2.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
10.1.19 Artifactory 2.3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
10.1.20 Artifactory 2.3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
10.1.21 Artifactory 2.3.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
10.1.22 Artifactory 2.4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
10.1.23 Artifactory 2.4.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
10.1.24 Artifactory 2.4.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
10.1.25 Artifactory 2.5.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
10.1.26 Artifactory 2.5.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
10.1.27 Artifactory 2.5.1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
10.1.28 Artifactory 2.5.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
10.1.29 Artifactory 2.6.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
10.1.30 Artifactory 2.6.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
10.1.31 Artifactory 2.6.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
10.1.32 Artifactory 2.6.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
10.1.33 Artifactory 2.6.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
10.1.34 Artifactory 2.6.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
10.1.35 Artifactory 2.6.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
10.1.36 Artifactory 2.6.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
10.2 Artifactory 3.0.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
10.2.1 Artifactory 3.0.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
10.2.2 Artifactory 3.0.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
1.
2.
3.
4.
Installing Artifactory
Before you install, refer to the section. System Requirements and Supported Platforms
Artifactory can be installed and run in a number of different ways:
Using thebundled Tomcat containeras a or UNIX Service Windows Service
Using thebundled Tomcat container as aStandalone Server
Using the , which sets up Artifactory as a service on a bundled Tomcat container - recommended RPM Distribution
As a standard WAR web app, either or see depending on the servlet container Drop The War specific instructions
Requirements
System Requirements
JDK
You can run Artifactory with and above, preferably JDK 1.7 update 21 and above. JDK 1.7
At least 512MB of allocated Java heap space is recommended, although it is possible to run with less RAM.
If you can reserve 512MB or more for Artifactory JVM, the recommended JVM option parameters are:
-server -Xms512m -Xmx2g -Xss256k -XX:PermSize=128m -XX:MaxPermSize=128m -XX:+UseG1GC
NOTE! that the larger the installation you must multiply thems, mx values accordingly.
Operating Systems
Artifactory has been tested and verified on Windows, Linux, Solaris and MacOS X. You should be able to run Artifactory on other platforms
supporting JDK 1.7 and above, but these have not been tested.
Browsers
Artifactory has been tested with the latest versions of Google Chrome, Firefox, Internet Explorer and Safari.
Servlet Containers
Artifactory ships with a bundled Tomcat 7 servlet container. however,Artifactory has been specifically verified to work seamlessly
on Tomcat 6 & 7, Jetty 6 & 7, JBoss 4.x & 5, BEA Weblogic 9, GlassFish v2 & V3, IBM Websphere 8.5 and Resin.
OS Service or Standalone
OS Service or Standalone
Before installing Artifactory on the bundled Tomcat server, ensure you have set the environment variable to point to a valid JDK JAVA_HOME
1.7+ home.
Follow these instructions for installing the standalone version under or . UNIX Windows
For greater performance and ease of maintenance you can also configure Artifactory to run on top of various . storage options
After successfully installing Artifactory, it should be available locally at: . http://localhost:8081/artifactory
1.
2.
Installing on UNIX
UNIX
When using UNIX, it is possible to either install Artifactory as a UNIX service or run it manually.
Before installation, it is recommended that you first verify your current environment by running theartifactoryct
l check under the $ARTIFACTORY_HOME/bin folder.
Installing Artifactory as Linux Service
Introduction
Artifactory is packaged as a zip with a bundled Tomcat and a complete install script that can be used to install it as a UNIX service, running
under a custom user.
Installing
To set up Artifactory as a Linux service:
Extract the packaged zip. This folder with the extracted files is considered the $ARTIFACTORY_HOME.
Runthe script as root. $ARTIFACTORY_HOME/bin/installService.sh
Set out below are details of the actions of the script:
User creation Creates a default user named "artifactory" ( ). $ARTIFACTORY_USER
You can change the default user by editing the $ARTIFACTORY_USE
value in . The install R /etc/opt/jfrog/artifactory/default
script accepts the user name as its first and only parameter.
etc config Creates the folder , copies the /etc/opt/jfrog/artifactory
configuration files there and creates a soft link in $ARTIFACTORY_H
OME/etc
etc default Creates the file contai /etc /default /opt/jfrog/artifactory
ning the main environment variables needed for Artifactory to run: JA
VA_HOME, ARTIFACTORY_USER, ARTIFACTORY_HOME,
... JAVA_OPTIONS,
The is included at the /etc /default /opt/jfrog/artifactory
top of and can include anything. artifactoryctl
that the default max memory is 2GB NOTE!
init.d Copies the service script file to artifactory /etc/init.d/arti
factory
Logs folder Creates folder, makes it writable for $ARTIFACTORY_HOME/logs
the user and creates a soft link ARTIFACTORY_USER $ARTIFACTOR
. Y_HOME/logs
The $ARTIFACTORY_HOME/tomcat/logs folder is linked to the $AR
TIFACTORY_HOME/logs/catalina.
Backup folder Creates the folder , so you must $ARTIFACTORY_HOME/backup
create a link if you want this folder to point to a different place (such
as: for example). The script makes /var/backup/artifactory $
writable for the user ARTIFACTORY_HOME/backup ARTIFACTORY_
. USER
Data folder Creates the folder , so you must create $ARTIFACTORY_HOME/data
a link if you want this folder to point to somewhere else. The script
makes it writable for the user . ARTIFACTORY_USER
chkconfig calls The script calls add, list (you can see the output), and then activates
the Artifactory service
After successfully running the script you can test the installation by running: or service artifactoryctl check /etc/init.d/artifact
ory check
Once everything is correct, start Artifactory with:
service artifactory start
or
/etc/init.d/artifactory start
You can then check the Artifactory log with:
tail -f $ARTIFACTORY_HOME/logs/artifactory.log
Generally, Artifactory is started as (when running as a service) and will internally to the user. root su $ARTIFACTORY_USER
Due to security considerations, it is not recommended that the is undefined and Artifactory runs as the current user, $ARTIFACTORY_USER
particularly if the current user is . root
. Note: In order to change the default storage follow this link
Running Artifactory Manually on UNIX
You can run Artifactory manually, without installation as a UNIX service, using directly to see its $ARTIFACTORY_HOME/bin/artifactory.sh
behavior. The console is locked on the Artifactory process and you can stop it cleanly with . crtl+c
To directly run Artifactory as a daemon process, using the environment variable of the shell you are currently in, execute the following script:
artifactoryctl check|start|stop
Installing on Windows
Windows
When using Windows, it is possible to install Artifactory as a Windows service or run it manually.
Running Artifactory Manually on Windows
Execute the "artifactory.bat" under the bin folder. This action searches for the Java executable and runs Artifactory's main class.
Installing Artifactory as a Windows Service
Overview
Artifactory makes use of the components providing the user with a method to install the application as a Windows Apache Commons Procrun
Service.
Requirements
The "JAVA_HOME" system variable should be set before running the installation, otherwise the script tries to find an appropriate JAVA
installation.
Optionally, the file found in can be edited and the default properties can be changed such %ARTIFACTORY_HOME%\bin InstallService.bat \
as and log directory. JAVA_OPTS
Installing
To install Artifactory as a Windows service, browse to , and execute the file . %ARTIFACTORY_HOME%\bin InstallService.bat
Windows 8 has a strict User Account Control (UAC), you must either disable UAC or right-click on cmd.exe and select "Run as
administrator" in order to run this script
1.
2.
Uninstalling
To uninstall the Artifactory service, browse to , and execute the file . %ARTIFACTORY_HOME%\bin UninstallService.bat
. Note: In order to change the default storage follow this link
Standalone Installation
Standalone Installation
You can set up Artifactory as a standalone server using the bundled Tomcat server, as follows:
Extract the Artifactory distribution archive (artifactory-xxx.zip) to a dedicated folder
This folder is (verify this by checking the presence of the ARTIFACTORY_HOME $ARTIFACTORY_HOME/etc/artifactory.config.x
file). ml
On the dedicated folder, go to the bin directory and run artifactory.sh for Unix, or artifactory.bat for Windows
In order to stop a standalone Artifactory instance, either use Ctrl-C, or kill the process using it's PID, or
execute$ARTIFACTORY_HOME/tomcat/bin/shutdown.sh/bat
NOTE! In order to change the defualt storage follow this . link

NOTE! that you can verify the default variables used in the startup scripts, such as JAVA_OPTIONS.
On UNIX, check the bin/artifactory.default file
On Windows, check the bin/artifactory.bat values
RPM Installation
Overview
In addition to the other Artifactory installation options, Artifactory can also be installed as an RPM package on RedHat compatible Linux
distributions.
The RPM distribution is available from Artifactory version 2.3.3.
The RPM package creates a dedicated user, installs a stripped-down distribution of the Apache Tomcat container configured for Artifactory (on
port 8081 by default), and registers this Tomcat as a service (but does not start it immediately).
This package effectively replaces the different setup scripts included with the Artifactory Zip distribution.
Requirements
Must be installed using the root user (or sudo).
An environment variable named pointing to the installation directory of JDK 1.7. JAVA_HOME
Managed Files And Folders
Artifactory, when installed via RPM retains the FHS (Filesystem Hierarchy Standard) format.
File/Folder Location Ownership
Artifactory binary /opt/jfrog/artifactory root
Depending on the security settings under Windows, you might need to install using 'Run as administrator'
In case running a 32 bit version of Windows, further information can be found here
You can check the effective values by running 'bin/artifactory.sh check'
Tomcat home /opt/jfrog/artifactory/tomcat root
Artifactory startup script /etc/init.d/artifactory root
Artifactory home /var/opt/jfrog/artifactory artifactory
Artifactory etc /etc/opt/jfrog/artifactory artifactory
Artifactory logs /var/opt/jfrog/artifactory/logs artifactory
Artifactory environment variables /etc /artifactory/default /opt/jfrog artifactory
MySQL Additional Configuration
The RPM includes a small CLI tool that assists with the configuration of Artifactory to use MySQL as a (recommended). Storage Method
After running the RPM installation process, it provides you with the option to run the MySQL configuration manually.
The tool is located in and requires MySQL 5.5+ to be pre-installed and running. /opt/jfrog/artifactory/bin/configure.mysql.sh
To install Artifactory use:
rpm -ivh artifactory-rpm-<version>.rpm
Running Artifactory
To start and stop Artifactory use the init script accordingly:
/etc/init.d/artifactory start
or
/etc/init.d/artifactory stop
Accessing Artifactory
Artifactory can be found using the following URL:
http://localhost:8081/artifactory
Deployment on Other Servlet Containers
General
Artifactory is a standard Java EE web application. Therefore, it can be installed and run on any Servlets 2.5 compliant container.
Artifactory has been specifically verified to work seamlessly on Tomcat 6 & 7, Jetty 6 & 7, JBoss 4.x & 5, BEA
Weblogic 9, GlassFish v2 & V3, IBM Websphere 6.1 and Resin.
Please follow the for installing on any servlet container. Generic Instructions the artifactory.war
There are also more detailed and specific instructions for installing under and . IBM Websphere JBoss
Deploying the WAR File
Generic Instructions
1.
2.
"Drop the War": Zero Configuration
Artifactory can be installed under any Servlet container by simply dropping or installing the file into the container's web artifactory.war
applications folder, for example, into Tomcat's folder. webapps
Deploy the artifactory.war file into your Servlet container, either by hot-deploy or by following the container's
standard web application deployment procedures.
that the file is located under the folder in the distribution. NOTE! artifactory.war webapps artifactory-x.y.x.zip
The Folder $ARTIFACTORY_HOME
Even with zero configuration, it is important to know where the Artifactory home folder is located, since this folder stores your configurations and
important repository data.
When Artifactory runs for the first time, it sets up a default configuration and creates all necessary files and folders under a $ARTIFACTORY_HOM
folder that, if unset, defaults to . E ${user.home}/.artifactory
To control the location of (particularly when installing Artifactory on a production server), either: $ARTIFACTORY_HOME
Start the Servlet Container VM with , pointing to the location of your Artifactory home -Dartifactory.home=$ARTIFACTORY_HOME
folder
- or -
Set an environment variable pointing to this location. $ARTIFACTORY_HOME
Artifactory creates the folder on startup if it does not already exist.
Manual Deployment
You can set up Artifactory on any Servlet container by deploying the war file and directing Artifactory to a dedicated create ARTIFACTORY_HOME
d by extracting the Artifactory distribution zip.
To manually deploy the war file:
Extract the Artifactory distribution archive (artifactory-xxx.zip) to a dedicated folder
This folder is (verify this by checking the presence of the ARTIFACTORY_HOME $ARTIFACTORY_HOME/etc/artifactory.config.x
file). ml
Start the Servlet Container and specify the location of by either using a JVM argument or by using an environment ARTIFACTORY_HOME
variable as explained in the previous section.
Deploying on JBoss
Deploying on JBoss
JBoss 5.x
Artifactory runs out-of-the-box on JBoss 5.x.
JBoss 4.x
For running Artifactory under JBoss 4.x, you must inform JBoss to use the JVM's built-in MBean server.
To do this, start JBoss with the system property set. jboss.platform.mbeanserver
On UNIX, you can do this by adding the following line to the JBoss startup script:
It is recommended not to include any version characters in the name of the war file, and leave it as: , to prevent artifactory.war
having version-specific information in the Artifactory base URL and to simplify future upgrades.
Ensure the folder is writable by the user running the Servlet Container.
1.
2.
3.
4.
5.
6.
7.
export JAVA_OPTS="$JAVA_OPTS -Djboss.platform.mbeanserver"
It is also recommended to increase the max perm gen size of the JBoss VM to at least 256MB ( ). -XX:MaxPermSize=256m
Deploying on IBM Websphere
Deploying on IBM Websphere
Overview
Artifactory can run on IBM's WebSphere application server (specific adjustments are necessary in Artifactory in order to be compatible with
WebSphere's working methods).
NOTE! that this is an out-of-the-box feature and requires minimal manual setup. not
Because of JAVA7 requirements, Artifactory 3.x can run on WebSphere 8.5 and above, These instructions have
been verified with WebSphere 8.5.0.1.
Setup
Before deploying Artifactory into WebSphere:
Extract the file. artifactory.war
Replace the standard web.xml file under with the WebSphere-specific from %EXTRACTED_WAR_FOLDER%/WEB-INF web.xml %ARTIFA
. CTORY_HOME%/misc/websphere
Repackage (zip) the war file.
Start WebSphere.
Add the following webcontainer custom property and set it to 'true' (see: ): PK33090
com.ibm.ws.webcontainer.invokefilterscompatibility
Save the change and restart WebSphere.
Add asm shared library:
8. Deploy normally into WebSphere.
Adding ASM shared library
WebSphere Application Server v8.5 includes version 3.2and version 4.0 of the ASM bytecode scanning library. This results in java.lan
g.IncompatibleClassChangeError:org.objectweb.asm.ClassVisitor when deploying Artifactory. To overcome this class path issue,you'll
need to create a new shared library containing the five asm jars used by Artifactory
(asm-3.2.jar,asm-analysis-3.2.jar,asm-commons-3.2.jar,asm-tree-3.2.jar,asm-util-3.2.jar), you can copy them from the artifactory
war/WEB-INF/lib. Add this library as a shared library to the Artifactory application and change the to Class loader order Classes
loaded with local class loader first (parent last).
Using WS datasorce
You can run Artifactory 3.x using WebSphere datasorce. This can be done
by creating two new datasorce, should have the same JNDI name but one
should end with 'noTX' (for none transaction)
ex: jdbc/oracleArDb, jdbc/oracleArDbnoTX
storage.properties should look like this:
type=oracle
driver=oracle.jdbc.OracleDriver
1.
2.
Running Behind HTTP Server
Artifactory can run behind an HTTP server. Examples of two popular servers are:
Running Behind Apache HTTPd
Running Behind nginx
Running Behind Apache HTTPd

Running Behind HTTP Server
Setting up Apache HTTPd as a Front-end to Artifactory
You may want to use Artifactory behind Apache HTTPd. This can be achieved via two alternative protocols HTTP or AJP:
Client ----------> HTTPD ----------> Artifactory
HTTP HTTP/AJP
Using AJP
The AJP protocol offers optimized low-level binary communication between the servlet container and Apache with additional support for
smart-routing and load balancing.
It can be used in Apache with , or with - for greater configuration flexibility. mod_proxy_ajp mod_jk
The examples below use which is distributed with Apache by default. mod_ajp
Configuring Apache with Installed mod_ajp
The sample virtual host refers to Apache as a reverse proxy to Tomcat, where Tomcat runs with the AJP connector on port 8009:
<VirtualHost *:80>
ServerAdmin your@email.address.com
DocumentRoot "/srv/www/httpd/htdocs"
ServerName artifactory.yourdomain.com
ErrorLog "logs/artifactory-error_log"
ProxyPreserveHost on
ProxyPass /artifactory/ ajp://localhost:8009/artifactory/
</VirtualHost>
Configuring Apache with Changing the Artifactory Path
This configuration uses the same setup as above but here the goal is to have as http://artifactory.yourdomain.com/repository/
root URL for Artifactory:
url=jndi:jdbc/oracleArDb
binary.provider.type=cachedDb
binary.provider.cache.maxSize=32212254720
Reset your cookies
When changing the Artifactory context path in Apache ensure to reset your browser's host and session cookies.
Having a stale context path value cached by cookies can lead to strange user interface issues, such as Not authorized to
errors when switching between tabs. instantiate class
<VirtualHost *:80>
ProxyPass /repository/ ajp://localhost:8009/artifactory/
ProxyPassReverse /repository/ http://artifactory.yourdomain.com/artifactory/
ProxyPassReverseCookiePath /artifactory/ /repository/
</VirtualHost>
Tomcat Configuration
If you are not using the bundled Tomcat with the Artifactory zip, but using a dedicated Tomcat, you must configure the AJP connector, located by
default under : $CATALINA_HOME/conf/server.xml
<Connector port="8009" protocol="AJP/1.3"
maxThreads="500" minSpareThreads="20" maxSpareThreads="150"
enableLookups="false" disableUploadTimeout="true"
backlog="100"/>
See for more configuration options. here
Using HTTP Proxy
Having Apache Proxy Artifactory via HTTP is the recommended setup when running Artifactory with Jetty.
It is required to configure correct redirects using the pass-reverse directive and to set the base URL in Artifactory
itself so that UI links show up correctly.
Configuring Apache with Installed mod_proxy_http
The sample virtual host assumes Tomcat or Jetty HTTP connector runs on port 8081.
NOTE! that for HTTP redirects to work, you must set a pass-reverse directive on Apache, or the underlying container base URL is passed in
redirects (in this example to ). http:// /artifactory/ artifactory.yourdomain.com
<VirtualHost *:80>
ProxyPass /artifactory/ http://localhost:8081/artifactory/
ProxyPassReverse /artifactory/ http://artifactory.yourdomain.com/artifactory/
</VirtualHost>
Proxying Apache HTTPs to Artifactory running HTTP
You can run Artifactory behind Apache with SSL (HTTPs). This can also be achieved using HTTP or AJP:
1.
2.
Client ----------> HTTPD ----------> Artifactory
HTTPS HTTP/AJP
Using AJP
If you are using Jetty (see above: AJP and Jetty), then AJP is recommended since it informs the servlet container everything about the not
correct base URL and requires no configuration in Artifactory.
Configuring Apache with Installed and Tomcat mod_proxy_ajp
The Apache and Tomcat sample configurations are identical to the one listed in "Using AJP" on this page for non-HTTPs Apache.
Using HTTP Proxy
Configuring Apache with Installed and Tomcat mod_proxy_http
The Apache and Tomcat sample configurations are identical to that detailed in "Using HTTP Proxy" on this page for non-HTTPs Apache.
Configuring a Custom URL Base in Artifactory
When not using AJP, the links produced by Artifactory, as well as certain redirects not only contain the wrong port but use the scheme http
instead of . https
To configure a custom base URL:
Go to the Admin tab and then . Configuration -> General -> Custom URL Basefield
Set the base URL to the value used to contact Artifactory on Apache
For example: https://artifactory.yourdomain.com/artifactory
See the section for more details about configuring the base URL. General Configuration

Setting up nginx server as a Front-end to Artifactory
You can use Artifactory behind an ngnix server.
Client ----------> NGNIX ----------> Artifactory
HTTP/S HTTP/S
Using HTTP/S Proxy
Having an nginx proxy Artifactory via HTTP or HTTPS is recommended.
You should set the base URL in Artifactory itself so that user interface links appear correctly.
This sample configuration assumes Tomcat HTTP connector runs on port 8081.
HTTPs to HTTP and Jetty
Jetty does not support HTTPs to HTTP without a special extended connector that hardcodes the HTTPs scheme (see: http://wiki.eclips
- Proxying SSL on Apache to HTTP on Jetty). e.org/Jetty/Tutorial/Apache
If you do not use this connector all redirects will use the wrong scheme. In such cases, it is recommended to use Artifactory with
Tomcat.
server {
listen *:80 ;
server_name artifactory.yourdomain.com;
client_max_body_size 2048M;
access_log /var/log/nginx/artifactory.yourdomain.com.access.log;
location /artifactory {
proxy_set_header Host $host:$server_port;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://localhost:8081;
proxy_read_timeout 90;
}
}
server {
listen 443;
server_name artifactory.yourdomain.com;
access_log /var/log/nginx/artifactory.yourdomain.com.access.log;
error_log /var/log/nginx/artifactory.yourdomain.com.error.log;
ssl on;
ssl_certificate /etc/nginx/ssl/site-name.crt;
ssl_certificate_key /etc/nginx/ssl/site-name.key;
ssl_session_timeout 5m;
ssl_protocols SSLv3 TLSv1;
ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP;
ssl_prefer_server_ciphers on;
location /artifactory {
proxy_redirect off;
proxy_set_header Host $host:$server_port;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Ssl on;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://localhost:8081;
proxy_read_timeout 90;
}
}

Tomcat Configuration
On Tomcat you must configure the HTTP connector located, by default, under : $CATALINA_HOME/conf/server.xml
internalProxies
Regular expression (using java.util.regex) that a proxy's IP address must match to be considered an internal proxy. Internal proxies
that appear in the remoteIpHeader are trusted and do not appear in the proxiesHeader value.
If not specified, the default value
of10\.\d{1,3}\.\d{1,3}\.\d{1,3}|192\.168\.\d{1,3}\.\d{1,3}|169\.254\.\d{1,3}\.\d{1,3}|127\.\d{1,3}\.\d{1,3}\.\d{1,3} is used.
1.
2.
<Connector port="8081" protocol="HTTP/1.1"
maxThreads="500" minSpareThreads="20" maxSpareThreads="150"
enableLookups="false" disableUploadTimeout="true"
backlog="100"/>
Add this to the . $TOMCAT_HOME/conf/Catalina/localhost/artifactory.xml
<Valve className="org.apache.catalina.valves.RemoteIpValve"
protocolHeader="x-forwarded-proto"/>
Configuring a Custom URL Base in Artifactory
Links generated by Artifactory, as well as certain redirects, contain the wrong port.
To configure a custom-based URL:
Go to the Admin tab and then . Configuration -> General -> Custom URL Base
Set the base URL to the value used to contact Artifactory on Apache, for example: http://artifactory.yourdomain.com/artif
actory
See the section for more details about configuring the base URL. General Configuration
Changing the Default Storage

Changing Storage Overview
Artifactory comes with a built-in Derby database that can be reliably used to store data for production-level repositories (up to hundreds of
gigabytes).
Artifactory's storage layer supports pluggable storage implementations, allowing you to use the most supported and popular databases:
Derby (embedded)
Oracle version 10g and above ( ) Oracle-specific Instructions
MySQL version 5.5 and above with InnoDB ( ) MySQL-specific instructions
Microsoft SQL Server 2008 and above
PostgreSQL version 9.2 and above ( ) PostgreSQL-specific instructions
You can work in two different modes:
Metadata in the database and binaries stored on the file system (default and recommended)
Metadata and binaries as BLOBs stored in the database
Once-And-Only-Once Identical Content Storage
Artifactory stores identical binary files only once. When a new file about to be stored in Artifactory is found to have the same checksum as a
previously stored file, Artifactory does not store the new file content, but creates a link to it in the metadata of the newly deployed file.
This principle applies regardless of which repository and path artifacts are deployed - you can deploy the same file to many different coordinates,
and as long as identical content is found in the storage, it is reused.
Changing the Storage Type Used
Changing the storage does not automatically transfer your data to the new storage! Read below on backing-up
and restoring your data before and after the change.
Removing the old $ARTIFACTORY_HOME/data folder
If you have previously run Artifactory with a different storage type you must remove (or move-aside) the existing $ARTIFACTORY_HOM
folder, or Artifactory continues to use part of the old storage definitions and will fail to start up (not found exceptions are E/data
1.
2.
3.
4.
5.
To change the storage used by Artifactory:
Create a database instance to which Artifactory connects.
Create an Artifactory user for this database and grant full permissions to this user (database tables are auto-created).
Download the appropriate JDBC driver and install it in your server's shared lib directory
($ARTIFACTORY_HOME/tomcat/lib).
Copy the relevant database configuration file from$ARTIFACTORY_HOME/misc/dbto$ARTIFACTORY_HOME/etc/storage.proper
ties
Change the database details in the storage.properties file to match your database. See for comprehensive details of each below
parameter.
When Artifactory is Deployed as a WAR
If you and have not specified a location for the directory, it is auto-created after it is run Deployed Artifactory as a WAR $ARTIFACTORY_HOME
for the first time by Artifactory under ' '. $USER_HOME/.artifactory
To use the bundled configuration files for common storage types, you may want to copy the folder from the Artifactory distribution to etc/misc
your . $ARTIFACTORY_HOME/misc
The Bundled Storage Configurations
For each of the supported databases you can find the file inside$ARTIFACTORY_HOME/misc/dbas listed below: <database>.properties
derby.properties
mssql.properties
mysql.properties
oracle.properties
Each file contains the mandatory parameters and definitions to be configured to work with your database.
binary.provider.type(If no parameter is set filesystem is used by default)
filesystem (default)
This means that all the metadata is stored in the database and the binaries are stored in the file system
$ARTIFACTORY_HOME/data/filestore (by default).
This setting typically yields the best performance with large repositories.
fullDb
All the metadata and the binaries are stored as BLOBs in the database
pool.max.active
The maximum number of pooled database connections (100 by default).
pool.max.idle
The maximum number of pooled idle database connections(10 by default).
binary.provider.cache.maxSize
If fullDb mode is being used, this value (in bytes) determines the maximum cache size to use on the system
for caching BLOBs.
binary.provider.filesystem.dir
If filesystem mode is being used, this value determines the location of the binaries
($ARTIFACTORY_HOME/data/filestore by default).
displayed on startup).
Starting with a clean or no folder fixes this. $ARTIFACTORY_HOME/data
Backing up your existing installation
When changing the storage type for an exiting installation you must import the old Artifactory content and configuration from backup.
Make sure to back-up your older Artifactory system before using a different storage type.
If the file $ARTIFACTORY_HOME/etc/storage.properties does not exist Artifactory automatically generates the file with the default
settings for a Derby database.
Accessing a Remote Database
To avoid network latency issues when reading and writing artifacts data, it is highly recommended to either create the database on the same
machine on which Artifactory is running or on a fast SAN disk.
Running Artifactory on MySQL

Overview of Running Artifactory on MySQL
The instructions below explain the process for setting-up Artifactory on MySQL.
By using MySQL (rather than the built-in Derby Database) you can utilize exiting MySQL infrastructure and use the
MySQL backup, restore and high-availability features.
The setup involves creating a dedicated MySQL database instance and then configuring Artifactory to use that
instance.
Create the Artifactory MySQL Database
Use the SQL script to execute the SQL commands below to create a database. $ARTIFACTORY_HOME/misc/mysql/createdb.sql
Review and edit this script before executing it, to suit your environment requirements.
root@pond artifactory]# mysql -u root
mysql> CREATE DATABASE artdb CHARACTER SET utf8;
Query OK, 1 row affected (0.00 sec)
mysql> GRANT ALL on artdb.* TO 'artifactory'@'localhost' IDENTIFIED BY 'password';
Query OK, 0 rows affected (0.00 sec)
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)
mysql> quit
Increasing MySQL's Default Packet Size
Since binaries are stored in MySQL, it is extremely important to increase the default packet size used by MySQL (refer to: max_allowed_packet
). increase
If using filesystem, for raw Artifactory data backup, the folder must be backed-up in parallel $ARTIFACTORY_HOME/data/filestore
with a database dump since both are required. The database must be dumped first.
This does not impact Artifactory's own backup system which is storage-agnostic.
This is critical if the files are served from database BLOBs and the file system cache size is low (relevant only to fullDb).
Please make sure to read before configuring MySQL. Changing the Default Storage
Supported MySQL versions
NOTE! that Artifactory works with . MySQL 5.5 and above
For best performance use the InnoDB engine (the default with this version).
1.
2.
3.
4.
1.
2.
We recommend changing this in the file. /etc/my.cnf
Create this file if it does not already exist (under the absolute path and under ): not $ARTIFACTORY_HOME
# The MySQL server
[mysqld]
.
.
# The maximum size of the binary payload the server can handle
max_allowed_packet=8M
.
.
Configure Artifactory to Use the MySQL Database
Copy to $ARTIFACTORY_HOME/misc/db/mysql.properties $ARTIFACTORY_HOME/etc/storage.properties
Adjust the connection definitions in the file to match the attributes of the $ARTIFACTORY_HOME/etc/storage.properties
Artifactory database you created.
(If you do not have this file you can take it from the standalone zip distribution or directly from .). here
You must configure the database URL and username/password to use. The schema and tables are created on the first run of Artifactory
using the database.
Download the and copy the jar file into the server's shared lib directory ( MySQL JDBC driver mysql-connector-java-x.x.x.jar $
in the standalone version), for example, etc. ARTIFACTORY_HOME/tomcat/lib $TOMCAT_HOME/lib
Start Artifactory.
Running Artifactory on Oracle
Overview of Running Artifactory on Oracle
The instructions below explain how to set up Artifactory on Oracle version 10g and above.
By using Oracle Database (rather than the built-in Derby Database) you can utilize exiting Oracle Database
infrastructure and use the native database backup, restore and high-availability features.
The setup involves creating the dedicated Oracle Database instance and then configuring Artifactory to use that
instance.
With Oracle, you can choose between two configurations:
DB-Filesystem stores metadata in Oracle Database and artifact BLOBs on disk; This option is very lightweight on the Oracle
database.
Full DB Stores both metadata and BLOBs in Oracle; This option allows you to rely solely on Oracle for failover and backup
procedures, as all data is in the database and it requires minimal maintenance.
With both of the above options ( ), it is recommended to create a dedicated table space and use the enco Full DB/DB-Filesystem AL32UTF8
ding.
All tables are created automatically by Artifactory the first time the application starts up and software upgrade may require altering tables and
indexes, so you must grant the configured connection user permissions to perform such actions.
General advice against storing artifacts as BLOBs inside MySQL
The suggested configuration keeps all artifacts information in MySQL while storing the artifact binary data on the file system (under $A
). This is the recommended setup. RTIFACTORY_HOME/data/filestore
It is possible, but not recommended, to store BLOBs inside MySQL, provided that the typical BLOB size is
relatively small. This is important because MySQL buffers BLOBs instead of streaming them (this behavior
is unrelated to Artifactory - http://bugs.mysql.com/bug.php?id=15089). Therefore, using large BLOBs may
result in out-of-memory errors with large binaries, depending on your JVM heap size.
If you want to store BLOBs inside MySQL, set in the storage.properties file, and change the binary.provider.type=fullDb max_allow
above to the maximum artifact size you are planing to store in Artifactory, for example . ed_packet 128M
Please make sure to read before configuring Oracle Database. changing the default storage
1.
2.
3.
4.
With the option, make sure you have created a table space big enough to accommodate your binaries. Full DB For efficiency, Artifactory
stores binaries by checksum. However, you may want to reclaim deleted BLOB space from time to time by
shrinking the BLOB table space:
{schema}.binary_blobs modify lob (data) (shrink space cascade);
Running Artifactory on PostgreSQL
Overview of Running Artifactory on PostgreSQL
The instructions below explain the process for setting-up Artifactory on PostgreSQL.
By using PostgreSQL (rather than the built-in Derby Database) you can utilize exiting PostgreSQL infrastructure and use the PostgreSQL
backup, restore and high-availability features.
The setup involves creating a dedicated PostgreSQL database instance and then configuring Artifactory to use that instance.
Create the Artifactory PostgreSQL Database
The commands below create artifactory user and database with appropriate permissions. Review and edit the create a database that suit your
environment requirements:
CREATE USER artifactory WITH PASSWORD 'password';
CREATE DATABASE artifactory WITH OWNER=artifactory ENCODING='UTF8';
GRANT ALL PRIVILEGES ON DATABASE artifactory TO artifactory;
Configure Artifactory to Use the PostgreSQL Database
Copy to $ARTIFACTORY_HOME/misc/db/postgresql.properties $ARTIFACTORY_HOME/etc/storage.properties
Adjust the connection definitions in the file to match the attributes of the $ARTIFACTORY_HOME/etc/storage.properties
Artifactory database you created.
(If you do not have this file you can take it from the standalone zip distribution or directly from .). here
You must configure the database URL and username/password to use. The schema and tables are created on the first run of Artifactory
using the database.
Download the and copy the file into the server's shared lib directory ( PostgreSQL JDBC4 driver postgresql-9.x-xxx.jdbc4.jar $
in the standalone version), for example, etc. ARTIFACTORY_HOME/tomcat/lib $TOMCAT_HOME/lib
Start Artifactory.
Upgrading Artifactory
To upgrade Artifactory to the latest version follow the specific instructions for your current version:
From 3.x and above
From 2.6.6 and above to 3.x
From 2.2.x and above to version 3.x
From 2.2.x or earlier versions
Please make sure to read before configuring PostgreSQL. Changing the Default Storage
Supported PostgreSQL versions
NOTE! that Artifactory works with using driver version or above. PostgreSQL 9.2 and above 9.2-1002.jdbc4
General advice against storing artifacts as BLOBs inside PostgreSQL
The suggested configuration keeps all artifacts information in PostgreSQL while storing the artifact binary data on the file system
(under ). This is the recommended setup. $ARTIFACTORY_HOME/data/filestore
It is possible, but not recommended, to store BLOBs inside PostgreSQL. This is important because PostgreSQL driver doesn't
support streaming BLOBs with unknown length to the database. Therefore, Artifactory will temporarily save deployed files to the
filesystem and only then save the BLOB to the database.
1.
2.
1.
2.
3.
1.
2.
Upgrading Artifactory from 3.x to the latest version
When Running the Artifactory WAR in a Servlet Container

Unzip the Artifactory distribution archive.
Replace the previously deployed file with the archive's file. artifactory.war webapps/artifactory.war
On servlet containers such as Tomcat it is also necessary to remove the exploded webapp directory. artifactory
When Running Standalone Artifactory
Unzip the Artifactory distribution archive.
Replace the following files and folders in you current with the same files from the new version: $ARTIFACTORY_HOME
webapps/artifactory.war
tomcat/conf/catalina.xml
tomcat/conf/web.xml
tomcat/conf/Catalina/localhost/artifactory.xml
bin
Delete the Tomcat work folder ( ) before starting up Artifactory. $ARTIFACTORY_HOME/tomcat/work
When Running the RPM Installation
Log in as root (or use ). 'sudo su -'
Execute'rpm -U artifactory-3.y.z.rpm'
================================================================
====================
Export / Import of Data to Artifactory from 2.6.6 and above to 3.x
NOTE! This method works only if the binaries are stored on the filesystem (the default config). If your server is configured to store binaries in the
database please follow the instructions . below
There are three steps required for the upgrade procedure:
Export from 2.6.6+
Copy the filestore from 2.6.6+
Import to 3.x
You can find detailed instructions below:
Export
The upgrade from version 2.x is not automatic. To upgrade from version 2.x read the upgrade instructions in the relevant sections
below.
The folder contains configuration files for specialized environments such as a or . misc Standalone Tomcat Server Websphere
Although these files are not required for runtime, it is recommended to replace this folder too.
If you have previously installed RPM from version 2.x, it cannot be upgraded. You must uninstall the old RPM and then install version
3.
1.
2.
NOTE! that if you have an updated backup, you can use this backup for performing the import. If your installation is coming from a legacy prior to
version 2.4.0 then use the full backup and do not export with exclude content as shown below.
Select the Admin tab and then go to -> to display the Export and Import options. Import & Export System
Installation and Definition - Physical and Database

When installing the new version of Artifactory, it must be installed in a location to the previously installed version. different
If you have previously installed RPM from version 2.x, it cannot be upgraded. You must uninstall the RPM and then install version 3.
If you are using an external database, you cannot use the same schema. You must create a new schema for the upgraded version.
Once you have taken the above into consideration, you can now perform a regular installation of Artifactory. Refer to for Installing Artifactory
details.
File Store Copy
Manually create data directory in $ARTIFACTORY_HOME/
Copy the $ARTIFACTORY_HOME/data/filestore directory from the old Artifactory version to $ARTIFACTORY_HOME/data in the new
Artifactory 3.x
Import
Select the Admin tab and then go to the to display the Export and Import options. Import & Export -> System
The only checkbox to be marked is the Exclude Content. Do not mark any other checkboxes!
Take into consideration, that the amount of free disk space required for upgrading a normal installation of Artifactory is at least the size
of the current file store - because manually copying the current file store
================================================================
====================
Upgrading From Version 2.2.x and Above to Version 3.x
The upgrade and installation process is divided into 3 steps:
Export from the previous version
Installation of Artifactory (in a new location) and defining a database
Import the data that was exported
Export
NOTE! that if you have an updated backup, you can use this backup for performing the import.
Select the Admin tab and then go to and select the target export directory. Import & Export -> System
NOTE! that you must add the timestamp to the name of the Zip File or Directory field after completion of the import process.
Set out below are the procedures required to upgrade Artifactory from version 2.2.x and above to version 3.x.
If you are using Artifactory version 2.6.6 it is preferable to use the above, which upgrade instructions
is a significantly faster procedure than a standard full system Export/Import.
Refer to for complete details of performing the export procedure. Importing and Exporting
Installation and Definition - Physical and Database
When installing the new version of Artifactory, it must be installed in a location to the previously installed version. different
If you have previously installed RPM from version 2.x, it cannot be upgraded. You must uninstall the old RPM and then install version 3.
If you are using an external database, you cannot use the same schema. You must create a new schema for the upgraded version.
Once you have taken the above into consideration, you can now perform a regular installation of Artifactory. Refer to for Installing Artifactory
details.
Import
Select the Admin tab and then go to and select the target directory to import to. Import & Export -> System
Refer to for complete details of performing the import procedure. Importing and Exporting
NOTE! that you must add the timestamp to the name of the Zip File or Directory field after completion of the import process.
================================================================
====================
Upgrading From 2.2.x or Earlier Versions
To upgrade from version prior to 2.2 you must first upgrade to 2.6. For details on how to perform this upgrade refer toUpgrading Artifactory to
. Version 2.6.x
Administering Artifactory
Overview
This section describes the Artifactory administration tasks, such as managing repositories, controlling security and configuring scheduled
services.
General Configuration
Managing Repositories
Managing Security
Managing Backups
Importing and Exporting
Mail Server Configuration
Configuration Files
Exposing Maven Indexes
Clustering Artifactory
The Artifactory Log Files
System Information
Maintenance
Introduction
To access the General Configuration settings of Artifactory, click on the Admin tab at the top of the viewing pane. In the left pane of the screen
select C the General Configuration options are displayed. onfiguration -> General
General Settings
The General Settings configurations allow you to set up various parameters that globally affect Artifactory. Enter the required information into
each field. Click on the icon next to each field for a detailed description of the information to be added. Fields marked with a red star are ?
mandatory.
The General Settings fields are as follows:
Field Name Description
Server Name(mandatory) The name of the server to be displayed on the title of each page.
Custom URL Base By default, URLs generated in Artifactory use context URL returned
by your servelt container as a base.
A custom URL base is useful when Artifactory is running behind a
proxy. In this case the base for URLs generated in Artifactory for
links and redirect responses must be specified manually.
Another reason to change the base URL would be to have
non-request-based operations in Artifactory use the correct address,
for example in generated emails.
File Upload Max Size Maximum size allowed for files uploaded via the web interface.
Date Format (mandatory) The date format for displaying dates inside the web interface.
Global Offline Mode A global offline checkbox alerting Artifactory to act as if it is not
connected to an external network (such as the internet), and
therefore, not to query remote repositories (regardless of the offline
status of a single remote repository).
Look and Feel Settings (UI Branding)
In the Look and Feel Settings you can customize Artifactory with your own logo presented in both the upper left of the screen and footer text.
1.
2.
Logo URL Use an existing image on a remote URL
Logo File Upload a logo image using the Choose File button.
NOTE!that the uploaded file is copied into theARTIFACTORY_HOME
/etc/ui folder.
Additional Footer Text Input the desired text you want to add to the footer. This is a free text
field.
Add-on Settings
Mark thischeck-boxto control Artifactory's behavior in connection with the Artifactory Add-ons Power Pack.
The Server ID is used to activate the Artifactory Add-ons Power Pack on the current Artifactory server. You can leave it unchecked when
using the open source version and no add-ons are installed.
You can decide whether or not to show available add-ons information in Artifactory for add-ons you do not have installed.
Available add-on information typically looks like this:
As an admin, you can decide whether or not users see Add-on information.
that marking the Show Available Add-ons Info checkbox overrides any previous user-specific preference for NOTE!
hiding it (you are still able to choose to hide this information again, if desired).
This section provides details of the common controls available for each repository type.
Understanding Repositories
Configuring Repositories
Local and Remote Repositories
Local Repositories
Remote Repositories
Virtual Repositories
Understanding Repositories
Local, Remote and Virtual Repositories
Artifactory hosts two kinds of repositories:
Local
Remote
Both local and remote repositories can be aggregated under repositories to create controlled domains for artifacts resolution and search, virtual
as detailed in the following sections.
To access theRepositoriessettings of Artifactory, click on the Admin tab at the top of the viewing pane. In the left pane of the screen select Conf
The Configure Repositories options are displayed. iguration -> Repositories.
Repositories can be created, deleted, edited, ordered and aggregated.
To make changes visible you must save them first.
Local Repositories
Local repositories are physical, locally-managed repositories into which you can deploy artifacts.
Artifacts under a local repository are directly accessible via the following URL:
http://<host>:<port>/artifactory/<local-repository-name>/<artifact-path>
Artifactory is deployed with a number of pre-configured local repositories for deploying internal and external releases, snapshots and plugins.
Remote Repositories
A remote repository serves as a caching proxy for a repository managed at a remote URL (including other Artifactory remote repository URLs).
Artifacts are stored and updated in remote repositories according to various configuration parameters that control the caching and proxying
behavior. You can remove cached artifacts from remote repository caches but you cannot manually deploy anything into a remote repository.
Artifacts under a remote repository are directly accessible via the following URL:
http://<host>:<port>/artifactory/<remote-repository-name>/<artifact-path>
or
http://<host>:<port>/artifactory/<remote-repository-name>-cache/<artifact-path> (the second URL only serves
already-cached artifacts while the first one fetches a remote artifact in the cache, if it is not already stored).
Artifactory is deployed with preconfigured common remote repositories, which you can, of course, change.
Remote repository configuration can also be imported from another Artifactory instance. JFrog contains an up-to-date standard Public Repository
list of remote repositories available on the net.
A remote repository acts as a . Artifacts are not stored eagerly in remote repository caches, but are fetched and proxy as a mirror not
stored when they are requested by a client. on demand
Therefore, a remote repository should contain zero artifacts immediately after its creation.
A virtual repository (or "repository group") aggregates several repositories under a common URL. The repository is virtual in that you can resolve
and retrieve artifacts from it but you cannot deploy anything to it.
The Default Virtual Repository
By default, Artifactory uses a global virtual repository available at:
http://<host>:<port>/artifactory/repo
This repository contains all local and remote repositories.
Virtual Resolution Order
When requesting artifacts from a virtual repository, the search/resolution order is always: local repositories, remote repository caches
and finally remote repositories themselves. The order by which repositories of the same type (local, cache and
remote) are queried is governed by the order local, remote and virtual repositories are listed in the configuration
(see below).
Artifactory's virtual repository configuration includes a "Resolved Repositories" list view displaying the effective repositories order per virtual
repository. This is particularly helpful when nesting virtual repositories.
General Resolution Order
Managing the global configuration order is performed under the Admin tab and then . Configuration -> Repositories
You can reorder each list of repositories (local, remote, virtual) using drag-and-drop or select with the up and down arrow buttons. When your
order is complete, use the "Save" or "Reset" to cancel the reordering.
Repositories resolution is also affected by security privileges, include/exclude patterns and snapshots/releases handling policies.
Configuring Repositories
Overview
This section covers the controls that are common between all repository configurations.
Repository Key
Repository Key (mandatory) The repository identifier must be a valid , and be XML ID Name
unique for the whole Artifactory configuration data. Therefore,
repository keys cannot begin with a number. It is recommended to
suffix the local repository with "-local".
1.
2.
Description A free text field for providing a description of the content and purpose
of the repository. This assists user configuration, UI screens and
repository sharing.
Internal Notes A free text field to add additional notes about the repository.
Include and Exclude Patterns
It is extremely important to use Includes and Excludes patterns for repositories, particularly for remote repositories in order to:
Avoid looking-up remote artifacts on repositories that will never contain those artifacts or that contain only a limited range of group IDs.
Prevent disclosing sensitive business information derived from your artifact queries to whomever can intercept the queries, including the
owners of the remote repository itself.
As best practice, it is easier to manage the list of remote repositories used in an organization under one virtual repository (for example: remote-re
. pos)
In such a case, you can globally stop querying remote repositories for company artifacts by setting an exclude pattern on this virtual repository.
Include and exclude filtering is controlled by editing the Includes Pattern and Excludes Pattern values for a repository under the Admin Tab and
then . General -> Repositories -> Edit
Specify a comma separated list of Ant-like patterns to filter-in and filter-out artifact queries. Filtering works by subtracting the excluded patterns
(default is none) from the included patterns (defaults to everything).
Example:
The pattern below causesArtifactory to submit queries to the repository in question:
and but not for org/apache/maven/parent/1/1.pom com/acme/project-x/core/1.0/nit-1.0.jar com/acme/exp-project/cor
. e/1.1/san-1.1.jar
Includes Pattern: org/apache/**,com/acme/**
Excludes Pattern: com/acme/exp-project/**
Overview
This section covers the controls that are common between local and remote repositories.
Snapshots and Releases Handling Policy
You can configure whether a local or remote repository handles snapshots and/or releases artifacts.
The repository rejects deployments conflicting with this policy and does not participate in conflicting resolution
requests.
Checkbox Name Description
Handle Releases Whether the repository handles release artifacts.
Handle Snapshots Whether the repository handles snapshot artifacts.
Blacked Out It is possible, if required, to completely black-out a repository by
marking this checkbox.
A blacked-out repository does not participate in any artifacts
resolution and artifacts cannot be downloaded from it or deployed to
it.
Suppress POM Consistency Checks By default, Artifactory keeps your repositories healthy by refusing
bad POMs with incorrect coordinates (path).
If the information inside the POM groupId:artifactId:version
does not match the deployed path, Artifactory rejects the
deployment.
You can disable this behavior by marking the "Suppress POM
Consistency Checks" checkbox.
Allow Content Browsing Allows Unsafe Content Browsing and determines whether viewing file
content (e.g., Javadoc browsing, HTML files) directly from Artifactory
is allowed.
Allowing content browsing requires strict content moderation to make
sure malicious users do not upload content that is used to
compromise security. For example, to conduct cross-site scripting
attacks.
Local Repositories
Overview
This section covers the controls that are specific to local repositories.
Public Description Free text description of the repository.
This description also appears when selecting the repository in the
tree browser.
Internal Notes Optional free text description about this repository.
Includes Pattern Comma-separated list of artifact patterns to include when evaluating
artifact requests, in the form of x/y/**/z/*.
When used, only requests matching one the include patterns are
served. By default all artifacts are included (**/*).
Excludes Pattern Comma-separated list of artifact patterns to exclude when evaluating
By default no artifacts are excluded.
Repository Layout Select the layout that the repository should use for storing and
identifying modules.
Cheksum Policy Checksum policy determines how Artifactory behaves when a client
checksum for a deployed resource is missing or conflicts with the
locally calculated checksum (bad checksum).
Checksum checking effectively verifies the integrity of the deployed
resource.
There are two options:
(1) Verify against client checksums (default) - Until a client has sent a
valid checksum for a deployed artifact matching the server's locally
calculated checksum, the artifact's checksum is not available and
returns a 404 (not found) error. If the client has sent a checksum that
conflicts with the one calculated on the server a 409 (conflict) is
returned until a valid checksum is deployed.
(2) Trust server generated checksums - Do not verify against
checksums sent by clients and trust the server's locally calculated
checksums. An uploaded artifact is available for consumption
immediately, but integrity might be compromised.
Maven Snapshot Version Behavior Whether to use time-based version numbers for the name of
SNAPSHOTs, or to use a non-unique, self-overriding naming pattern
of artifactId-version-SNAPSHOT.type (the default), or to respect the
deployer settings coming from the Maven client.
Max Unique Snapshots The maximum number of unique snapshots (of the same artifact) to
store. Any number of snapshots above the max are automatically
removed by age.
A value of 0 (the default) indicates that there are no limits on the
number of unique snapshots (thus no automatic cleanup).
Blacked Out Whether the repository is blacked-out. A blacked-out repository does
not participate in artifact resolution, nor does its local cache.
Suppress POM Consistency Checks Whether the repository should suppress POM Consistency Checks.
Allow Archive Browsing Allow Unsafe Archive Content Browsing - Determines whether
viewing archive content (e.g., Javadoc browsing) directly from
Artifactory is allowed.
Allowing content browsing requires strict content moderation to
ensure malicious users do not upload content that is used to
compromise security. For example, to conduct cross-site scripting
attacks.
Centrally Controlled Maven Unique Snapshot Policy
Artifactory allows you centralized control of how snapshots are be deployed into a repository, regardless of end user-specific settings. This
guarantees standardized format for deployed snapshots within your organization.
1.
2.
Snapshot Version Behavior The available options are:
Non-unique snapshots
Unique snapshots - with unique time-stamp and build number
suffix
Deployer-respecting behavior - Artifactory respects the user
snapshot policy, i.e. act as a standard, non-smart, repository
Max Unique Snapshots Maximum number of unique snapshots to be deployed
Cleaning-up Unique Snapshots
You can configure Artifactory to automatically clean up old unique snapshots by setting the repository's value to the Max Unique Snapshots
maximum number of unique snapshots of an artifact that should be maintained in the repository. Clean up takes effect on each new snapshot
deployment.
Handling Deployed Client Checksums
Checksum policy determines how Artifactory behaves when a client checksum for a deployedresource is missing or conflicts with the locally
calculated checksum (bad checksum).
Checksum checking effectively verifies the integrity of the deployed resource.
The options are:
Verify against client checksums (default) - Until a client has sent a valid checksumfor a deployed artifact that matches the server's
locally calculated checksum, theartifact is unavailable and returns a 404 (not found) error message. If the client has sent achecksum
conflicting with the one calculated on the server, a 409 (conflict) error message is returned until a valid checksum is deployed.
Trust server generated checksums - Do not verify against checksums sent by clientsand trust the store
server's locally calculated checksums. An uploaded artifactis unavailable for consumption immediately, but
integrity might be compromised.
Pre-canned Repositories
Artifactory comes with a set of per-defined local repositories, which reflect binary management best practices.
Repository Name Purpose
libs-release-local Your code releases
libs-snapshot-local Your code snapshots
ext-release-local Manually deployed 3rd party libs (releases)
ext-snapshot-local Manually deployed 3rd party libs (shapshots)
plugins-release-local Your and 3rd party plugins (releases)
plugins-snapshot-local Your and 3rd party plugins (snapshots)
Maven 3 Only Supports Unique Snapshots
Maven 3 has dropped support for resolving and deploying non-unique snapshots. Therefore, if you have a snapshot repository using
non-unique snapshots, it is recommended to change your Maven snapshot policy to 'Unique' and remove any previously deployed
snapshot from this repository.
The unique snapshot name generated by the Maven client on deployment cannot help in identifying the
source control changes from which the snapshot was built and has no relation to the time sources checked
out. It is advised to have the artifact itself embed the revision/tag (as part of its name or internally) for clear
and visible revision tracking. Artifactory allows you to tag artifacts with the revision number as part of its Buil
d Integration support.
Remote Repositories
This section describes various aspects of managing remote repositories:
Managing Caches
Handling Offline Scenarios
Handling Checksums
Going Through Proxies
Advanced Settings
Importing Shared Configurations
Managing Caches
Overview
This section examines the settings used by remote repositories for deciding how to handle remote artifact requests.
When a remote artifact is stored in Artifactory, it is cached for a certain and controlled period of time. For Maven
artifacts, this is applicable only for snapshots, since releases are assumed never to change.
When Artifactory receives a request, where an artifact that its caching timeout has expired, Artifactory checks if there is an updated artifact
remotely.
Repository Layout Select the layout the repository to be used for storing and identifying
modules.
Remote Layout Mapping Select the layout that best matches the layout used by remote
repository for storing and identifying modules.
Path-mapping takes place if the remote layout is different from the
local layout - remote module artifacts and descriptors are stored
according to the local repository layout (e.g., Maven 1->Maven 2, or
Maven 2->Ivy).
Proxy Network proxy reference
Local Address The local address to be used when creating connections.
Useful for specifying the interface to use on multi-homed systems.
Username Enter the HTTP authentication username.
Password Enter the HTTP authentication password.
Socket Timeout This is the timeout period (for socket and connection) that Artifactory
waits for before giving up on retrieving an artifact from a remote
repository. After a timeout Artifactory caches the fact that a retrieval
failure has happened for the amount of time defined in "Failed
Retrieval Cache Period".
Artifactory answers future requests for that particular artifact withNOT
_FOUND(404) for a period of "Failed Retrieval Cache Period"
seconds and does not attempt to retrieve it it again until that period
expired.
Keep Unused Artifacts (Hours) Many cached artifacts in Artifactory remote repository storage are
actually unused by any current projects in the organization. To solve
this issue you can set an automatic removal of unused artifacts in
remote repository caches.
Retrieval Cache Period (Secs) Defines how long before Artifactory checks for a newer version of a
requested artifact in remote repository. Artifactory will not fetch
anything but the metadata if no newer version is found.
Assumed Offline Limit (Secs) The number of seconds the repository stays in assumed offline state
after a connection error. At the end of this time an online check is
attempted in order to reset the offline status.
A value of 0 means the repository is never assumed offline.
Missed Retrieval Cache Period (Secs) The number of seconds to cache artifact retrieval misses. A value of
0 means no caching.
A miss is a 404 response ( ) received from a remote NOT_FOUND
repository that currently does not have the artifact requested. You
might want to treat this differently than when failing to retrieve the
artifact is due to network problems.
Zapping Caches
You can clean up the Retrieval Cache by selecting a cached file or a folder in the Artifacts tab and then and clicking (or Tree Browser
selecting, if right-clicking the item) the "Zap Caches" action.
You can cleanup both the Retrieval Failures Cache and Missed Retrieval Cache by selecting a cached folder in Artifacts -> Tree
and clicking (or selecting, if right-clicking the item) the "Zap Caches" action. Browser
Timeout settings in many different locations were stringently tested before deciding on the default values.
It is therefore recommended not to change the defaults, unless there is a compelling reason to do so.
Handling Offline Scenarios
Overview
Artifactory supports two kinds of offline cases:
Organization-wide Offline - When the whole organization is disconnected from remote repositories
Single Repository Offline - When one or more remote repositories needs to be put offline.
Organization-wide Offline
In this case, remote repositories serve as caches only and do not proxy remote artifacts.
This is common in organizations using a separate secured network (such as military or financial institutes) and are disconnected from the rest of
the world.
You can turn the Global Offline Mode flat checkbox on (and off), under the Admin tab and then . Configuration -> General
Server Name A name uniquely identifying this Artifactory server instance across
the network.
Custom URL Base A hard-coded URL prefix used by Artifactory for calculating relative
URLs.
Use this only if you need to override the default URL base
(equals to the Servlet Context URL.
For Example: ). http://myhost.com/artifactory
File Upload Max Size The maximum size in megabytes for artifact files uploaded through
the web UI. Set to '0' for unlimited size.
Date Format The format to be used for displaying dates.
Global Offline Mode If this checkbox is marked, Artifactory never tries to fetch artifacts
remotely.
Only cached and local artifacts are served.
Single Repository Offline
A less rigid case is where one or more remote repository has gone offline for some reason.
In this situation, it is possible to configure Artifactory to treat the individual remote repository as offline, so that only artifacts already present in the
cache are used.
URL The URL for the remote repository. Currently only HTTP/S URLs are
supported.
Public Description Textual description of the repository.
This description also appearx when selecting the
repository in the tree browser.
Internal Notes Free text field for optional notes about this repository.
artifact requests, in the form of x/y/**/z/*. When used, only requests
matching one the include patterns will be served.
By default all artifacts are included (**/*).
By default no artifacts are excluded.
Checksum Policy Checksum policy determines how Artifactory behaves when a
checksum for a remote resource is missing or conflicts with the
locally calculated checksum (bad checksum).
Checksum checking effectively verifies the integrity of the remote
resource.
The options are:
(1) Generate if absent (the default) - A bad remote checksum fails
the resource request. If however, a remote checksum could not be
found, Artifactory automatically generates one.
(2) Fail: A bad or missing remote checksum fails the resource
request.
(3) Ignore and generate: Artifactory locally generates a checksum for
both a bad or missing remote checksum. Remote resource retrieval
never fails, but integrity might be compromised.
(4) Pass-thru: Artifactory stores and passes-thorugh all remote
checksums including bad ones and locally generates a checksum for
a missing remote checksum cannot be found.
Remote resource retrieval never fails, but integrity
might be compromised and client-side checksum
validation (such as that performed by Maven) fails.
Max Unique Snapshots The maximum number unique snapshots (of the same artifact) to
store.
Any number of snapshots above the max will be automatically
removed by age. A value of 0 (the default) means no limits on unique
snapshots number (thus no automatic cleanup).
Blacked Out Whether the repository is blacked-out. A blacked-out repository does
not participate in artifact resolution, nor does its local cache.
Share Configuration Whether or not the configuration details of this remote repository can
be publicly shared with remote clients, such as other Artifactory
servers.
Offline When this checkbox is marked only already-cached artifacts are
retrieved and fetching remote artifacts is not attempted.
Handling Checksums
Overview
Artifactory can help you block broken artifacts by activating checksum handling - Artifactory queries the remote checksum prior to storing the file
locally.
Configuring Checksum Policies
Using the configuration for a remote repository, you can select:
Recalculating bad checksums
Failing on bad checksums (blocking them)
Calculate only missing checksums
Accepting bad checksums.
Going Through Proxies
Overview
In corporate environments it is often required to go through a proxy server to access remote resources.
Artifactory supports both regular network proxies and NTLM proxies.
Defining Proxies
To use a proxy you must create a proxy definitionunderthe Admin tab and then . Configuration -> Proxies
Click New to create a new proxy. Fields that do not require any value in your setup can be left blank (e.g. if you are
not using authentication credentials or an NTLM proxy).
Proxy Key The unique ID of the proxy.
System Default Mark this checkbox to make this proxy the default for new remote
repositories and for internal HTTP requests.
Host The name of the proxy host.
Port The proxy port number.
Username The proxy username.
Password The proxy password.
NT Host The computer name of the machine (the machine connecting to the
NTLM proxy).
NT Domain The proxy domain/realm name.
Redirecting Proxy target Hosts An optional list of newline or comma separated host names to which
the proxy may redirect requests.
The credentials of the proxy are reused by requests redirected to any
of these hosts.
The following message appears when marking the "System Default" checkbox:
Click "OK" to assign this proxy to all remote repositories (see below).
If the proxy is defined as "System Default" Artifactory uses it for all HTTP queries not related to remote repositories
downloads. Only one system default proxy can be defined.
The optional redirecting proxy target hosts allows listing host names to which the proxy may redirect requests. The credentials of the proxy are
reused by requests redirected to any of these hosts.
Using Proxies
Advanced Settings
Overview
The Advanced Settings can be found under the Admin tab and then and then click on New or select an existing Configuration -> Repositories
A remote repository uses a proxy only if one is selected in the configuration panel for that repository. The "System Default" proxy
is assigned automatically when creating a new remote repository, but is not used by default.
A remote repository without a defined proxy does not use any proxy!
remote repository to edit.

Repository Layout Select the layout the repository to be used for storing and identifying
modules.
Remote Layout Mapping Select the layout that best matches the layout used by remote
repository for storing and identifying modules.
Path-mapping occurs if the remote layout is different to the local

layout - remote module artifacts and descriptors are stored according
to the local repository layout (e.g., Maven 1->Maven 2, or Maven
2->Ivy).
Suppress POM Consistency Checks Whether the repository should suppress POM consistency checks.
Proxy The network proxy reference.
Local Address The local address to be used when creating connections. Useful for
specifying the interface to use on multi-homed systems.
Username The HTTP authentication username.
Password HTTP authentication password.
Socket Timeout Network timeout in milliseconds to use both for connection establish
ment and for unanswered requests.
Timing out on a network operation is considered as a retrieval failure.
Keep Unused Artifacts (Hours) The numbers of hours to wait before an artifact is deemed "unused"
and eligible for cleanup from the repository.
A value of 0 means automatic cleanup of cached artifacts is disabled.
Retrieval Cache Period (Secs) The number of seconds to cache artifact lookup results. A value of 0
indicates no caching.
Assumed Offline Limit (Secs) The number of seconds the repository stays in assumed offline state
after a connection error.
At the end of this time an online check is attempted in order to reset
the offline status. A value of 0 indicates the repository is never
assumed offline.
Missed Retrieval Cache Period (Secs) The number of seconds to cache artifact retrieval misses (artifact not
found). A value of 0 indicates no caching.
Query Params Custom HTTP query parameters that are automatically included in all
remote resource requests.
For example: param1=val1&param2=val2&param3=val3
Eagerly Fetch Jars When selected, the repository attempts to eagerly fetch the jar in the
background each time a POM is requested.
Eagerly Fetch Sources When selected, the repository attempts to eagerly fetch the source
jar in the background each time a jar is requested.
Hard Fail Whether failing to communicate with this repository returns an error
to the client that causes the build to fail.
Do Not Store Artifacts Locally Whether the repository should store cached artifacts locally or not.
When not storing artifacts locally direct repository-to-client streaming
is used.
This can be useful for multi-server setups over a high-speed LAN,
with one Artifactory caching certain data on a central storage and
streaming it directly to satellite pass-though Artifactory servers.
List Remote Folder Items Lists the items of remote folders in simple and list browsing.
Required for dynamic resolution depending on remote folder content
information, such as remote Ivy version lookups.
The remote content is cached according to the value of 'Retrieval
Cache Period'
Synchronize Artifactory Properties Whether to synchronize properties of artifacts retrieved from a
remote instance of Artifactory.
Allow Archive Browsing Whether to allow unsafe archive content browsing - determines
whether viewing archive content (e.g., Javadoc browsing) directly
from Artifactory is permitted.
Allowing content browsing requires strict content moderation to make
sure malicious users do not upload content that is used to
compromise security.
For example: to conduct cross-site scripting attacks.
Reject Invalid Jar Archives Reject the caching of jar files that are found to be invalid.
For example: pseudo jars retrieved behind a "captive portal".
Accelerating Downloads
You can instruct a remote repository to automatically eagerly retrieve related artifacts, in parallel on the server-side, before requested by the
Maven client.
The options are:
Try and fetch a immediately when is queried. *.jar *.pom
Try and fetch a when is queried. *-sources.jar *.jar
Having these options activated speeds up first downloads by a factor.
Suppressing POM Consistency Checks
By default, Artifactory keeps your repositories healthy by refusing bad POMs deployed on remote repositories with wrong information.
Artifactory checks that the coordinates (path) of POMs retrieved remotely match the groupId:artifactId:vers
ion information inside the POM, and rejects POMs that conflict with their path.
You can disable this behavior by marking the 'Suppress POM Consistency Checks" checkbox.
Cleaning-up Unique Snapshots
If the remote repository managed unique snapshots names (the same has many jars and pom with date and groupId:artifactId:version
build number), you can configure Artifactory to automatically clean up old unique snapshots by setting the repository's Max Unique
value to the maximum number of unique snapshots of an artifact that should be maintained in the repository. Clean up takes effect Snapshots
each time a new snapshot file name is downloaded and cached.
Remote Repository Authentication
If a remote repository requires authentication you can provide a and as part of the repository definition. username password
Custom HTTP Query Parameters
Custom HTTP queries parameters that are automatically included in all remote resource requests.For example:
param1=val1&param2=val2&param3=val3
List Remote Folder Items
If you want to browse the contents of a remote repository that has not been cached yet, you can enable this checkbox. This allows to navigate
of the remote repository via the Simple Browser or List Browser. the contents
Proxying Maven 1 repositories
To proxy Maven 1 repositories, simply set the remote repository layout to Maven 1.
Connecting from Multi-homed Machines
If you are running Artifactory on a machine with multiple network interfaces and only specific interfaces can connect to remote repositories, you
can specify the interface you want to use for remote connections under the "Local Address" field.
Importing Shared Configurations

Overview
The Artifactory "Remote Repository Provisioning" feature allows you to share the configuration details of remote repositories between Artifactory
instances.
The Public JFrog Artifactory instance contains an up-to-date version of most of the common public repositories.
Sharing a Remote Repository Configuration
Go to the Admin tab and thenRepositories -> Remote Repositories -> Edit
The checkbox "Share Configuration" indicates to Artifactory to expose this remote repository configuration to another Artifactory instance.
When checked, all configuration parameters are shared from REST API queries except: Connection credentials
(username,password) and Proxy configuration.
Using Import in Remote Repositories Configuration
To create or update remote repositories with a shared configuration from another Artifactory, go to Admin -> Repositories -> Remote
. Repositories -> Import
You can enter the Artifactory root URL of the server exposing remote repositories configuration. By default it points to JFrog Public Repository.
Activating "Load" issues a request to the server.
A list of remote repositories can be selected and the repository key for each of them can be changed.
You can declare a remote repository with a URL pointing to yourself in order to offer access to your Artifactory. Be careful that this
remote repository is not usable.
If you have a "System Default" proxy defined, Artifactory uses it for performing this HTTP query.
1.
2.
3.
Important points to notice:
If the repository key already exists, the configuration of the existing remote repository is modified.
If HTTP proxy is used, each of the new repository must be associated with the local proxy definition.
You must add new remote repositories to existing virtual repositories so they are visible to virtual repository requests.
1.
2.
3.
4.
Overview
Artifactory allows you to define a virtual repository which 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 with 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:
Nesting
Include Exclude patterns filter
Automatic removal of repository references
WebStart automatic signing and JNLP file conversion
Setting Up a Virtual Repository
From the Admin tab go to and create a new virtual repository. Configuration -> Repositories -> Virtual Repositories
Add the repositories you want 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) is displayed and automatically updated.
1.
2.
3.
The search/resolution order when requesting artifacts from a virtual repository is always:
Local repositories
Remote repository caches
Remote repositories themselves.
Public Description Free-text field description of the repository.
This description also appears when selecting the repository in the
tree browser.
Internal Notes Free-text field for optional notes about this repository.
When used, only requests matching one the include patterns are
served.
By default, all artifacts are included (**/*).
By default, no artifacts are excluded.
Repositories A set of local and remote repository references to include in a virtual
repository.
Resolved Repositories The resolved list of repositories.
Repositories beginning with an exclamation mark ('!') indicate that not
all tokens can be mapped between the layout of this virtual repository
and the marked repository.
Path translations may not work as expected.
Nesting Virtual Repositories
The ability to nest virtual repositories is unique to Artifactory. It allows for greater reuse of virtual repositories between themselves.
Include Exclude Patterns in Virtual Repositories
The coupling of Include/Exclude patterns of Artifactory to virtual repositories nesting provides a powerful feature. Configuring Repositories
You can define in a single virtual repository "remote-repos" the company groupId exclusion, and it ensures that no
requests for internal artifacts are sent externally.
Another example for this feature, is defining virtual repository for a project and filter undesirable groupId, sources or versions, that are not visible
to developers.
Serving Requests from Other Artifactory Instances
By marking the 'Artifactory Requests Can Retrieve Remote Artifacts' checkbox, 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.
Artifactory detects when overly nesting repositories enter an infinite loop and warns against it.
To control remote artifacts resolution for other Artifactory instances for the global virtual repository 'repo', you must use the artifact
system property, which is set to by default. ory.artifactoryRequestsToGlobalCanRetrieveRemoteArtifacts false
Repository Layout Select the layout that the repository should use for storing and
identifying modules.
Artifactory Requests Can Retrieve Remote Artifacts Mark this checkbox to determine whether artifact requests arriving
from other Artifactories can be fulfilled by accessing this virtual
repository's remote repositories or by only accessing its caches (the
default).
Cleanup Repository References in POMs (1) Discard Active References - Removes repository elements that
are declared directly under project or under a profile in the same
POM. By default, this is active.
(2) Discard Any References - Removes all repository elements
regardless of whether they are included in an active profile or not.
(3) Nothing - Does not remove any repository elements declared in
the POM.
Key Pair A named key-pair to use for automatically signing artifacts.
Zap Caches Clears all caches stored at the virtual repository level (transformed
POMs, JNLP files, merged indexes, etc.)
Ensuring Artifactory is Your Sole Artifacts Provider
One very bad practice often used on public POMs, is to add a direct reference to an external repository in a POM. When either of the code
examples below are present, Maven dynamically adds an external repository URL to the build. This shortcuts Artifactory.
1.
2.
3.
<project><repositories><repository>
or
<project><pluginRepositories><pluginRepository>
Until now, the solution was using mirrorOfas described here.
Artifactory provides at the virtual repository level, an automatic cleanup of POM file. Three levels of cleanup policy are configurable:
Discard Active References - Removes repository elements that are declared directly under project or under a profile in the same pom
that is activeByDefault.
Discard Any References - Removes all repository elements regardless of whether they are included in an active profile or not.
Nothing - Does not remove any repository elements declared in the POM.
Pre-canned Repositories
Artifactory comes with a set of per-defined virtual repositories, which reflect binary management best practices.
Repository Name Purpose
remote-repos Aggregation of all remote repositories
lib-releases libs-releases-local, ext-releases and remote-repos
plugins-releases plugins-releases-local, ext-releases and remote-repos
libs-snapshots libs-snapshots-local, ext-snapshots-local, remote-repos
plugins-snapshots plugins-snapshots-local, ext-snapshots-local, remote-repos
repo Aggregation of all repositories
Managing Security
Overview
Artifactory offers a strong security model.
It allows you to:
Assign role-based or user-based permissions to areas in your repositories (called Permission Targets)
Allow sub-administrators for these areas
Configure LDAP out-of-the-box
Prevent clear text in your Maven's settings.xml
Inspect security definitions for a single artifact or folder and more.
Artifactory's security is based on Spring Security and can be extended and customized.
This section explains the strong security aspects and controls offered by Artifactory:
Managing Users
Managing Groups
Managing Permissions
Managing Security with LDAP
Centrally Secure Passwords
Access Log
Managing Users
Overview
Artifactory user management is available under the Admin tab and then . Security -> Users
An administrator must create users (unless external authentication, such as LDAP is active) and assign each user roles and permissions.
Creating and Editing Users
Create a new user by clicking the New button next to the users table.
Unchecking the "Can Update Profile" checkbox prevents a user from updating his profile details. This can be useful, for example, for creating a
shared departmental user, with a single password shared between all department members. Only an administrator can update the password.
When external authentication, such as LDAP, is active you can disable the fallback to use an internal password by checking the "Disable Internal
Password" checkbox.
Administrator Users
An administrator user is to Artifactory as a root is to UNIX systems. Administrators are not subject to any security restrictions. It is therefore
recommended to create a minimum number of administrators.
You can always create less powerful, per-permission-target, administrators inside Artifactory (responsible for a specific repository path). See the
section. Permissions Management
The Anonymous User
Artifactory supports the concept of anonymous users.
A built-in, unmodifiable 'anonymous' user exists in Artifactory and can be assigned permissions, as any regular
user. A global "Allow Anonymous Access" checkbox controls whether this 'anonymous' user is active or not, and
must be marked before you can fine tune the anonymous user permissions.
Anonymous access is activated by default. It can be deactivated by going to the Admin tab and thenSecurity ->
General:
Passwords are always stored as hashes or encrypted hashes inside Artifactory.
The Default Admin Account
The default user name and password for the built-in administrator user are: . admin/password
You should change the password after first log in. It is possible to recover the default admin account by following these . instructions
When the global Allow Anonymous Access is marked, anonymous download requests can download cached artifacts and populate caches,
regardless of other permissions definitions.
User Management
Other user management functions such as editing, removing and assigning groups to selected users are performed under the Admin Tab and
thenSecurity -> Users
Recreating the Default Admin Account
Obtaining A Security Configuration File
If your instance of Artifactory is configured to perform backups, you can find the file at the top backup directory. Otherwise, see security.xml
here
To amend the secuirty.xml file:
1.
2.
3.
1.
2.
1.
2.
Make a copy of this file
Open it with a text editor
Change the admin's "password" field, as follows:This is 'password' in hash and set it aside.
<password>5f4dcc3b5aa765d61d8327deb882cf99</password>
that if no backup is available, contact JFrog for further assistance. NOTE!
Forcing export of security.xml file
Remove the following file and restart Artifactory:
$ARTIFACTORY_HOME/data/.deleteForSecurityMarker
Make sure to let the Artifactory startup process finish with no interruption, you have the security.xml file with the current timestamp
inside$ARTIFACTORY_HOME/etc/security.<timestamp>.xml
No other operation required once startup has completed.
Resetting The Password
To reset the password:
Take the modified security configuration file and place it under $ARTIFACTORY_HOME/etc
Rename it to:
security.xml for versions 2.0.6 - 2.0.8.
security.import.xml for versions 2.1.0 - latest.
Restart Artifactory
The admin password is reset.
Managing Groups
Overview
Groups are managed in Artifactory from the web user interface under the Admin tab and then . Security -> Groups
Create a new group by clicking the New button next to the groups table.
A group is a role in Artifactory and is used with RBAC (Role-Based Access Control) rules.
Default Groups
When creating (or editing) a group you can mark it as a default group to which all newly-added users from this point auto-join.
This is particularly useful when using external authentication such as LDAP, where users are automatically created
on successful login and you want them to automatically be part of a certain group.
Managing Permissions
Overview
Artifactory allows you to manage permissions via Permission Targets. A permission target is a concept that denotes a physical (non-virtual)
repository and includes and excludes patterns in the repository together with a set of permissions.
Multiple permissions for groups or users can be attached to a single permissions target, hence ACLs,
An example permission target:
The repository target containing all files (by include/exclude patterns) under the 'libs-releases' repository has read
and deploy permissions for the user 'Builder' and for the group 'Deployers'.
Permissions Management
You can create, edit and delete permission targets and permissions from the permissions page. Got to the Admin tab and then Security ->
. Permissions
Creating a Permission Target
When creating a permission target, select the repositories the permission target is applicable to.
Select multiple include and exclude patterns in Ant-like format. The combination of these patterns constitute the set of paths to be governed by
this permission target. In the example below, sources are specifically excluded from the permissions.
Use the dropdown lists to insert common predefined include and exclude patterns and customize them to suit your requirements.
Finally, select the Groups and Users you want to grant/revoke permissions for. There are five possible permissions:
Read - Allows reading/downloading artifacts.
Annotate - Allows annotating artifacts and folders with metadata and properties.
Deploy - Allows deploying artifacts and deploying to caches (populate them with remote artifacts).
Delete - Allows deleting or overwriting artifacts.
Admin - Allows adding permissions to other users on this permission target.
Permission Target Admins
Permission Target administrators are local administrators to the specific permission target. They can assign new permissions on the permission
target to other users or groups. Upon logging-in to the web application, these users have access to the specific section they allowed to
administer.
This set up is extremely useful if you have a multi-team site and you want to delegate to teams the role of managing
their repositories.
An anonymous user cannot be permission target administrator.
Preventing Overwriting Deployments
The Delete permission can be used to prevent overwriting a deployed release or unique snapshot. Non-unique snapshots can always be
overwritten (as long as the Deploy permission is on).
Examining Permissions
By Arifact/Path
To examine the effective permissions of any item select it in the Tree Browser from the Artifacts tab and then and select the Tree Browser
Effective Permissions tab.
By User
You can also select a specific user from the user management panel. Go to the Admin tab and then to view the Security -> Users
permission targets the user is part of (directly or by group association).
Permissions are additive and negative (actions not specifically granted are forbidden).
Only users and groups with the assigned permissions appear. If you do not see a user or a group in the table, they do not have any
permissions on the selected item.
Managing Security with LDAP
LDAP Authentication
Artifactory OSS has out-of-the-box support for authenticating users against an LDAP server.
When LDAP authentication is active, Artifactory first attempts to authenticate the user against the LDAP server. If
the LDAP authentication fails, Artifactory tries to authenticate via its internal database.
For every LDAP authenticated user Artifactory creates a new user in the internal database, if that user does not already exist, Artifactory assigns
the user the default (auto-join) groups.
Configuration
LDAP authentication is configurable. Go to the Admin tab and then . Security -> LDAP Settings
The configuration parameters for connecting to LDAP are:
Parameter Name Description
Settings Name The unique ID of the LDAP setting.
Enabled Mark the checkbox to changet the setting to "Enabled".
Managing Permissions for LDAP Groups
Artifactory can synchronize your LDAP groups and leverage your existing organizational structure when managing group-based
permissions. LDAP groups in Artifactory use super-fast caching and has support for both Static, Dynamic and Hierarchical mapping
strategies.
Powerful management is accomplished with multiple, switchable LDAP settings and visual feedback about the up-to-date status of
groups and users coming from LDAP.
The feature is bundled as one of the Add-ons in the Artifactory Power Pack. LDAP Groups
1.
2.
3.
4.
LDAP URL Location of the LDAP server in the form of:ldap://myserver:myp
ort/dc=sampledomain,dc=com.
It should include the base DN for searching and/or authenticating
users.
User DN Pattern A DN pattern used to directly login users to the LDAP database. This
pattern is used for creating a DN string for "direct" user
authentication, where the pattern is relative to the base DN in the
LDAP URL.
The pattern argument { } is replaced with the username in runtime. 0
This works only if anonymous binding is allowed and a direct user
DN can be used (which is not the default case for Active Directory).
For example:
uid={0},ou=People
Search Filter A filter expression used to search for the user DN that is used in
LDAP authentication.
This is an LDAP search filter (as defined in 'RFC 2254') with optional
arguments. In this case, the is the only argument, username
denoted by . '{0}'
Possible examples are:
- this would search for a username match on the uid uid={0})
attribute.
Authentication to LDAP is performed from the DN found if successful.
Search Base Context name to search in, relative to the base DN in the ldapUrl.
This is parameter is optional
Manager DN Used only with "search" authentication method. It is the DN of the
user who binds to the LDAP server to perform the search.
Manager Password Used only with "search" authentication method. It is the password of
the user who binds to the LDAP server to perform the search.
Search Sub Tree Flag to enable deep search through the sub tree of the ldapUrl +
searchBase. True by default.
Auto Create Artifactory Users Whether or not to automatically create new users in Artifactory for
logged-in LDAP users and assign them default auto-join groups.
Avoiding Clear Text Passwords
Storing your LDAP password in clear text in on your disk is a big security threat, since this password is very sensitive and is settings.xml
used in SSO to other resources on the domain.
We strongly recommend, especially with LDAP, to use in your local settings. Artifactory's Encrypted Passwords
Preventing Authentication Fallback to the Local Artifactory Realm
As an administrator you might want users to authenticate only through LDAP with their LDAP password. However, if a user already has an
account in the internal database with a password, Artifactory utilizes fallback to use his database password when his LDAP password failed.
To prevent this scenario you can edit the specific user. Go to the Admin tab and then Security -> Users) and check
the Disable Internal Password checkbox.
Using LDAPS (Secure LDAP)
To use LDAPS, your LDAP server must have a valid certificate from a CA trusted by Java. No other setting is required, except using a secure
LDAP URL in your settings, e.g. ldaps://secure_ldap_host:636/dc=sampledomain,dc=com
However, if you want to use LDAPS with a non-trusted (self-signed) certificate, please follow these steps (thanks to Marc Schoechlin for
providing this information):
Download the CA of the ssl secured ldap server
openssl s_client -connect the.ldap.server.net:636 -showcerts > server.ca
Identify the CA certificate and keep only the ascii-text between BEGIN/END CERTIFICATE maker
Identify the standard file of your Java installation cacerts
Create a custom file by copying the file to the Artifactory configuration dir, e.g. cacerts cacerts
4.
5.
6.
7.
8.
1.
2.
3.
1.
cp /usr/lib64/jvm/java-1_6_0-ibm-1.6.0/jre/lib/security/cacerts /etc/artifactory
Import the CA certificate into the cacerts file customized
keytool -import -alias myca -keystore cacerts -trustcacerts -file server.ca
=> Password: changeit
=> Aggree for adding the certificate
Change permissions for the user artifactory
chown 755 /etc/artifactory/cacerts
chown artifactory:users /etc/artifactory/cacerts
Modify the defaults of the Artifactory JVM to use the custom file cacerts
echo "export JAVA_OPTIONS=\"\$JAVA_OPTIONS -Djavax.net.ssl.trustStore=/etc/artifactory/cacerts\"" >>
/etc/artifactory/default
Restart Artifactory
Centrally Secure Passwords

Overview
Using clear text passwords in your file, which is Maven's default, is a security risk. settings.xml
This situation worsens if you use LDAP or other authentication integration, since you expose your SSO password in
clear and that password is likely to be used for other services, not just Artifactory.
Using Maven's built-in support for encrypted passwords, by generating passwords on the client side, does not improve the situation:
Login password is decrypted on the client side and ends up in clear text in memory, and when transmitted over the wire (unless forcing
SSL too).
The master password used for decryption is stored in clear text on the file system.
Password encryption is left to the good will of the end-user and there is no way to centrally mandate it.
Artifactory provides a unique solution to this problem by generating encrypted passwords for users based on secret keys stored in Artifactory.
You can ensure users' shared passwords are never stored or transmitted as clear text.
You can also set a central policy for using or accepting encrypted passwords. Go to the Admin tab and then : Security -> General
Using Your Secure Password
To secure your password:
Manager DN
For constructing the Manager DN string according to your
Active Directory server,
navigate to the Administrator user (1),
and than construct the Manager DN in reverse order (2,3) from
the User, up the folder hierarchy.
For example, in this simple configuration, the Manager DN here
should be
cn=Administrator,cn=Users,dc=alljfrog,dc=org
Notice that the domain (3) is splited in reverse order to
dc=alljfrog,dc=org
1.
2.
3.
Open your profile page (click on your login name on the upper-right corner) and type-in your current password.
Enter a correct password. Yourpassword is in the Encrypted Password field.
Copy this value (including the {...} prefix) or use the sample xml snippet in your (you must change the server server settings.xml
name to match the ID of your repository).
Access Log
The Artifactory access.log
Artifactory maintains an access log containing all security-related events, their source IP and context. Events include accept/reject information
regarding logins, artifact downloads and browsing and artifact deployments.
The access log is located at . $ARTIFACTORY_HOME/logs/access.log
You can also view and download the access log from Artifactory's UI, by going to the Admin tab and then Advanced -> System Logs.
1.
2.
3.
4.
IBM JDK Encryption Restrictions
Some of the IBM JRE/JDK are shipped with a restriction on the encryption key size (mostly for countries outside the US); This
restriction can be officially removed by downloading unrestricted policy files from IBM and overriding the existing ones:
Register and download the unrestricted JCE policy files from: https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?
. source=jcesdk
Select the correct zip that matches your JAVA version.
The downloaded zip file contains 2 jar files - local_policy.jar and US_export_policy.jar. Backup the existing files in
$IBM_JDK_HOME/jre/lib/security and extract the jars from the zip file to this location
Restart Artifactory
Watches
You can also choose to receive focused information about repository events for a specific repository section, using the . Watches Add-on
Managing Backups
Backups
You can automatically and periodically backup the entire Artifactory system. The backup process creates a time-stamped directory
in the target backup directory.
To define multiple backups go to the Admin tab and then . Services -> Backups
Each backup may have its own schedule and repositories to either process or exclude.
Backup content is stored in standard file system format and can be loaded into any repository, so that Artifactory never locks you out.
Backup Key
Cron Expression To control backup frequency. Backup works by specifying a validCro
expression. For example, to back up every 12 hours use a value of: n
0 0 /12 * * ?
Next Time Backup When the next backup is due to take place.
Backup Directory The directory to which backup local repository data as files.
The default is $ARTIFACTORY_HOME/backup/[backup_key]
Sent Mail to Admins of there are Backup Errors It is possible to select that any problem encountered during backup
will be automatically reported to all Artifactory administrators by
email.
Exclude Builds Exclude all builds from the backup.
Retention Period You can have Artifactory automatically clean up old backups for you
and free valuable disk space by defining a retention period for your
backups. This of course is only applicable for backu non-incremental
ps only.
For example, to keep backups for up to a week max, use a value of
168 (hours).
Incremental checkbox Artifactory supports backing up incrementally to the same directory
(named ' ') in the target backups dir. This type of backup current
only writes deltas to the output dir, resulting in extremely fast
backups.
The backup files can be used by any incremental
file-system based backup utility (such as rsync).
Activate incremental backup by selecting the "Incremental" checkbox
under the advanced backup configuration.
Backup to a Zip Archie (Slow and CPU Intensive) Backups are created by default under the$ARTIFACTORY_HOME/ba
ckup/<backup_key>directory.
If you want to use another directory for storing backups, change the
target directory, otherwise leave it empty and use the defaults.
Importing and Exporting
Overview
Artifactory supports import and export of data at two levels:
System level
Repository level.
At , Artifactory can export and import the whole Artifactory server - configuration, security information, stored data and metadata. system level
The format used is identical to the format. This is useful for manually running backups and for migrating and restoring a complete System Backup
Artifactory instance (this is an alternative for using database level backup restore).
At , Artifactory can export and import repository stored data and metadata. This is useful for moving store data, including its repository level
metadata between repositories and for batch population of a repository.
System Import and Export
System import and export can be accessed from the Admin tab and then Import & Export -> System
Do not store any custom files under the target backup
directory, since the backup cleanup processes may wipe
them!

Target Export Dir Browse to select the directory to be exported
Exclude Content Exclude repository binaries from the export
Exclude Metadata Check to exclude repositories metadata from the export.
(Maven 2 metadata is unaffected by this setting)
Exclude Builds Exclude all builds from the export
Create .m2 Compatible Export Include Maven 2 repository metadata and checksum files as part of
the export
Create a Zip Archive (Slow and CPU Intensive!) Creates a Zip Archive
Output Verbose Log Lowers the log level to debug and redirects the output from the
standard log to the import-export log.
that you can monitor the log in the page. NOTE! 'System Logs'
The source/target of the import/export operations are folders (Zip archives are not recommended) on the Artifactory
server itself.
You can use the built-in server-side browsing inside Artifactory to select server-side source/target folders:
Repositories Import and Export
System import and export can be accessed from the Admin tab and then Import & Export -> Repositories
Importing or exporting a large amount of data may take some time to complete. It is not necessary to watch the page and wait for the
operation to finish, you can view the logs to determine when import/export completed.
(Go to the Admin tab and then ). Advanced -> System Logs
You can either export and import to and from server-side folders (browsable though Artifactory - see above), or import a repository by zipping it
and uploading it to Artifactory.
You can also import directly into caches and can take your local Maven repository and upload it into Artifactory to make all your
already-locally-stored artifacts available on the server. You can choose whether to import multiple repositories ('All Repositories') or a single
repository.
Import Layout
The expected layout of an imported repository is in the format of a Maven 2 repository layout.
When importing a single repository, the file structure within the folder your selection should be similar to:
SELECTED_DIR
|
|--LIB_DIR_1
When importing all repositories, the file structure within the folder your selection should be similar to:
SELECTED_DIR
|
|--REPOSITORY_NAME_DIR_1
| |
| |--LIB_DIR_1
Mail Server Configuration
Overview
Some features in Artifactory require sending outgoing mail to recipients. These features include:
Watch notifications
Alerts for backup warnings and errors
License violation notifications etc.
A mail server must be properly configured in Artifactory to enable the sending of mails.
Setup
The mail server configuration is available from the Admin tab and then . Configuration -> Mail
Set-up is straightforward and can be verified by sending a test mail message from the Configure Mail window, by clicking on Sent Test Mail.
Host The host name of the mail server.
Port The port of the mail server.
Username The authentication username.
When importing all repositories, ensure the names of the directories representing the repositories in the archive match the names of
the target repositories in Artifactory.
Password The authentication password.
From The "from" address header to use in all outgoing mails.
This field can be left blank.
Subject Prefix A prefix to use for the subject of all outgoing mails.
Use TLS Determines whether to use Transport Layer Security when
connecting to the mail server.
Use SSL Determines whether to use Single Sign-On when connecting to the
mail server.
Test Message Recipient Enter the email address of a recipient to send a test message.
Configuration Files
Configuration Files Location
All Artifactory configuration files are located under the folder. $ARTIFACTORY_HOME/etc
On UNIX is usually a soft link to . $ARTIFACTORY_HOME /etc/artifactory
Specific Configuration Files
The following sections contain detailed information regarding the different configuration files used by Artifactory at bootstrap time:
Global Configuration Descriptor
Security Descriptor
System Properties
Global Configuration Descriptor
artifactory.config.xml
The global Artifactory configuration file is located in . $ARTIFACTORY_HOME/etc/artifactory.config.xml
The artifactory.config.xml file is loaded by Artifactory on startup.
The initial configuration bundled with Artifactory contains a sensible defaults configuration that can be changed via the Administration page.
Once Artifactory loads the file, it renames the original file to , and from artifactory.config.xml artifactory.config.bootstrap.xml
here on, configuration is stored internally in Artifactory's storage. This ensures Artifactory configuration and data are coherently
stored in one place. It also makes it easier to back up and move Artifactory when using direct database backups.
On every startup, Artifactory also writes the current configuration it loaded with to the $ARTIFACTORY_HOME/etc/artifactory.config.sta
file as a backup. rtup.xml
Direct Use of the Global Configuration Descriptor
The raw global configuration descriptor itself can be retrieved and manipulated through Artifactory's configuration or by using Artifactory's REST
API.
Getting or Saving the Global Configuration Descriptor through the UI
Go to the Admin tab and then and copy the security configuration from the text field. Advanced -> Config Descriptor
Directly editing the global configuration descriptor is an advanced feature that can wipe all your configuration! Make sure you know
what you are doing and keep a backup of the configuration.
Retrieving and Saving the Global Configuration Descriptor through REST API
To retrieve configuration send a request to , e.g.: GET http://<host>:<port>/artifactory/api/system/configuration
curl -u admin:password -X GET -H "Accept: application/xml"
http://localhost:8080/artifactory/api/system/configuration
To set configuration send a request to with the configuration POST http://<host>:<port>/artifactory/api/system/configuration
data, e.g.:
curl -u admin:password -X POST -H "Content-type:application/xml" --data-binary
@artifactory.config.xml http://localhost:8080/artifactory/api/system/configuration
NOTE!that you must provide admin privileges with the request.
Bootstrapping Artifactory's Configuration
It is possible to bootstrap Artifactory with predefined global configuration by creating a $ARTIFACTORY_HOME/etc/artifactory.config.im
file containing the Artifactory configuration descriptor. port.xml
Once Artifactory sees this file at startup, it uses the information in the file to its global configuration. override This is useful if you want to
copy configurations between different Artifactory instances.
Security Descriptor
Direct Use of the Security Configuration Descriptor
The raw security configuration descriptor itself can be retrieved and manipulated through Artifactory's configuration or by using Artifactory's
REST API.
Getting or Saving the Security Descriptor through the UI
Go to the Admin tab and then and copy the security configuration from the text field. Advanced -> Security Descriptor
Getting and Saving the Security Descriptor through REST API
To retrieve configuration send a request to , e.g.: GET http://<host>:<port>/artifactory/api/system/security
curl -u admin:password -X GET -H "Accept: application/xml"
http://localhost:8080/artifactory/api/system/security
To set configuration send a request to with the configuration data, POST http://<host>:<port>/artifactory/api/system/security
e.g.:
curl -u admin:password -X POST -H "Content-Type: application/xml" --data-binary
@artifactory.config.xml http://localhost:8080/artifactory/api/system/security
NOTE!that you must provide admin privileges with the request.
Bootstrapping security using security.import.xml
Artifactory stores all security-related information as part of its internal storage. It is possible to bootstrap Artifactory with predefined security
configuration by creating a file that contains Artifactory-exported security information. $ARTIFACTORY_HOME/etc/security.import.xml
Directly editing the security configuration descriptor is an advanced feature that can wipe all your security configuration! Make sure you
know what you are doing and keep a backup of the configuration.
Once Artifactory sees this file at startup, it uses the information in the file to all security settings. This can be useful if you want to copy override
security configuration between different Artifactory instances.
System Properties
artifactory.system.properties
Artifactory includes a convenient method for specifying system properties. Rather than configuring properties in the JVM runtime configuration of
the hosting container, you can edit the file and restart Artifactory. $ARTIFACTORY_HOME/etc/artifactory.system.properties
Artifactory-specific properties start with the prefix and their meaning is documented in comments in the default artifactory. artifactory.s
file which can be found in the above path. ystem.properties
As these settings impact the entire container VM, it is recommended to use this feature primarily for specifying Artifactory-related properties only
(such as changing the database used by Artifactory, etc.).
Exposing Maven Indexes
Overview
Artifactory exposes Maven indexes for use by Maven integrations of common IDEs (IntelliJ IDEA, NetBeans, Eclipse).
Indexes are fetched remotely for remote repositories that provide them (many do not, or do not keep an updated index) and are calculated for
local and virtual repositories.
If Artifactory cannot find a remote index, it calculates one locally, based on the remote repository's previously cached artifacts.
Usage
To administer Maven indexes go to the Admin tab and then . Services -> Indexer
You can control how often local indexing calculation and remote index fetching runs and what repositories are included in index calculation.
Setting properties in is an advanced feature and is typically not required. artifactory.system.properties
Do not confuse these setting with those in the $ARTIFACTORY_HOME/data/artifactory.properties
file, which are for internal use.
Artifactory's search and indexing facilities are not related to Maven indexes
The indexing performed by Artifactory is secure, immediately effective and supports a larger variety of search options, including
custom metadata searches.
Maven indexes exist in Artifactory for the purpose IDE integrations only and are calculated periodically, contain a limited set of data
and are non-secure by design.
Information about the content of a repository is exposed to anyone with access to the repository's index, regardless of any effective
path permission you have in place. If this is a concern, do not expose an index for that repository.
1.
Clustering Artifactory
Artifactory Active/Passive Architecture
Overview
Artifactory Active/Passive architecture allows achieving High Availability (HA) and fast disaster recovery.
Artifactory supports two types of HA architectures
Deployment on fault-tolerant storage
Periodical cross-server data sync.
The first option is strongly recommended.
Deployment on Fault-tolerant Storage
Using a fault-tolerant disk mounted on another machine allows fast recovery with short MTR (Mean Time to Recovery). Once Artifactory is
deployed on NAS or SAN it becomes highly available as long as the other machine can immediately mount the storage, bootstrap Artifactory
from it and start accepting requests and not from the failing one.
To achieve this setup quickly and efficiently, it is recommended to use the built-in Virtual Machine Failover feature offered by virtualization
software providers as part of their HA solution.
Indexing can be expensive
NOTE! that calculating and indexing for a repository may be a resource-hungry operation, especially for a large local repository or if
the repository is a virtual one containing other underlying repositories. Therefore, do not include repositories that do not require
indexing for the period index calculation.
1.
2.
3.
1.
2.
Create a VM image that runs the Artifactory startup script and mounts the HA storage
The storage should contain the Artifactory installation and data (everything under $ARTIFACTORY_HOME)
Use the VM image on two Virtual Machines and have Artifactory running on one machine while the other
machine is readily available as a failover target by the virtualization HA monitor.
Cross-server Data Synchronization
In case this is not possible (or redundancy is required), fault-tolerance can be achieved by correctly replicating the data folder to a warm standby.
The setup of up-to-date passive replication server for active Artifactory server requires database replication and file system directories sync.
Syncing the Data and Configuration Directories
It is required to rsync two directories under $ARTIFACTORY_HOME: data and etc.
To achieve this, perform the rsync command on $ARTIFACTORY_HOME, excluding the directories that are not required.
Set out below is a simple example of such a command:
/usr/bin/rsync -vvah --del --progress --log-file=/home/replication/replication.log
--exclude-from=rsync-excludes.txt
artifactory@active-artifactory-host:$ARTIFACTORY_HOME/ $ARTIFACTORY_HOME/
In such a case the rsync-excludes.txt file appears as follows:
/work/
/data/tmp*/
/data/cache/
/logs/
NOTE!that the rsync should be executed from the passive stand-by server.
Syncing the Database
NOTE! that the database replication must run executing rsync. before
Each database provides its own procedures for the sync. Please consult the specific database vendor documentation for further reference.
For example, MySQL Replication HowTo guide can be found . here
It is also possible to use a full dump/restore procedure on the database to synchronize the database and filestore state. In this situation, it is
recommended to perform the dump in a single routine with rsync (in case of File System Storage Types).
Time Synchronization on Standby Server
Time synchronization on the standby serveris very important to sync timewise between the metadata stored in the database and the data stored
on the file system.
A straightforward method to achieve this, is to make sure the database is in a state that is to the file system (data/filestore) state. prior
This allows you to:
Make a database dump before executing filesystem sync,
Activate database replication on demand just before executing rsync.
Since the sync operations are not atomic, there might be a gap between the data from rsync and data from database replication.
The following should be noted:
The time snapshot that Artifactory is set to is the database replication time.
Items synced to the filesystem which have no representation in the database can be purged by clicking on Prune Unreferenced Data
2.
from the Admin tab and then in the Artifactory configuration. Advanced -> Maintenance
The Artifactory Log Files
Overview
Artifactory log files are found under the folder. ARTIFACTORY_HOME/logs
The following log files are available:
artifactory.log - The main Artifactory log file containing output about the Artifactory server activity.
access.log - Security log containing important information about accepted and denied requests, as well as configuration changes,
password reset requests etc., including the originating IP address for each event.
request.log - Generic http traffic information, similar to the Apache HTTPd request log.
import-export.log - A log used for tracking the process of long-running import and export commands.
Configuring Log Verbosity
Artifactory relies on the for its logging. Logger configuration can be changed in the Logback file: Logback Framework ARTIFACTORY_HOME/etc
. /logback.xml
Viewing Log Files from the UI
Artifactory supports monitoring log files from the configuration, as well as downloading the current log files from the browser.
Log files are viewable from the Admin tab then . You can select which log to tail or download from the drop-down Advanced -> System Logs
menu.
Tomcat/Servlet container-secific log files
When running Artifactory inside an existing servlet container, the container typically has its own log files.
These files normally contain additional information to that in or application bootstrapping-time information that is artifactory.log
not part of the Artifactory logs.
In Tomcat, these files are and , respectively. catalina.out localhost.yyyy-mm-dd.log
The log tail view is automatically refreshed every few seconds.
System Information
Overview
Admin users can view Artifactory system information. Go to the Admin tab and then . Advanced -> System Info
The information includes the JVM runtime parameters, JVM arguments and memory usage.
This is useful for examining the runtime aspects of Artifactory and is a valuable resource when reporting Artifactory issues.
To save system resources, do not leave the log view open in your browser unnecessarily.
Maintenance
Overview
To set up various operations that globally impact the system go to the Admin tab and then : Advanced -> Maintenance
Section Description
Garbage Collection Artifactory uses a checksum-based storage and stores identical
binary files only once.
When a new file is deployed, Artifactory checks if a binary with the
same checksum already exists and links the repository path to this
binary if it exists. Upon deletion of a repository path, Artifactory does
not delete the binary because it might be used by other paths.
The garbage collector is responsible to delete unused binaries. The
default garbage collection is set to periodically every 4 hours to
collect unused (deleted) binaries from the datastore and dispose os
them.
Garbage collection works by specifying a valid expression. For cron
example, to execute the garbage collector every 12 hours use a
value of:
0 0 /12 * * ?
Do not set the cron expression interval too often as it may
compromise the overall performance of the system.
Storage Quota Limits The storage quota limits provide a method to set a limit on the entire
system storage disk space.
By enabling a storage quota youcontribute to the
reliability and availability of the server filesystem and
ensure that its capacity is not used up completely.
If and when the storage disk space has reached the limit percentage
configured, all future deployments are rejected with status code
413and an admin receives an error message at the bottom of the
configuration page:
You can also set the warning level percentage above which you are
notified, before the actual deployments are blocked.
A warning is displayed in your$ARTIFACTORY_HOME/logs/artifac
file and an admin receives a warning message at the bottom tory.log
of the configuration page:
Cleanup Unused Cached Artifacts You can automatically and periodically remove unused artifacts from
remote repository caches according to each remote repository 'Keep
Unused Artifacts' policy.
You can also run the cleanup manually by clicking on
the 'Run Unused Cached Artifacts Cleanup' button. To
configure a specific remote repository cleanup policy, seeManaging
. Caches
Cleanup works by specifying a valid expression. For example, Cron
to run the cleanup job every 12 hours use a value of:
0 0 /12 * * ?
With a filesystem storage the partition checked is one
containing the dir '$ARTIFACTORY_HOME/data/filestore'
ectory.
With a database blob storage the partition checked is one
containing the direc '$ARTIFACTORY_HOME/data/cache'
tory.
Storage Compress the Internal Database
If the default Derby database is used, this action reclaims unused
and allocated space in a table and its indexes. Typically, unused
allocated space exists when a large amount of data is deleted from a
table or indexes are updated.
By default,Derbydoes not return unused space to the
operating system. For example, once a page has been
allocated to a table or index, it is not automatically
returned to the operating system until the table or index
is destroyed.
Prune Unreferenced Data
Remove unreferenced binary files and empty folders present in the
filestore or cache folders.
Such inconsistency may occur as a result of running
with wrong file system permissionson storage folders
or due to running out of storage space.
Working with Maven
Overview
There are two aspects to configuring Maven for use with Artifactory (or with any repository):
1. Setting up Maven to resolve artifacts from, and only from, Artifactory.
2. Setting up Maven for deploying artifacts to the various repositories hosted by Artifactory.
This section covers these aspects:
Configuring Artifacts Resolution
Configuring Deployment
Configuring Artifacts Resolution
Auto Settings Generation
The easiest way to set up Maven to use Artifactory is to use the automatic settings generator from the Home tab and then Client Settings
. -> Maven Settings
Generate and save the file into your Maven home directory. settings.xml
This feature is only relevant when using the internal Derby
DB.
Please run this when Artifactory activity is low, as
compression may not be able to complete when storage is
busy (failure to complete will have no effect on the
storage).
It is also recommended to always shutdown Artifactory
correctly to avoid these errors from occurring.
Releases The repository of the chosen releases.
Snapshots The repository of the chosen snapshots.
Plugin Releases The repository of the chosen plugins releases.
Plugin Snapshots The repository of the chosen plugins snapshots.
Mirror Any Mark this checkbox if you want to mirror the repository.
Provisioning Dynamic Settings for Users
You can deploy and provision a dynamic settings template for your users.
Once downloaded, settings are generated according to your own logic and can automatically include user
authentication information.
Refer to the section under Filtered Resources. Provisioning Build Tool Settings
The Default Global Repository
The simplest way for setting up Maven to use Artifactory proxy is to configure a Maven repository with the following URL:
<host>:<port>/artifactory/repo
This URL is Artifactory's built-in global virtual repository and it lets Artifactory search through all repositories (local and remote), for any artifacts
Maven is fetching.
You can create and use a dedicated virtual (or local) repository to limit Artifactory searches to that specific repository.
The Maven repository URL should appear as:
<host>:<port>/artifactory/<repo_name>
Overriding the Built-in Repositories
If your Artifactory is configured correctly, you should override the built-in central and snapshots repositories of Maven, so that no request is ever
sent directly to them.
Insert the following into your parent POM or settings.xml (under an active profile):
<repositories>
<repository>
<id>central</id>
<url> http://[host]:[port]/artifactory/libs-release </url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
<repository>
<id>snapshots</id>
<url> http://[host]:[port]/artifactory/libs-snapshot </url>
<releases>
</releases>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>central</id>
<url> http://[host]:[port]/artifactory/plugins-release </url>
<snapshots>
</snapshots>
</pluginRepository>
<pluginRepository>
<id>snapshots</id>
<url> http://[host]:[port]/artifactory/plugins-snapshot </url>
<releases>
</releases>
</pluginRepository>
</pluginRepositories>
Additional "Mirror-any" Setup
You can use the "Mirror Any" feature of the previous setup, and have Artifactory act as a redirecting proxy for any Maven repository, on top
including those defined inside POMs of plug-ins and third party dependencies (although this is bad practice, but unfortunately, not uncommon).
This ensures no unexpected requests are made to external repositories introduced by such POMs.
Insert the following into your settings.xml:
<mirrors>
<mirror>
<id>artifactory</id>
<mirrorOf>*</mirrorOf>
<url> http://[host]:[port]/artifactory/repo </url>
<name>Artifactory</name>
</mirror>
</mirrors>
Caveat
Do not use "Mirror Any" as your only resolution rule. Use it to enforce any artifacts resolution to be made strictly through Artifactory.
The "Mirror Any" proxying configuration works for defined repositories. It supersedes, but does not hide, the built-in and re central snapshots
positories, unless overridden by the user.
It defines a coarse-grained proxying rule that does not differentiate between releases and snapshots and relies on the defined repositories to do
this resolution filtering.
Configuring Authentication
You can uncheck the Global Anonymous Access checkbox from the Admin tab and then and use secure downloads Security -> General
with Maven.
Users must have Read Access on repositories they want to resolve artifacts from. You must also ensure your file contains a settings.xml se
definition with the repository ID used for artifacts resolution (downloads) and with valid user name and password. rver
Artifactory offers a unique feature that ensures you do not have to use clear text passwords in your settings, so it is
highly recommended to use this feature.
Watch the Screencast
Configuring Deployment
Setting Up a Deployment Descriptor
To deploy Artifactory you must add a deployment descriptor to your POM with the URL of a target local repository to deploy to. This is standard
Maven practice.
Artifactory can make the process easier by providing you the "Distribution Management" snippet when selecting a
local repository in the tree view (Browse ->Tree Browser).
Synchronizing Authentication Details for Same-URL Repositories
When using authenticated downloads Maven uses the user name and password defined in your to authenticate settings.xml
against Artifactory repositories.
Your settings.xml may contain other server definitions (with different server IDs) used for authenticating
to deployment repositories or to other download repositories.
If you have repository definitions (either for deployment or download) that are using , Maven takes the authentication the same URL
details (from the matching server definition) of the first repository encountered and uses it for the life-time of the running build for all
repositories with the same URL.
This might cause authentication to fail if you are using different authentication details between such
repositories, and you might receive 401 errors for your downloads or deployments. Unfortunately, this is an
inherent Maven problem which is beyond the control of Artifactory and the only solution is to use the same authentication details in
your if they are going to be used by same-URL repositories. settings.xml
Setting Up Security
For deploying, unless anonymous deployments are allowed on the target local repository (which is unlikely), you must also make sure your sett
file contains a definition with the repository ID used in the and with a valid deployer user name ings.xml server distributionManagement
and password.
Artifactory offers a unique feature to ensure you do not have to use clear text passwords in your settings, so it is
highly recommended to use this feature.
Working with Gradle
Working with Gradle and Artifactory
For Gradle to work with Artifactory, you only require a properly configured script file. build.gradle
To avoid dwelling on configuration details we shall just mention the main configuration steps and show a sample
Gradle script that we believe shows all the required information needed to get you started.
It also demonstrates the effectiveness and brevity of Gradle.
Remember that Virtual Repositories are virtual. They cannot be deployed to or used inside a deployment descriptor.
1.
2.
3.
4.
5.
6.
that this build script is used for building the NOTE! Build Integration project as is also available in source control.
Resolution Configuration
Using Artifactory's Gradle Init Script Generator
With Artifactory's Gradle init script generator, you can easily create a Gradle init script that handles resolution. To do so go to the Home tab and
then : Client Settings -> Gradle Init Script
You can deploy and provision a dynamic settings template for your users. Once downloaded, settings are generated according to your own logic
and can automatically include user authentication information.
Refer to section under Filtered Resources. Provisioning Build Tool Settings
Manual Configuration Steps
Define the Artifactory repository to be used by Gradle for artifacts resolution.
Optionally provide credentials in case you do not allow anonymous artifact downloads on the Artifactory repository.
Define the local repository in Artifactory to which module artifacts are to be deployed.
Optionally provide deployment credentials.
If you would also like Gradle to auto-generate a POM file for your artifacts, define the Maven artifact attributes, and -
Define local Artifactory repository to be used for POM deployment (typically this would be the same as the one used for Gradle/Ivy
artifacts).
Sample Build Script and Properties
This section describes a manual integration of Gradle with Artifactory and works for Gradle 0.8.
For Gradle version 0.9-preview-3 and above it is recommended to use the for publication Gradle Artifactory Plugin
build.gradle
usePlugin('java')
usePlugin('maven')
group = 'org.jfrog.buildinfo'
version = '1.0'
/*
(5) Define the Maven attributes that will be used for POM auto-generation
*/
def artifactId = projectDir.name
def groupId = group
def versionNumber = version
dependencies {
compile group: 'com.thoughtworks.xstream', name: 'xstream', version: '1.3.1'
compile group: 'com.google.collections', name: 'google-collections', version:
'1.0-rc5'
}
/*
(1) Define an Artifactory virtual repository used for dependency resolution
*/
repositories {
/*
(2) An optional login/password (will is kept in gradle.properties) and used to
authenticate a reader to Artifactory.
USER, PASSWORD and REALM are coming from gradle.properties
Uncomment if anonymous access is not allowed.
*/
//org.apache.ivy.util.url.CredentialsStore.INSTANCE.addCredentials(REALM, HOST,
USER, PASSWORD);
mavenRepo urls: "http://localhost:8080/artifactory/libs-releases";
}
uploadArchives {
repositories {
/*
(6) This will be used to deploy the Gradle artifact and ivy modules
*/
mavenRepo urls: "http://localhost:8080/artifactory/libs-release-local";
/*
(3) Use this to also deploy an auto-generated POM
*/
repositories.mavenDeployer {
repository(url: "http://localhost:8080/artifactory/libs-release-local") {
/*
(4) The login/password of an Artifactory user with deploy privileges.
USER and PASSWORD are coming from gradle.properties
*/
authentication(userName: USER, password: PASSWORD)
}
pom.version = versionNumber
pom.artifactId = artifactId
pom.groupId = groupId
}
}
}
1.
And the properties file under the same directory:
gradle.properties
HOST=localhost
REALM=Artifactory Realm
USER=admin
PASSWORD=password
Running Gradle
The following clause is required for gradle to recognize Artifactory.
To build your project and upload the generated artifacts to Artifactory, run:
gradle uploadArchives
Please refer to the for more detailed information on building with Gradle (running sub-tasks etc.). Gradle Documentation
Getting Debugging Information from Gradle
If you experience problems, it is highly recommended to run Gradle with the option. This typically provides useful readable information on -d
what went wrong.
Dependency Declaration Snippets
Click on the Artifacts tab to use the Artifactory configuration to obtain dependency declaration snippets by selecting either an artifact and copying
the "Gradle Dependency Declaration" section into your build.gradle file.
Gradle Artifactory Plugin
Overview
Artifactory offers full integration with Gradle via two methods:
Build Server Integration - When running Gradle builds in your continuous integration build server, it is recommended to use one of the
1.
2.
a.
b.
c.
d.
for Jenkins, TeamCity or Bamboo to configure resolution and publishing to Artifactory with build-info capturing, via Artifactory Plugins
your build server UI.
Standalone Integration - As described below, for when running standalone Gradle build scripts using the Gradle Artifactory plugin.
The Gradle Artifactory plugin offers a simple DSL to perform the following as part of your Gradle build:
Define default dependency resolution from Artifactory
Define configurations whose artifacts to be published to Artifactory after a full (multi-module) successful build
Define properties that to be attached to published artifacts in Artifactory metadata
Capture and publish a object to Artifactory build-info REST API to provide a fully traceable build context build-info
Gradle Compatibility
Plugin Version Compatible with Gradle
2.0.4 gradle-1.0-milestone-3
2.0.12 gradle-1.0-milestone-8 and above
2.0.17 gradle-1.0 and above
Downloading and Installing the Artifactory Plugin
Add a repository, which has the plugin and the dependency which includes it. For example:
buildscript {
repositories {
maven { url 'http://dl.bintray.com/jfrog/jfrog-jars' }
}
dependencies {
classpath(group: 'org.jfrog.buildinfo', name: 'build-info-extractor-gradle',
version: '2.1.0')
}
}
The above script automatically downloads the plugin and makes it available to the of your projects. buildScript
Adding the Plugin to Your Project(s)
In order to apply the plugin in your Gradle projects, the following closure must be declared in your script: build.gradle
apply plugin: 'artifactory'
In a multi-project build, you might want to apply the plugin to all projects:
allprojects {
apply plugin: 'artifactory'
}
Configuration
Using the Artifactory Plugin DSL
The Gradle Artifactory plugin can be configured using its own convention DSL inside the script of your root project. build.gradle
The syntax of the Convention DSL is shown below.
artifactory {
+contextUrl = 'http://repo.myorg.com/artifactory' //The base Artifactory URL if
not overridden by the publisher/resolver
publish {
contextUrl = 'http://repo.myorg.com/artifactory' //The base Artifactory URL for
the publisher
//A closure defining publishing information
repository {
+repoKey = 'integration-libs' //The Artifactory repository key to publish to
+username = 'deployer' //The publisher user name
password = 'deployerPaS*' //The publisher password
ivy {
//Optional section for configuring Ivy publication (when publishIvy = true).
Assumes Maven repo layout if not specified
ivyLayout = '[organization]/[module]/[revision]/[type]s/ivy-[revision].xml'
artifactLayout =
'[organization]/[module]/[revision]/[module]-[revision](-[classifier]).[ext]'
mavenCompatible = true //Convert any dots in an [organization] layout value to
path separators, similar to Maven's groupId-to-path conversion. True if not specified
}
}
defaults {
//This closure defines defaults for all 'artifactoryPublish' tasks of all
projects the plugin is applied to
publishConfigs ('a','b','foo') //Optional list
of configurations (names or objects) to publish.
//The
'archives' configuration is used if it exists and no configuration is specified
mavenDescriptor = '/home/froggy/projects/proj-a/fly-1.0.pom' //Optional
alternative path for a POM to be published (can be relative to project baseDir)
ivyDescriptor = 'fly-1.0-ivy.xml' //Optional
alternative path for an ivy file to be published (can be relative to project baseDir)
properties = ['qa.level': 'basic', 'q.os': 'win32, deb, osx'] //Optional map
of properties to attach to all published artifacts
properties { //Optional
closure to attach properties to artifacts based on a list of artifact patterns per
project configuration
foo '*:*:*:*@*', platform: 'linux', 'win64' //The property
platform=linux,win64 will be set on all artifacts in foo configuration
archives 'org.jfrog:*:*:*@*', key1: 'val1' //The property
key1=val1 will be set on all artifacts part of the archives configuration and with
group org.jfrog
all 'org.jfrog:shared:1.?:*@*', key2: 'val2', key3: 'val3' //The
properties key2 and key3 will be set on all published artifacts (all configurations)
with group:artifact:version equal to org.jfrog:shared:1.?
}
publishBuildInfo = true //Publish build-info to Artifactory (true by
default)
publishArtifacts = true //Publish artifacts to Artifactory (true by default)
publishPom = true //Publish generated POM files to Artifactory (true
Mandatory items within the relevant context are prefixed with '+'. All other items are optional.
by default)
publishIvy = false //Publish generated Ivy descriptor files to
Artifactory (false by default)
}
}
resolve {
the resolver
repository {
+repoKey = 'libs-releases' //The Artifactory (preferably virtual) repository
key to resolve from
username = 'resolver' //Optional resolver user name (leave out to use
anonymous resolution)
password = 'resolverPaS*' //The resolver password
maven = true //Resolve Maven-style artifacts and descriptors
(true by default)
ivy {
//Optional section for configuring Ivy-style resolution. Assumes Maven repo
layout if If not specified
ivyLayout = ...
artifactLayout = ...
mavenCompatible = ...
}
}
1.
2.
3.
}
}
The Properties Closure DSL
The closure in and task accept the following syntax: properties artifactory.publish.defaults artifactpryPublish
properties {
configuration 'group:module:version:classifier@type', key1:'value1',
key2:'value2', ...
}
A configuration that is a valid name of a configuration of the project. You can use to apply the properties to all configurations. all
An artifact specification filter for matching the artifacts to which properties should be attached. The filter may
contain wildcards: * for all characters or ? for a single character.
A list of key/value(s) properties that are attached to to the published artifacts matching the filter.
The Artifactory Project Publish Task
Behind the scenes the Gradle Artifactory Plugin creates an ' ' Gradle task for each project the plugin is applied to. artifactoryPublish
The is configured by the closure of the plugin. artifactoryPublish publish
You can configure the project-level task directly with the task's closure, which uses identical Syntax to that of the artifactoryPublish
plugin's closure. publish
artifactoryPublish {
skip = false //Skip build info analysis and publishing (false by default)
publishConfigs ('a','b','c')
mavenDescriptor = '/home/froggy/projects/proj-a/fly-1.0.pom'
ivyDescriptor = 'fly-1.0-ivy.xml'
properties = ['qa.level': 'basic', 'q.os': 'win32, deb, osx']
properties {
c '**:**:**:*@*', cProperty: 'only in c'
}
}
Controlling the Published Modules
To control which modules of a multi-module build are published to Artifactory:
Do not apply the ' ' plugin to project so that it does not publish anything. artifactory
This cannot be performed for the root project that contains the convention object, and so must have the plugin applied. NOTE!
Manually activate the corresponding ' ' Gradle task for each project you wish to. artifactoryPublish
For example in our you can run: Gradle project example ./gradlew clean api:artifactory:publish
shared:artifactoryPublish
Use the flag to deactivate analysis and publication. artifactoryPublish.skip
Controlling BuildInfo's Build Name and Build Number
By default, BuildInfo is published with a build name that is the name of your root project and a build number that is the start date of the build.
You can control the build name and build number values by specifying the following properties, respectively:
buildInfo.build.name=my-super-cool-build
buildInfo.build.number=r9001
The above properties are specified as standard . Gradle Properties
To see the Gradle Artifactory Plugin in action you can watch the following screencast below.
Gradle 1.6 Publishing Artifactory Plugin
Overview
Since Gradle 1.6 the new publishing model for Ivy and Maven publications is fully supported by the new 'artifactory-publish' plugin.
The Gradle Artifactory plugin version supporting this new model is 2.1.0 or above.
Gradle Compatibility
Plugin Version Compatible with Gradle
2.1.0 gradle-1.6 and above
Downloading and Installing the Artifactory Plugin
Manual Installation
The latest plugin jar file can be downloaded from and copy it to your gradle home plugins directory . here ~/.gradle/plugins
And add the following to your project:
buildscript.dependencies.classpath files(new File(gradle.gradleUserHomeDir,
'plugins/build-info-extractor-gradle-2.1.0-uber.jar'))
Automatic Installation
Alternatively, you can add to your Gradle scripts to fetch the plugin using the standard Ivy resolution. For example:
buildscript {
repositories {
maven { url 'http://repo.jfrog.org/artifactory/gradle-plugins' }
}
dependencies {
version: '2.1.0')
}
}
The above script will automatically download the plugin, and make it available to the of your projects. buildScript
Adding the Plugin to Your Project(s)
This page describes a new àrtifactory-publish` plugin, which is supported along side with the classic àrtifactory` plugin. New Gradle
versions are supported by both plugins. For documentation of the àrtifactory` plugin, please see . this page
In order to apply the plugin in your Gradle projects, the following closure needs to be declared in your script: build.gradle
apply plugin: 'artifactory-publish'
In a multi-project build, you'd want to apply the plugin to all projects:
allprojects {
apply plugin: 'artifactory-publish'
}
Configuration
Using the Artifactory Plugin DSL
The Gradle Artifactory plugin can be configured using its own convention DSL inside the script of your root project. build.gradle
The syntax of the Convention DSL is described below.
artifactory {
+contextUrl = 'http://repo.myorg.com/artifactory' //The base Artifactory URL if
not overridden by the publisher/resolver
publish {
the publisher
//A closure defining publishing information
repository {
+repoKey = 'integration-libs' //The Artifactory repository key to publish to
+username = 'deployer' //The publisher user name
password = 'deployerPaS*' //The publisher password
ivy {
//Optional section for configuring Ivy publication (when publishIvy = true).
Assumes Maven repo layout if not specified
ivyLayout = '[organization]/[module]/[revision]/[type]s/ivy-[revision].xml'
artifactLayout =
'[organization]/[module]/[revision]/[module]-[revision](-[classifier]).[ext]'
mavenCompatible = true //Convert any dots in an [organization] layout value to
path separators, similar to Maven's groupId-to-path conversion. True if not specified
}
}
defaults {
//This closure defines defaults for all 'artifactoryPublish' tasks of all
projects the plugin is applied to
publications ('ivyJava','mavenJava','foo') //Optional list
of publications (names or objects) to publish.
properties = ['qa.level': 'basic', 'q.os': 'win32, deb, osx'] //Optional map
of properties to attach to all published artifacts
properties { //Optional
closure to attach properties to artifacts based on a list of artifact patterns per
project publication
foo '*:*:*:*@*', platform: 'linux', 'win64' //The property
platform=linux,win64 will be set on all artifacts in foo publication
mavenJava 'org.jfrog:*:*:*@*', key1: 'val1' //The property
key1=val1 will be set on all artifacts part of the mavenJava publication and with
Mandatory items within the relevant context are prefixed with '+'. All other items are optional.
group org.jfrog
all 'org.jfrog:shared:1.?:*@*', key2: 'val2', key3: 'val3' //The
properties key2 and key3 will be set on all published artifacts (all publications)
with group:artifact:version equal to org.jfrog:shared:1.?
}
publishBuildInfo = true //Publish build-info to Artifactory (true by
default)
publishArtifacts = true //Publish artifacts to Artifactory (true by default)
}
}
resolve {
the resolver
repository {
+repoKey = 'libs-releases' //The Artifactory (preferably virtual) repository
key to resolve from
username = 'resolver' //Optional resolver user name (leave out to use
anonymous resolution)
password = 'resolverPaS*' //The resolver password
maven = true //Resolve Maven-style artifacts and descriptors
(true by default)
ivy {
//Optional section for configuring Ivy-style resolution. Assumes Maven repo
layout if If not specified
ivyLayout = ...
artifactLayout = ...
mavenCompatible = ...
}
}
}
// Redefine basic properties of the build info object
clientConfig.setIncludeEnvVars(true)
clientConfig.info.addEnvironmentProperty('test.adding.dynVar',new
java.util.Date().toString())
clientConfig.info.setBuildName('new-strange-name')
clientConfig.info.setBuildNumber('' + new
1.
2.
3.
java.util.Random(System.currentTimeMillis()).nextInt(20000))
}
The Properties Closure DSL
The closure in and task accept the following syntax: properties artifactory.publish.defaults artifactoryPublish
properties {
publicationName 'group:module:version:classifier@type', key1:'value1',
key2:'value2', ...
}
A publication that is a valid name of a publication of the project. You can use to apply the properties to all publications. all
An artifact specification filter for matching the artifacts to which properties should be attached. The filter may contain wildcards: for all *
characters or for a single character. ?
A list of key/value(s) properties that will be attached to to the published artifacts that match the filter.
The Artifactory Project Publish Task
Behind the scenes the Gradle Artifactory Plugin creates an ' ' Gradle task for each project the plugin is applied to. The artifactoryPublish ar
is configured by the closure of the plugin. You can configure the project-level task directly with the task's tifactoryPublish publish artifa
closure, which uses identical Syntax to that of the plugin's closure. ctoryPublish publish.defaults
artifactoryPublish {
skip = false //Skip build info analysis and publishing (false by default)
publications ('a','b','c')
properties = ['qa.level': 'basic', 'q.os': 'win32, deb, osx']
properties {
c '**:**:**:*@*', cProperty: 'only in c'
}
}
Controlling the Published Modules
To control which modules of a multi-module build, will be published to Artifactory you can:
Do not apply the ' ' plugin to project should not publish anything. Note: This cannot be done for the root project that artifactory
contains the convention object, and so needs the plugin applied.
Manual activate the corresponding ' ' Gradle task for each project you wish to. For example in our artifactoryPublish Gradle project
you can run: example ./gradlew clean api:artifactory:publish shared:artifactoryPublish
Use the flag to deactivate analysis and publication. artifactoryPublish.skip
Controlling BuildInfo's Build Name and Build Number
By default, BuildInfo will be published with a build name that is the name of your root project and a build number that is the start date of the build.
You can control the build name and build number values by specifying the following properties, respectively:
buildInfo.build.name=my-super-cool-build
buildInfo.build.number=r9001
The above properties are specified as standard . Gradle properties
You can also control the values from inside the convention object DSL like showed at the bottom of the DSL code.
To see the Gradle Artifactory Plugin in action you can watch the following screencast below.
1.
2.
3.
1.
2.
Gradle Artifactory Plugin using the snapshot version
Downloading and Installing the snapshot version of the Artifactory Plugin
Manual Installation
The latest plugin jar file can be downloaded from . here
Automatic Installation
Alternatively, you can add to your Gradle scripts the following to fetch the plugin using the standard Ivy resolution. For example:
buildscript {
repositories {
maven { url 'http://repo.jfrog.org/artifactory/gradle-plugins-snapshots' }
}
dependencies {
version: '2.1.x-SNAPSHOT')
}
configurations.classpath {
resolutionStrategy {
failOnVersionConflict()
cacheDynamicVersionsFor 0, 'seconds'
cacheChangingModulesFor 0, 'seconds'
}
}
}
The above script automatically downloads the plugin and makes it available to the of your projects. buildScript
Working with Ivy
Setting up Ivy to work with Artifactory
To enable Ivy to work with Artifactory, the following files must be present and configured:
The Ivy settings - - used to configure artifact resolution and deployment using repositories in Artifactory. ivysettings.xml
The Ivy modules - - where the project's modules and dependencies are declared. ivy.xml
The Ant build - - which is used to execute the ANT tasks that will, in turn, use Ivy for artifact resolution and deployment. build.xml
Ivy Settings - ivysettings.xml
The file holds a chain of Ivy resolvers used for both resolution and publishing (deployment). Resolvers exist for both regular ivysettings.xml
artifacts and Ivy module files.
There are a two options to set up Ivy to work with Artifactory by configuring resolvers in : ivysettings.xml
Automatically using the Artifactory's Ivy settings generator, or
Manually defining Ibiblio and URL resolvers.
Automatic Settings with Artifactory's Ivy Settings Generator
To begin quickly, you can use Artifactory's Ivy settings generator to define credentials and resolver settings. This generates a URL resolver
suitable for both deployment and resolution.
You can deploy and provision a dynamic settings template for your users.
Once downloaded, settings are generated according to your own logic and can automatically include user authentication information.
Refer to section under Filtered Resources. Provisioning Build Tool Settings
Manual Resolver Definitions
The iBiblio Resolver
This resolver is used strictly for dependency resolution. By default, it assumes artifacts in your repository are laid-out in the popular standard
Maven 2 format (which may not always be the case).
The ibiblio resolver can resolve artifacts from remote Maven 2 HTTP repositories and if you use version ranges it
relies on maven-metadata.xml files in the remote repository to gather information on the available versions.
To use the ibiblio resolver add the following to your : ivysettings.xml
<resolvers>
<ibiblio name="artifactory" m2compatible="true"
root="http://localhost:8080/artifactory/libs-releases"/>
</resolvers>
The URL Resolver
The URL resolver can be used for dependency resolution and/or of both regular artifacts and Ivy module files. deployment
To publish or resolve artifacts to/from Artifactory configure a URL resolver with the pattern that matches your target repository layout for both Ivy
and artifact files, e.g.:
The URL must point at an Artifactory repository. In this case, the pre-configured 'libs-releases' virtual repository. root
The m2compatible property pre-configures the resolver with an artifact pattern that follows the Maven 2
standard layout.

<credentials host="localhost" realm="Artifactory Realm" username="admin"
passwd="password"/>
<resolvers>
<url name="artifactory-publish">

<artifact pattern=

"http://localhost:8080/artifactory/libs-snapshot-local/[organization]/[module]/[revisi
on]/[artifact]-[revision].[ext]"/>
<ivy
pattern="http://localhost:8080/artifactory/libs-snapshot-local/[organization]/[module]
/[revision]/ivy-[revision].xml" />
</url>
</resolvers>
Using a Chain Resolver
You can mix resolvers under a chain resolver in Ivy which uses sub-resolvers for dependency resolution and publishing.
Refer to the . Relevant Ivy Documentation
Ivy Modules - ivy.xml
ivy.xml files contain a list of dependency declarations that are required to be resolved for the build.
Under the Artifacts tab of the configuration, you can obtain dependency declaration snippets by selecting either an
Ivy module or a POM artifact and copying the "Ivy Dependency Declaration" section into your ivy.xml file.
The URL resolver uses HTML href analysis to learn about the available versions of a remote artifact. This is a less reliable method
compared to the iBiblio resolver way, though it works well with remote Artifactory servers.
Ant Build - build.xml
To work with Ivy for dependency resolution you must use in your file. This will load the . <ivy:configure/> build.xml ivysettings.xml
The resolution of artifacts is done using <ivy:retrieve/>.
Refer to the for more detailed information. Ivy Documentation
Publishing to Artifactory
In order to publish to Artifactory the command must be used. Ivy uses the configured resolver to deploy your artifact into <ivy:publish>
Artifactory.
For example:
<ivy:publish resolver="artifactory-publish" overwrite="true">

<artifacts/>
</ivy:publish>
Using a Dedicated Settings File for Deployment
If you have defined your deployment settings, including the required credentials in a dedicated settings file, you can refer to it by defining a
unique ID for your settings:
<ivy:settings id="ivy.pub.settings" file="publish_to_artifactory_settings.xml"/>
Then point the publish task at these settings, by adding the following attribute to the element: publish
settingsRef="ivy.pub.settings"
Please consult the for more detailed information. Ivy documentation
Using Artifactory
Overview
This section describes how to use Artifactory and is divided into the following sections:
Browsing Artifactory
Deploying via the Web UI
Searching Artifacts
Manipulating Artifacts
Updating Your Profile
Content-Type Handling
Artifactory REST API
Browsing Artifactory
Overview
Artifactory provides two modes for browsing repositories:
Tree Browsing
Simple Browsing
Both browsing modes enforce the defined security rules to ensure you can only perform permitted actions and see
just the information you are allowed to see in accordance with system security policies.
Tree Browsing
The Tree Browser and the Artifacts tabprovides full information about repository items.
For each selected artifact/folder/repository on the tree, a tabbed panel offers detailed data views. Some of the information provided includes
actions that can be performed on the selected item:
When running Artifactory standalone, the default local URL is . http://localhost:8081/artifactory
If the Artifactory WAR is deployed to another servlet container, this URL may vary according to the
container-specific deployment configuration.
Viewing Maven Metadata and POMs
Artifactory provides ad-hoc views for Maven metadata ( and POM files as dedicated tabs when selecting the maven-metadata.xml pom.xml
relevant tree item.
POM View
Maven Metadata View
Download Statistics
In tree-mode browsing, Artifactory also provides download statistics information for artifacts.
Simple Browser
The simple browser allows you to browse Artifactory using simple path-driven URLs, which are the same URLs used by a build client, such as
Maven. It provides lightweight, view-only browsing.
A unique feature provided by this browsing mode is the ability to browse virtual repositories content in a consolidated way and see where each
physical repository/s every folder and artifact comes from.
List Browsing
List Browsing provides the most lightweight, read-only view and is similar to simple directory listing provided by HTTP servers.
To activate List Browsing, click the small icon to the right of a repository name in the Simple Browser (marked in red in the screenshot above).
Creating public views with List Browsing
One of the advantages of List Browsing is that it is mounted on a well-known path prefix - : list
http://host:port/artifactory/list/repo-path
This allows the system administrator to create a virtual host that only exposes Artifactory's List Browsing feature to public users, while
maintaining all write and advanced privileges, but potentially expensive UI and REST features (such as searches), for internal use.
1.
2.
Remote Browsing
Remote browsing provides the ability to navigate the contents of the remote repository even if the artifacts have not been cached locally.
To view the contents of a remote repository, ensure that the "List Remote Folder Items" checkbox is marked in the remote repository
configuration and then navigate via the the Simple Browser or List Browser to the remote repository.
An item (folder or artifact) that has not been cached yet has a small globe icon to its right in the Simple Browser:.

In the List Browser a non-cached item has an arrow to its right:
WebDAV Browsing
Any local or cache repository may be mounted as a secure WebDAV share and made browsable from any WebDAV-supporting file manager, by
referencing the URL of the target repository.
For example: . http://host:port/artifactory/repo-path
Deploying via the Web UI

Overview
Artifactory offers configuration-based deployments in two forms:
Uploading and deploying a single artifact
Uploading and deploying a bundle of artifacts
Deploying a Single Artifact
Single-artifact deployment is performed from the Deploy tab and then . Deploy -> Single Artifact
Initial remote browsing may be slow
Initial remote browsing may be slow, especially when browsing a virtual repository containing multiple remote repositories.
Remote content is cached according to the "Retrieval Cache Period" defined in the remote repository configuration panel.
For deploying/importing whole repositories, you may want to use the feature. Go to the Admin tab and then Import Repository Import &
Export -> Repositories
1.
2.
Deployment is a two-step process:
Upload an artifact file to Artifactory.
Make smart guesses about your artifact details (this works for both Maven and Ivy). For example, if a JAR artifact has an embedded
POM under its internal directory, this information is used. META-INF
Maven vs. Non-Maven Deployment
You can choose between Maven and non-Maven artifact deployment.
When deploying a Maven artifact you can edit the auto-filled GroupId, ArtifactId, Version, Classifier and Type details. The changes you make are
auto-reflected in the target path displayed. You can ask for automatic POM generation if one is missing in the target repository and you can even
edit the POM manually (make sure you know what you are doing!).
For non-Maven artifacts, such as Ivy artifacts that do not have to follow the Maven repository layout convention, you can deactivate the Deploy
and edit the target deployment path manually. as Maven Artifact
Once you are happy with the deployment details, mark the checkbox to deploy the artifact into Artifactory. Deploy Artifact
Why was my deployment rejected?
Deployment can fail for various reasons, as a whole or partially. The most common reasons for a rejected deployment are:
Lack of permissions
A conflict with the target repository's includes/excludes patterns
A conflict with the target repository's snapshots/releases handling policy.
Deploying a Bundle of Artifacts
Bundle deployment is performed from the Deploy tab and then Deploy ->Artifacts Bundle.
This is a very convenient feature for deploying multiple artifacts in one go. The following archive extensions are supported:
zip,tar,tar.gz,tgz
Artifacts should be packaged in an archive and contained in the file structure they should be deployed with. For
example, the structure of the (partial) archive for Hibernate appears as follows:
org-
hibernate-
hibernate-
3.3.2GA-
hibernate-3.3.2.GA.pom
hibernate-3.3.2.GA.jar
hibernate-entitymanager-
3.3.2GA-

hibernate-entitymanager-3.3.2.GA.pom

hibernate-entitymanager-3.3.2.GA.jar
Uploading and deploying the archives is a single step ending with all archived artifacts deployed into the selected repository.
Searching Artifacts
Searching Artifacts
Artifactory offers a quick search option for artifacts that searches on all the artifact attributes.
One unique feature of the search is that you can quickly navigate from a selected found artifact to its detailed view, under the Tree Browser to
examine the artifact and receive further information on it.
Quick Search
Overview
Artifactory allows you to perform quick searches for artifacts.
Searching
The search is available under the Artifacts tab and then . You can also search in the search field in the upper Artifacts -> Quick Search
right-hand corner of the screen.
You can enter either the name of the artifact or a part of the name of the artifact that you want to search for.
For example, you can use the following search to find all artifacts with "antlr-2.7.2" as a part of its name:
Class Search
Overview
Artifactory allows you to perform class searches on aritfacts for specific classes.
Searching
To perform a class search go to the Artifacts tab and then . Search -> Class Search
Searches in Artifactory are immediate and unlike some repository managers, always reflect the current state of the repository.
Therefore, whatever you deployed is immediately available in search results and whatever is un-deployed
is not displayed.
There is no need to rebuild indexes periodically.
In the search field enter the name of the class you want to find.
For example, you can use the following search to find all artifacts with a class containing 'CBZip' and 'Stream' as part of the class name:
Property Search
Overview
Artifactory allows you to perform searches on properties which are attached to an artifact or repository.
Searching
The search is available under the Artifacts tab and then . Search -> Property Search
You must enter the name of the property and the value itself.
For example, you can use the following search to find all artifacts with a property whose license is marked as "approved":
GAVC Search
Overview
Property Search is part of the feature. Properties Add-on
Artifactory allows you to perform searches for artifacts by specifying their GAVC (GroupId, ArtifactId, Version, and Classifier).
Searching
Performing a GAVC search is available under the Artifacts tab and then . Search -> GAVC Search
You can enter the name of the GroupId, ArtifactId, Version, and Classifier.
For example, you can use the following search to find all artifacts with , and as part of groupId:antlr artifactId:antlr version:*.7.6
the artifact specification:
Checksum Search
Overview
Artifactory allows you to search artifacts by their sha1 or md5 checksum.
Searching
You can perform a Checksum such by going to the Artifacts tab and then . Search -> Checksum Search
You must enter the sha1 or md5 checksum value of the artifact you want to find.
For example, you can use the following search to find artifacts with checksum value of 'c5c499f1eef9367c657e89bb881c69aa':
Bintray remote search
Artifactory provides remote search, which allows to find, download, and show artifacts from Bintray's JCenter.
To use Bintray's remote search go to Artifacts->Search->Remote Search, type the search word and press the Search button (* and ? are
accepted in the search word).
Download artifact
Right click on the selected row in the table and press the Download button
Available only if the JCenter repository configured in Artifactory
Show in Bintray
Right click on the selected row in the table and press the Show in Bintray button
Show in Tree table
Right click on the selected row in the table and press the Show in Tree table button
Available only if the item exists in Artifactory and the JCenter repository configured in Artifactory.
Create JCenter
If JCenter remote repository is currently not configured and is admin the user logged as , Artifactory allows convenient way to create JCenter
repository, in such case the following link will appear, click on the link and then press the create button in the "New remote repository" panel to
create JCenter repository in Artifactory.
1.
2.

Manipulating Artifacts
Overview
Artifactory supports , in contrast to naive removal of repository files and folders. This means that the true undeployment of artifacts maven-met
descriptors inside the repository are immediately updated to reflect the removal of artifacts, ensuring consistent operation with adata.xml
Maven clients.
Artifactory does not only provide simple artifact removal, but also a powerful way to from the repository. clean up complete versions
This section covers these options:
Deleting Single Items
Cleaning-up Complete Versions
Moving Artifacts
To remove an artifact or a folder of an artifact:
To to the Tree Browser under the Artifacts tab and then Browse -> Tree Browser
Select the Delete operation, either from the tabbed-panel or from the right-click drop-down menu
Once deleted, the respective maven-metadata.xml affected by the removal is updated accordingly (unless
removed from a remote cache) and the deleted artifacts are not returned by search results.
1.
2.
3.
4.
Cleaning-up Complete Versions
Overview
It is common for a repository to accumulate many different artifacts deployed under the same group (or just the same path prefix) and the same
version. This is especially true for snapshot deployments of multi-module projects, where all deployed artifacts use the same version.
Cleaning up an old version of different artifacts can be a tedious task and often requires some sort of scripting and
metadata patching. Aware of this problem,Artifactory provides a simple solution for cleaning up old versions.
Performing Versions Cleanup
To perform a version cleanup:
Select a folder in the Tree Browser under the Artifacts tab and then Browse -> Tree Browser
Right-click on the selected item and choose the Remove Versions operation from the right-click menu
Artifactory performs a deep-scan of the folder and returns with a list of all the groups and versions available for deletion
Select the versions you want to clean up
Moving Artifacts
Moving Artifacts
You can move artifacts or folders from the tree browser under the Artifacts tab and then , by using the move action Browse -> Tree Browser
button or by right-clicking the item.
Only admin users can perform version cleanup.
Before moving, you must select the target repository to move to.
You may also perform a 'Dry Run' to ensure the move can be accomplished without any errors or warnings (the target repository may not accept
all moved items due to its policies, the current user's permissions etc.).
Once the move is complete you are guaranteed that all metadata is consistent and that Maven-specific metadata is recalculated to reflect the
move results.
You can edit your profile at any time, provided that you have the right permissions to do so by clicking on you login name on the upper-right hand
corner of the screen.
After entering your password a profile edit panel appears.
Make Sure You Have Sufficient Permissions

Since moving implies deleting the original item from one repository and creating it in another repository, you must have DELETE
permissions and DEPLOY permissions for the moved item's path in the source and target repositories, respectively.
You are not able to change your password if external authentication, such as LDAP, is used by Artifactory.
Content-Type Handling
Content-Type / Mime-Type
Artifactory provides flexible to manage mechanism Content-Type / Mime-Type. On one hand it allows to define system wide Mime-Types and on
Mime-Types . , allows the other hand to overwrite for certain files The default Mime-Types list is in $ARTIFACTORY_HOME/etc/mimetypes.xml
and can be edited in order to add, remove or change Mime-Types. If a file doesnt contain an extension or an extension is not supported by either
of the Mime-Types, Artifactory will use the default one: . Each Mime-Type contains a list of supported application/octet-stream
extensions which are being compared with the artifacts name extension. The first Mime-Type that contain the artifact name extension will be the
chosen as the artifact Mime-Type.
The mimetypes.xml Format Example
For more information about using secured passwords with your profile, . please read this
mimetype.xml example
<mimetypes version="4">
<mimetype type="text/plain" extensions="txt, properties, mf, asc" viewable="true"
syntax="plain"/>
<mimetype type="text/html" extensions="htm, html" viewable="true" syntax="xml"/>
<mimetype type="text/css" extensions="css" viewable="true" syntax="css"/>
<mimetype type="text/xsl" extensions="xsl" viewable="true" syntax="xml"/>
<mimetype type="text/xslt" extensions="xslt" viewable="true" syntax="xml"/>
<mimetype type="text/x-java-source" extensions="java" viewable="true"
syntax="java"/>
<mimetype type="text/x-javafx-source" extensions="fx" viewable="true"
syntax="javafx"/>
</mimetypes>
Some of the Mime-Types such as are required by Artifactory for a proper Caution: "application/x-checksum"
functioning. DO NOT change them unless you really know what you are doing.
Each Mime-Type may have the following attributes:
type - The mime entry unique name (mandatory)
extensions - Comma separated list of file extensions mapped to this mime type (mandatory)
index - True if this mime type should be indexed for archive searching (valid only supported archive files)
archive - True if this mime type is a browsable archive
viewable - True if this mime type can be viewed as text file inside Artifactory UI
syntax - The UI highlighter syntax to for this mime type (only relevant if this is a viewable type)
css - The css class of a display icon for this mime type
According to the above Mime-Types list: : Example
test.properties is "text/plain" (properties is included in the text/plain supported list)
test.css is "text/css" (css is included in the"text/css"default list)
test.doc is "application/octet-stream" (doc is not included ineither of the Mime-types).
Choosing Content-Type during download (Artifactory Pro 3.0.2 or above)
Artifactory allows overriding the Content-Type HTTP header value of downloaded files with the special property artifactory.content-type
, In such case the will receive the property value Content-Type HTTP header value . Artifactory will use the default mechanism which Otherwise
chooses the Content-Type by trying to find a match between the artifact name extension and extensions in the mimetypes.xml file.
Artifactory REST API
WADL
Artifactory exposes its REST API through an auto-generated WADL file (courtesy of the ). Jersey REST framework
This provides a convenient and up-to-date self-descriptive API and can be used by various tools/frameworks to
automate the creation of REST calls.
The WADL file is available at the following URL:
http://server:port/artifactory/api/application.wadl
REST Resources
Set out below is a list of the REST resources exposed by Artifactory.
Usage of REST resources is subject to security restrictions applicable to each individual resource.
TABLE OF CONTENTS
BUILDS
All Builds
Build Runs
Build Info
Builds Diff
Build Promotion
Delete Builds
Build Rename
ARTIFACTS & STORAGE
Folder Info
File Info
Item Last Modified
Item Properties
Set Item Properties
Delete Item Properties
Retrieve Artifact
Retrieve Latest Artifact
Retrieve BuildArtifacts Archive
Trace Artifact Retrieval
Archive Entry Download
Create Directory
Deploy Artifact
Deploy Artifact by Checksum
Deploy Artifacts from Archive
File Compliance Info
Delete Item
Copy Item
Move Item
Scheduled Replication Status
Pull/Push Replication
Artifact Sync Download (Deprecated)
Folder Sync (Deprecated)
File List
SEARCHES
Artifact Search (Quick Search)
Archive Entry Search (Class Search)
GAVC Search
Property Search
Bad Checksum Search
Artifacts Not Downloaded Since
Artifacts Created in Date Range
Pattern Search
Builds for Dependency
License Search
Artifact Version Search
Artifact Latest Version Search
Build Artifacts Search
SECURITY
Get Users
Get User Details
Create or Replace User
Update User
Delete User
Get Groups
Get Group Details
Create or Replace Group
Update Group
Delete Group
Get Permission Targets
Get Permission Target Details
Create or Replace Permission Target
Delete Permission Target
Effective Item Permissions
Security Configuration
Save Security Configuration (Deprecated)
REPOSITORIES
Get Repositories
Repository Configuration
Create or Replace Repository Configuration
Update Repository Configuration
Delete Repository
Remote Repository Configuration
Calculate YUM Repository Metadata
Calculate Maven Index
CalculateMaven Metadata
SYSTEM & CONFIGURATION
System Info
System Health Ping
Save General Configuration
Version and Add-ons information
PLUGINS
Execute Plugin Code
Retrieve All Available Plugin Info
Retrieve Plugin Info Of A Certain Type
Retrieve Build Staging Strategy
Execute Build Promotion
IMPORT & EXPORT
Import Repository Content
Import System Settings Example
Full System Import
Export System Settings Example
Export System
BUILDS
All Builds
Description: Provides information on all builds
: 2.2.0 Since
: Requires a privileged user (can be anonymous) Security
: GET /api/build Usage
: application/vnd.org.jfrog.build.Builds+json Produces
: Sample Output
GET /api/build
{
"uri": "http://localhost:8080/artifactory/api/build"
"builds" : [
{
"uri" : "/wicket",
"lastStarted" : ISO8601 (yyyy-MM-dd'T'HH:mm:ss.SSSZ)
},
{
"uri" : "/jackrabbit",
"lastStarted" : ISO8601 (yyyy-MM-dd'T'HH:mm:ss.SSSZ)
}
]
}
Build Runs
Description: Build Runs
: 2.2.0 Since
: GET /api/build/{buildName} Usage
: application/vnd.org.jfrog.build.BuildsByName+json Produces
: Sample Output
GET /api/build/wicket
{
"uri": "http://localhost:8080/artifactory/api/build/wicket"
"buildsNumbers" : [
{
"uri" : "/51",
"started" : ISO8601 (yyyy-MM-dd'T'HH:mm:ss.SSSZ)
},
{
"uri" : "/52",
"started" : ISO8601 (yyyy-MM-dd'T'HH:mm:ss.SSSZ)
}
]
}
Build Info
Description: Build Info
: 2.2.0 Since
: GET /api/build/{buildName}/{buildNumber} Usage
: application/vnd.org.jfrog.build.BuildInfo+json Produces
: Sample Output
GET /api/build/wicket/51
{
"uri": "http://localhost:8080/artifactory/api/build/wicket/51"
"buildInfo" : {
...
}
}
Builds Diff
Description: Compare a build artifacts/dependencies/environment with an older build to see what has changed (new artifacts added, old
dependencies deleted etc).
: 2.6.6 Since
: GET /api/build/{buildName}/{buildNumber}?diff={OlderbuildNumber} Usage
: application/vnd.org.jfrog.build.BuildsDiff+json Produces
: Sample Output
GET /api/build/wicket/51?diff=50
{
"artifacts": {
"updated": [],
"unchanged": [],
"removed": [],
"new": []
}, "dependencies": {
"updated": [],
"unchanged": [],
"removed": [],
"new": []
}, "properties": {
"updated": [],
"unchanged": [],
"removed": [],
"new": []
}
}
Build Promotion
Description: Change the status of a build, optionally moving or copying the build's artifacts and its dependencies to a target repository and
setting properties on promoted artifacts.
All artifacts from all scopes are included by default while dependencies are not. Scopes are additive (or).
: 2.3.3 Since
: Requires Artifactory Pro Notes
: POST /api/build/promote/{buildName}/{buildNumber} Usage
: application/vnd.org.jfrog.artifactory.build.PromotionRequest+json Consumes
POST /api/build/promote/wicket/51
{
"status": "staged" // new build status (any string)
"comment" : "Tested on all target platforms." // An optional comment describing the
reason for promotion. Default: ""
"ciUser": "builder" // The user that invoked promotion from the CI server
"timestamp" : ISO8601 // the time the promotion command was received by Artifactory
"dryRun" : false // run without executing any operation in Artifactory, but get the
results to check if the operation can succeed. Default: false
"targetRepo" : "libs-release-local" // optional repository to move or copy the
build's artifacts and/or dependencies
"copy": false // whether to copy instead of move, when a target repository is
specified. Default: false
"artifacts" : true // whether to move/copy the build's artifacts. Default: true
"dependencies" : true // whether to move/copy the build's dependencies. Default:
false.
"scopes" : [ "compile", "runtime" ] // an array of dependency scopes to include when
"dependencies" is true
"properties": { // a list of properties to attach to the build's artifacts
(regardless if "targetRepo" is used).
"components": ["c1","c3","c14"],
"release-name": ["fb3-ga"]
}
"failFast": true // fail and abort the operation upon receiving an error. Default:
true
}
Produces: application/vnd.org.jfrog.artifactory.build.PromotionResult+json
: Sample Output
{
"messages" : [
{
"level": "error",
"message": "The repository has denied...."
},...
]
}
Delete Builds
Description: Removes builds stored in Artifactory. Useful for cleaning up old build info data.
If the parameter is evaluated as 1 (0/false by default), build artifacts are also removed. artifacts
If the parameter is evaluated as 1 (0/false by default), the whole build is removed. deleteAll
: 2.3.0; artifact removal since 2.3.3; Since
: Requires an admin user Security
: DELETE /api/build/{buildName}[?buildNumbers=n1[,n2]][&artifacts=0/1][&deleteAll=0/1] Usage
: application/text Produces
: Sample Usage
DELETE /api/build/wicket?buildNumbers=51,52,55&artifacts=1
The following builds has been deleted successfully: 'wicket#51', 'wicket#52',
'wicket#55'.
DELETE /api/build/wicket
All 'wicket' builds have been deleted successfully.
Build Rename
Description: Renames a build stored in Artifactory. Typically used to keep the build info in sync with a renamed build on the CI server.
: 2.2.5 Since
: Requires a valid user with deploy permissions Security
: POST /api/build/rename/{buildName}?to=newBuildName Usage
: Sample Usage
POST /api/build/rename/myJobName?to=myNewJobName
Build renaming of 'myJobName' to 'myNewJobName' was successfully started.
ARTIFACTS & STORAGE
Folder Info
Description: Folder Info
For virtual use, the virtual repository returns the unified children
: 2.2.0 Since
: GET /api/storage/{repoKey}/{folder-path} Usage
: application/vnd.org.jfrog.artifactory.storage.FolderInfo+json Produces
: Sample Output
GET /api/storage/libs-release-local/org/acme
{
"uri": "http://localhost:8080/artifactory/api/storage/libs-release-local/org/acme",
"repo": "libs-release-local",
"path": "/org/acme",
"created": ISO8601 (yyyy-MM-dd'T'HH:mm:ss.SSSZ),
"createdBy": "userY",
"lastModified": ISO8601 (yyyy-MM-dd'T'HH:mm:ss.SSSZ),
"modifiedBy": "userX",
"lastUpdated": ISO8601 (yyyy-MM-dd'T'HH:mm:ss.SSSZ),
"children": [
{
"uri" : "/child1",
"folder" : "true"
},{
"uri" : "/child2",
"folder" : "false"
}
]
}
File Info
Description: File Info
For virtual use the virtual repository returns the resolved file. Supported by local, local-cached and virtual repositories.
: 2.2.0 Since
: GET /api/storage/{repoKey}/{filePath} Usage
: application/vnd.org.jfrog.artifactory.storage.FileInfo+json Produces
: Sample Output
GET /api/storage/libs-release-local/org/acme/lib/ver/lib-ver.pom
{
"uri":
"http://localhost:8080/artifactory/api/storage/libs-release-local/org/acme/lib/ver/lib
-ver.pom",
"downloadUri":
"http://localhost:8080/artifactory/libs-release-local/org/acme/lib/ver/lib-ver.pom",
"path": "/org/acme/lib/ver/lib-ver.pom",
"remoteUrl": "http://some-remote-repo/mvn/org/acme/lib/ver/lib-ver.pom",
"lastModified": ISO8601 (yyyy-MM-dd'T'HH:mm:ss.SSSZ),
"modifiedBy": "userX",
"lastUpdated": ISO8601 (yyyy-MM-dd'T'HH:mm:ss.SSSZ),
"size": "1024", //bytes
"mimeType": "application/pom+xml",
"checksums":
{
"md5" : string,
"sha1" : string
},
"originalChecksums":{
"md5" : string,
"sha1" : string
}
}
Item Last Modified
Description: Retrieve the last modified item at the given path. If the given path is a folder, the latest last modified item is searched for
recursively. Supported by local and local-cached repositories.
: 2.2.5 Since
: Requires a valid user with deploy permissions Security
: GET /api/storage/{repoKey}/{item-path}?lastModified Usage
: application/vnd.org.jfrog.artifactory.storage.ItemLastModified+json Produces
: Sample Output
GET /api/storage/libs-release-local/org/acme?lastModified
{
"uri":
"http://localhost:8080/artifactory/api/storage/libs-release-local/org/acme/foo/1.0-SNA
PSHOT/foo-1.0-SNAPSHOT.pom",
"lastModified": ISO8601
}
Item Properties
Description: Item Properties. Optionally return only the properties requested. Supported by local and local-cached repositories.
: 2.2.1 Since
: GET /api/storage/{repoKey}/{itemPath}?properties[=x[,y]] Usage
: application/vnd.org.jfrog.artifactory.storage.ItemProperties+json Produces
: Sample Output
GET /api/storage/libs-release-local/org/acme?properties\[=x[,y]\]
{
"uri": "http://localhost:8080/artifactory/api/storage/libs-release-local/org/acme"
"properties":{
"p1": ["v1","v2","v3"],
"p2": ["v4","v5","v6"]
}
}
Set Item Properties
Description: Attach properties to an item (file or folder). When a folder is used property attachment is recursive by default.
: 2.3.0 Since
: PUT /api/storage/{repoKey}{itemPath}?properties=p1=v1[,v2][|p2=v3][&recursive=1] Usage
: Sample Usage
PUT
/api/storage/libs-release-local/ch/qos/logback/logback-classic/0.9.9?properties=os=win
,linux|qa=done&recursive=1
Delete Item Properties
Description: Deletes the specified properties from an item (file or folder). When a folder is used property removal is recursive by default.
: 2.3.2 Since
: DELETE /api/storage/{repoKey}{itemPath}?properties=p1[,p2][&recursive=1] Usage
: Sample Usage
DELETE
/api/storage/libs-release-local/ch/qos/logback/logback-classic/0.9.9?properties=os,qa&
recursive=1
Retrieve Artifact
Description: Retrieves an artifact from the specified destination.
You can also use as part of retrieving artifacts. Property-based Resolution
: Requires a user with 'read' permission (can be anonymous) Security
: GET /repo-key/path/to/artifact.ext Usage
: Sample Usage
GET
http://localhost:8080/artifactory/libs-release-local/ch/qos/logback/logback-classic/0.
9.9/logback-classic-0.9.9.jar
Retrieve Latest Artifact
Description: Retrieves the latest artifact version from the specified destination.
: Specify or for the version in the requested path to get the latest Maven integration or Latest Maven Release/Integration SNAPSHOT [RELEASE]
release artifact.
: S Latest Non-Maven Release/Integration pecify or for the versionin the requested path (replacing the [INTEGRATION] [RELEASE] [folderI
and as defined by the repository's ) tegRev] [fileItegRev] layout to get the latest integration version or latest release version artifact
accordingly.
Integration and release tokens cannot be mixed together. Only local, cache and virtual repositories will be used.
You can also use as part of retrieving artifacts. property-based resolution
: Requires Artifactory Pro. Notes
: Latest Maven: 2.6.0; Latest non-Maven: 2.6.2 Since
: GET /repo-key/path/to/artifact.ext Usage
: Sample Usage
Download the latest Maven unique snapshot artifact:
GET
9.9-SNAPSHOT/logback-classic-0.9.9-SNAPSHOT.jar
Download the latest release artifact:
GET http://localhost:8080/artifactory/ivy-local/org/acme/[RELEASE]/acme-[RELEASE].jar
Download the latest integration artifact:
GET
http://localhost:8080/artifactory/ivy-local/org/acme/1.0-[INTEGRATION]/acme-1.0-[INTEG
RATION].jar
Retrieve BuildArtifacts Archive
Description: Retrieves an archive file (supports zip/tar/ ) containing all the artifacts related to a specific build, you can optionally provide tar.gz/tgz
mappings to filter the results, the mappings support whichenables you to dynamically construct the target path inside regexp capturing groups
the result archive file.
: 2.6.5 Since
: POST /api/archive/buildArtifacts Usage
:application/vnd.org.jfrog.artifactory.build.BuildArtifactsRequest+json Consumes
application/zip (for zip archive type), application/x-tar (for tar archive type), application/x-gzip (for archive type) Produces: tar.gz/tgz
: Sample Usage
POST /api/archive/buildArtifacts
{
+"buildName": "build-name" // The build name for search by
+"buildNumber": "15" // The build number to search by, can be LATEST to search for
the latest build number
-"buildStatus": "Released" // Optionally search by latest build status (e.g:
"Released")
-"repos": ["libs-release-local,ext-release-local"] // Optionally refine search for
specific repos, omit to search within all repositories
+"archiveType": "tar/zip/tar.gz/tgz" // The archive file type to return
-"mappings": [ // Optionally refine the search by providing a list of regexp patterns
to search by
{
"input": "(.+)/(.+)-sources.jar",
"output": "$1/sources/$2.jar" // Optionally provide different path of the found
artifacts inside the result archive, supports regexp groups tokens
},
{
"input": "(.+)-release.zip"
}
]
}
Trace Artifact Retrieval
Description: Simulates an artifact retrieval requestfrom the specified location and returns verbose output about the resolution process.
This API is useful for debugging artifact retrieval issues.
: As applied to standard artifact retrieval by the requesting user. Security
: 2.6.0 Since
: GET /repo-key/path/to/artifact.ext?trace Usage
: text/plain Produces
: Sample Output
GET
http://localhost:8080/artifactory/libs-release-local/jmock/jmock/1.0.1/jmock-1.0.1.jar
?trace
Request ID: 51c808f6

Repo Path ID: libs-release-local:jmock/jmock/1.0.1/jmock-1.0.1.jar
Method Name: GET
User: resolver
Time: 2012-05-06T10:49:09.528+03:00
Thread: pool-1-thread-31
Steps:
2012-05-06T10:49:09.587+03:00 Received request
2012-05-06T10:49:09.588+03:00 Request source = 0:0:0:0:0:0:0:1, Last modified =
01-01-70 01:59:59 IST, If modified since = -1, Thread name = pool-1-thread-31
2012-05-06T10:49:09.697+03:00 Retrieving info
2012-05-06T10:49:09.723+03:00 Identified resource as a file
...
2012-05-06T10:49:09.788+03:00 Responding with selected content handle
2012-05-06T10:49:09.807+03:00 Request succeeded
Archive Entry Download
Description: Retrieves an archived resource from the specified archive destination.
: GET /repo-key/path/to/artifact.jar*!*/path/to/archived/resource ( the '!' between the archive file name and the archive entry path) Usage NOTE!
: Sample Output
GET
http://localhost:8080/artifactory/repo1-cache/commons-lang/commons-lang/2.6/commons-la
ng-2.6.jar!/META-INF/LICENSE.txt
Create Directory
Description: Create new directory at the specified destination.
: You can also as part of creating directories. Notes attach properties
: Requires a user with 'deploy' permissions (can be anonymous) Security
: PUT /repo-key/path/to/directory/ Usage
: application/vnd.org.jfrog.artifactory.storage.ItemCreated+json Produces
: Sample Usage
PUT /libs-release-local/path/to/directory/
{
"uri": "http://localhost:8080/artifactory/libs-release-local/path/to/directory",
"path": "/path/to/directory",
"children" : [ ]
}
Deploy Artifact
Description: Deploy an artifact to the specified destination.
: You can also as part of deploying artifacts. Notes attach properties
: PUT /repo-key/path/to/artifact.ext Usage
: Sample Usage
PUT /libs-release-local/my/jar/1.0/jar-1.0.jar
{
"uri": "http://localhost:8080/artifactory/libs-release-local/my/jar/1.0/jar-1.0.jar",
"downloadUri":
"http://localhost:8080/artifactory/libs-release-local/my/jar/1.0/jar-1.0.jar",
"path": "/my/jar/1.0/jar-1.0.jar",
"size": "1024", //bytes
"mimeType": "application/java-archive",
"checksums":
{
"md5" : string,
"sha1" : string
},
"md5" : string,
"sha1" : string
}
}
Deploy Artifact by Checksum
Description: Deploy an artifact to the specified destination by checking if the artifact content already exists in Artifactory.
If Artifactory already contains a user readable artifact with the same checksum the artifact content is copied over to the new location and return a
response without requiring content transfer.
Otherwise, a 404 error is returned to indicate that content upload is expected in order to deploy the artifact.
: You can also as part of deploying artifacts. Notes attach properties
: PUT /repo-key/path/to/artifact.ext Usage
: X-Checksum-Deploy: true, X-Checksum-Sha1: sha1Value Headers
: 2.5.1 Since
: Sample Output
PUT /libs-release-local/my/jar/1.0/jar-1.0.jar
{
"uri": "http://localhost:8080/artifactory/libs-release-local/my/jar/1.0/jar-1.0.jar",
"downloadUri":
"http://localhost:8080/artifactory/libs-release-local/my/jar/1.0/jar-1.0.jar",
"path": "/my/jar/1.0/jar-1.0.jar",
"size": "1024", //bytes
"mimeType": "application/java-archive",
"checksums":
{
"md5" : string,
"sha1" : string
},
"md5" : string,
"sha1" : string
}
}
Deploy Artifacts from Archive
Description: Deploys an archive containing multiple artifacts and explodes it at the specified destination maintaining the archive's file structure.
Deployment is performed in a single HTTP request and only the exploded content is deployed, not the archive file itself.
Supported archive types are: zip; tar; tar.gz; and tgz. that deployment of compressed archives (unlike tar) may incur considerable CPU NOTE!
overhead.
Requires Artifactory Pro : Notes
: PUT /repo-key/path/to/archive.zip Usage
: X-Explode-Archive: true Headers
: 2.6.3 Since
: Sample Usage
PUT /libs-release-local/archive.zip
File Compliance Info
Description: Get compliance infofor a given artifact path. The result includes license and vulnerabilities, if any.
Requires Artifactory Pro : Notes
: 3.0.0 Since
:Requires an authenticated user. Security
: GET: /api/compliance/{repoKey}/{item-path} Usage
:application/json Produces
: Sample output
GET:
/api/compliance/libs-release-local/ch/qos/logback/logback-classic/0.9.9/logback-classi
c-0.9.9.jar
{
"licenses" : [ {"name":"LGPL v3", "url": "http://"}, {"name":"APL v2", "url":
"http://"}... ],
"vulnerabilities" : [ {"name":"CVE-13427", "url": "http://"}, {"name":"CVE-1041",
"url": "http://"}... ]
}
Delete Item
Description: Deletes a file or a folder from the specified destination.
: Requires a user with 'delete' permission (can be anonymous) Security
: DELETE /repo-key/path/to/file-or-folder Usage
: Sample Usage
DELETE
9.9
Copy Item
Description: Copy an artifact or a folder to the specified destination.
Optionally suppress cross-layout module path translation during copy.
You can test the copy using a dry run.
Copy item behaves similarly to a standard file system and supports renames. If the target path does not exist, the source item is copied and
optionally renamed. Otherwise, if the target exists and it is a directory, the source is copied and placed under the target directory.
: POST /api/copy/{srcRepoKey}/{srcFilePath}?to=/{targetRepoKey}/{targetFilePath}[&dry=1][&suppressLayouts=0/1][&failFast=0/1] Usage
: application/vnd.org.jfrog.artifactory.storage.CopyOrMoveResult+json Produces
: 2.2.2 Since
: Sample Output
POST /api/copy/libs-release-local/org/acme?to=/ext-releases-local/org/acme-new&dry=1
{
"messages" : [
{
"level": "error",
},...
]
}
Move Item
Description: Moves an artifact or a folder to the specified destination.
Optionally suppress cross-layout module path translation during move.
You can test the move using dry run.
Move item behaves similarly to a standard file system and supports renames. If the target path does not exist, the source item is moved and
optionally renamed. Otherwise, if the target exists and it is a directory, the source is moved and placed under the target directory.
: POST /api/move/{srcRepoKey}/{srcFilePath}?to=/{targetRepoKey}/{targetFilePath}[&dry=1][&suppressLayouts=0/1][&failFast=0/1] Usage
: application/vnd.org.jfrog.artifactory.storage.CopyOrMoveResult+json Produces
: 2.2.2 Since
: Sample Output
POST /api/move/libs-release-local/org/acme?to=/ext-releases-local/org/acme-new&dry=1
{
"messages" : [
{
"level": "error",
},...
]
}
Scheduled Replication Status
Description: Returns the status of scheduled cron-based replication jobs define via the Artifactory UI on repositories.
: GET /api/replication/{repoKey} Usage
: application/vnd.org.jfrog.artifactory.replication.ReplicationStatus+json Produces
: 2.4.2 Since
: Sample Usage
GET /api/replication/remote-libs
{
"status": never_run|incomplete(running or interrupted)|error|warn|ok|inconsistent
"lastCompleted": ISO8601 (yyyy-MM-dd'T'HH:mm:ss.SSSZ) or null if never completed
}
Pull/Push Replication
Description: Schedules immediate content replication between two Artifactory instances. Replication can includeproperties and can optionally
delete local items if they do not exist in the source repository.
This API completes the exiting cron-based replication exposed via the Artifactory UI and allows for on-demand execution.
Pull Replication - pulls content from a remote Artifactory repository to a local cache of the remote repository.
Push Replication - pushes content from a local repository into a remote Artifactory local repository.
: Requires a privileged user (can be anonymous) For non-admin users will replicate at max the number of files as defined by the Security artif
system property. actory.search.userQueryLimit
: POST /api/replication/{srcRepoKey}/{srcPath} Usage
: application/vnd.org.jfrog.artifactory.replication.ReplicationRequest+json Consumes
: 2.4.0 Since
: Sample Usage
POST /api/replication/libs-release-local/com/acme
{
- "properties": true, //Sync item properties (false by default)
- "delete": true, //Sync deletions (false by default)
//The following is only applicable for push replication
+ "url" : "https://repo.nmiy.org/repo-key", // The remote repository URL
+ "username": "replicator", //The name of a user with deploy permissions on the
remote repository
+ "password": "***", //The remote repository password
- "proxy": "org-prox", //A name of an Artifactory-configured proxy to use for remote
requests
}
+=mandatory; -=optional
Artifact Sync Download (Deprecated)
Description: Downloads an artifact with or without returning the actual content to the client. When tracking the progress marks are printed (by
default every 1024 bytes). This is extremely useful if you want to trigger downloads on a remote Artifactory server, for example to force eager
cache population of large artifacts, but want to avoid the bandwidth consumption involved in transferring the artifacts to the triggering client. If no
content parameter is specified the file content is downloaded to the client.
: This API is . Requires Artifactory Pro Notes deprecated
: GET /api/download/{repoKey}/{filePath}[?content=none/progress][&mark=numOfBytesToPrintANewProgressMark] Usage
: application/octet-stream, text/plain (depending on content type) Produces
: 2.2.2 Since
: Sample Output
GET /api/download/my-remote/org/acme/1.0/acme-1.0.jar?content=progress&mark=512
.....................................................
.....................................................
.....
Completed: 150/340 bytes
Folder Sync (Deprecated)
Description: Triggers a no-content download of artifacts from a remote Artifactory repository for all artifacts under the specified remote folder.
Can optionally delete local files if they do not exist in the remote folder, overwrite local files only if they are older than remote files or never
overwrite local files. The default is not to delete any local files and to overwrite older local files with remote ones. By default progress marks of
the sync are displayed. The default timeout for the remote file list is 15000 milliseconds (15 seconds).
: This API is . Requires Artifactory Pro Notes deprecated
: Requires a privileged user (can be anonymous) For non-admin users will replicate at max the number of files as defined by the Security artif
system property. actory.search.userQueryLimit
: GET Usage
/api/sync/{remoteRepositoryKey}/{folderPath}[?progress=showProgress][&mark=numOfBytesToPrintANewProgressMark][&delete=deleteExistin
gFiles][&overwrite=never/force][&timeout=fileListTimeoutInMillis]
: 2.2.4 Since
: Sample Output
GET /api/sync/my-remote/org/acme/1.0?progress=1&delete=1
.....................................................
.....................................................
.....................................................
..........................................
.....................................................
..................
Completed with 0 errors and 2 warnings (please check the server log for more details).
File List
Description: Get a flat (the default) or deep listing of the files and folders (not included by default) within a folder.
For deep listing you can specify an optional depth to limit the results.
Optionally include a map of metadata timestamp values as part of the result (only properties are displayed in since 3.0.0).
folder inclusion since 2.3.2; checksum inclusion since: 2.3.3; include folder root path since: 2.5.2. Supported by all types of repositories.
: 2.2.4 Since
: Requires a non-anonymous privileged user. Security
: GET /api/storage/{repoKey}/{folder-path}?list[&deep=0/1][&depth=n][&listFolders=0/1][&mdTimestamps=0/1][&includeRootPath=0/1] Usage
: application/vnd.org.jfrog.artifactory.storage.FileList+json Produces
: Sample Output
GET /api/storage/libs-release-local/org/acme?list&deep=1&listFolders=1&mdTimestamps=1
{
"uri": "http://localhost:8080/artifactory/api/storage/libs-release-local/org/acme",
"created": ISO8601,
"files" : [
{
"uri": "/archived",
"size": "-1",
"lastModified": ISO8601,
"folder": "true"
},
{
"uri": "/doc.txt",
"size": "253207", //bytes
"folder": "false",
"sha1": sha1Checksum,
"mdTimestamps": { "properties" : lastModified (ISO8601) }
},
{
"uri": "/archived/doc1.txt",
"size": "253100", //bytes
"folder": "false",
"sha1": sha1Checksum,
"mdTimestamps": { "properties" : lastModified (ISO8601) }
},...
]
}
SEARCHES
Artifact Search (Quick Search)
Description: Artifact search by part of file name.
Searches return file info uris. Can limit search to specific repositories (local or caches).
: 2.2.0 Since
: GET /api/search/artifact?name=name[&repos=x[,y]] Usage
X-Result-Detail: info (To add all extra information of the found artifact), X-Result-Detail: properties (to get the properties of Headers (Optionally):
the found artifact), X-Result-Detail: info, properties (for both).
: application/vnd.org.jfrog.artifactory.search.ArtifactSearchResult+json Produces
: Sample Output
GET /api/search/artifact?name=lib&repos=libs-release-local
{
"results": [
{
"uri":
-ver.pom"
},{
"uri":
"http://localhost:8080/artifactory/api/storage/libs-release-local/org/acme/lib/ver2/li
b-ver2.pom"
}
]
}
Archive Entry Search (Class Search)
Description: Search archive entries for classes or any other jar resources.
Can limit search to specific repositories (local or caches).
: 2.2.0 Since
: GET /api/search/archive?name=[archiveEntryName][&repos=x[,y]] Usage
: application/vnd.org.jfrog.artifactory.search.ArchiveEntrySearchResult+json Produces
: Sample Output
All searches return limited results (same limits as in the user interface) for anonymous users.
GET
/api/search/archive?name=*Logger.class&repos=third-party-releases-local,repo1-cache
{
"results" :[
{
"entry":
"org/apache/jackrabbit/core/query/lucene/AbstractIndex.LoggingPrintStream.class",
"archiveUris": [

"http://localhost:8080/artifactory/api/storage/third-party-releases-local/org/apache/j
ackrabbit/
jackrabbit-core/1.2.3/jackrabbit-core-1.2.3.jar",

"http://localhost:8080/artifactory/api/storage/third-party-releases-local/org/apache/j
ackrabbit/
jackrabbit-core/1.3.1/jackrabbit-core-1.3.1.jar"
]
},{
"entry": "org/codehaus/plexus/logging/AbstractLogger.class",
"archiveUris": [

"http://localhost:8080/artifactory/api/storage/repo1-cache/org/codehaus/plexus/plexus-
container-default/

1.0-alpha-9-stable-1/plexus-container-default-1.0-alpha-9-stable-1.jar"
]
}
]
}
GAVC Search
Description: Search by Maven coordinates: GroupId, ArtifactId, Version & Classifier.
Search must contain at least one argument. Can limit search to specific repositories (local or caches).
: 2.2.0 Since
: GET /api/search/gavc?[g=groupId][&a=artifactId][&v=version][&c=classifier][&repos=x[,y]] Usage
: application/vnd.org.jfrog.artifactory.search.GavcSearchResult+json Produces
: Sample Output
GET /api/search/gavc?g=org.acme&a=artifact&v=1.0&c=sources&repos=libs-release-local
{
"results": [
{
"uri":
"http://localhost:8080/artifactory/api/storage/libs-release-local/org/acme/artifact/1.
0/artifact-1.0-sources.jar"
},{
"uri":
"http://localhost:8080/artifactory/api/storage/libs-release-local/org/acme/artifactB/1
.0/artifactB-1.0-sources.jar"
}
]
}
Property Search
Description: Search by properties.
If no value is specified for a property - assume '*'. Can limit search to specific repositories (local or caches).
: 2.2.0 Since
: GET /api/search/prop?[p1=v1,v2][&p2=v3][&repos=x[,y]] Usage
: application/vnd.org.jfrog.artifactory.search.MetadataSearchResult+json Produces
: Sample Output
GET /api/search/prop?p1=v1,v2&p2=v3&repos=libs-release-local
{
"results" : [
{
"uri":
-ver.pom"
},{
"uri":
b-ver2.pom"
}
]
}
Checksum Search
Description: Artifact search by checksum (md5 or sha1)
Searches return file info uris. Can limit search to specific repositories (local or caches).
: 2.3.0 Since
: GET /api/search/checksum?md5=md5sum|?sha1=sha1sum[&repos=x[,y]] Usage
: application/vnd.org.jfrog.artifactory.search.ChecksumSearchResult+json Produces
: Sample Output
GET /api/search/checksum?md5=04040c7c184620af0a0a8a3682a75eb7&repos=libs-release-local
{
"results": [
{
"uri":
"http://localhost:8080/artifactory/api/storage/libs-release-local/org/jfrog/build-info
-api/1.3.1/build-info-api-1.3.1.jar"
}
]
}
Bad Checksum Search
Description: Find all artifacts that have a bad or missing client checksum values (md5 or sha1)
Searches return file info uris. Can limit search to specific repositories (local, caches or virtuals).
: 2.3.4 Since
: GET /api/search/badChecksum?type=md5|sha1[&repos=x[,y]] Usage
: application/vnd.org.jfrog.artifactory.search.BadChecksumSearchResult+json Produces
: Sample Output
GET /api/search/badChecksum?type=md5&repos=libs-release-local
{
"results": [
{
"uri":
"http://localhost:8080/artifactory/api/storage/libs-release-local/org/jfrog/build-info
-api/1.3.1/build-info-api-1.3.1.jar"
"serverMd5": "4040c7c184620af0a0a8a3682a75eb7"
"clientMd5": "4040c7c184620af0a0a8a3682a75e44" //On missing checksum this
element will be an empty string
}
]
}
Artifacts Not Downloaded Since
Description: Retrieve all artifacts not downloaded since the specified Java epoch in msec.
Optionally include only artifacts created before the specified date, otherwise only artifacts created before are createdBefore notUsedSince
returned.
: 2.2.4 Since
: Requires a privileged non-anonymous user. Security
: GET /api/search/usage?notUsedSince=javaEpochMillis[&createdBefore=javaEpochMillis][&repos=x[,y]] Usage
: application/vnd.org.jfrog.artifactory.search.ArtifactUsageResult+json Produces
: Sample Output
GET /api/search/usage?notUsedSince=long&createdBefore=long&repos=libs-release-local
{
"results" : [
{
"uri":
-ver.jar",
"lastDownloaded": ISO8601
},{
"uri":
b-ver2.jar",
lastDownloaded: ISO8601
}
]
}
Artifacts Created in Date Range
Description: Get All Artifacts Created in Date Range
If 'to' is not specified use now(). Can limit search to specific repositories (local or caches).
: 2.2.0 Since
: GET /api/search/creation?from=javaEpochMillis[&to=javaEpochMillis][&repos=x[,y]] Usage
: application/vnd.org.jfrog.artifactory.search.ArtifactCreationResult+json Produces
: Sample Output
GET /api/search/creation?from=long&to=long&repos=libs-release-local
{
"results" : [
{
"uri":
-ver.jar",
"created": ISO8601
},{
"uri":
b-ver2.jar",
"created": ISO8601
}
]
}
Pattern Search
Description: Get all artifacts matching the given Ant path pattern
: 2.2.4 Since
: Requires Artifactory Pro. Pattern "**" is not supported to avoid overloading search results. Notes
: GET /api/search/pattern?pattern= Usage repo-key:this/is/a/*pattern*.war
: application/vnd.org.jfrog.artifactory.search.PatternResultFileSet+json Produces
: Sample Output
GET /api/search/pattern?pattern=libs-release-local:killer/*/ninja/*/*.jar
{
"repositoryUri" : "http://localhost:8080/artifactory/libs-release-local",
"sourcePattern" : "libs-release-local:killer/*/ninja/*/*.jar",
files : [
"killer/coding/ninja/1.0/monkey-1.0.jar",
"killer/salty/ninja/1.5-SNAPSHOT/pickle-1.5-SNAPSHOT.jar"
]
}
Builds for Dependency
Description: Find all the builds an artifact is a dependency of (where the artifact is included in the build-info dependencies)
: 2.3.4 Since
: GET /api/search/dependency?sha1=sha1Checksum Usage
: application/vnd.org.jfrog.artifactory.search.DependencyBuilds+json Produces
: Sample Output
GET /api/search/dependency?sha1=451a3c5f8cfa44c5d805379e760b5c512c7d250b
{
"results" : [
{
},{
}
]
}
License Search
Description: Search for artifacts with specified statuses.
To search by specific license values use Property Search with the 'artifactory.licenses' property.
Default parameter values when unspecified: unapproved=1, unknown=1, notfound=0, neutral=0, approved=0, autofind=0.
When the parameter is specified Artifactory will try to automatically find new license information and return it as part of the result in autofind
the field. Please note that this can affect the speed of the search quite dramatically. found
: 2.3.0 Since
: GET /api/search/license[?unapproved=1][&unknown=1][&notfound=0][&neutral=0][&approved=0][&autofind=0][&repos=x[,y]] Usage
: application/vnd.org.jfrog.artifactory.search.LicenseResult+json Produces
: Sample Output
GET
/api/search/license?approved=1&unknown=1&autofind=1&repos=libs-release-local,staging
{
"results" : [
{
"uri":
-ver.jar",
"license": "lgplv2",
"found": "lgplv2",
"status": "approved"
},{
"uri":
-ver.jar",
"license": "cddlv1",
"found": "gplv3",
"status": "neutral"
},{
"uri":
"http://localhost:8080/artifactory/api/storage/staging/org/acme/lib/ver2/lib-ver2.jar"
,
"license": "gplv3",
"found": "gplv3",
"status": "unapproved"
}
]
}
Artifact Version Search
Description: Search for all available artifact versions by GroupId and ArtifactIdin local, remote or virtual repositories.
Search can be limited to specific repositories (local, remote and virtual) by settings the parameter. repos
:Unless the parameter is specified, both release and integration versions are returned. When is Release/integration versions version version
specified, e.g. , result includes only integration versions. Integration versions are determined by the of the 1.0-SNAPSHOT repository layout
repositories searched. For integration search to work the repository layout requires an 'Artifact Path Pattern' that contains the token baseRev
and then the token with only literals between them. fileItegRev
: By default only local and cache repositories are used. When specifying , Artifactory searches for versions on Remote searches remote=1
remote repositories. that this can dramatically slow down the search. NOTE!
For Maven repositories the remote is consulted. For non-maven layouts, remote file listing runs for all maven-metadata.xml
remoterepositories that have the 'List Remote Folder Items' checkbox enabled.
The parameter can accept the * and/or ? wildcards which will then filter the final result to match Filtering results (Artifactory 3.0.2+): version
only those who match the given version pattern.
: 2.6.0 Since
:Requires a privileged user (can be anonymous) Security
:GET /api/search/versions?[g=groupId][&a=artifactId][&v=version][&remote=0/1][&repos=x[,y]] Usage
:application/vnd.org.jfrog.artifactory.search.ArtifactVersionsResult+json Produces
Sample Output:
GET /api/search/versions?g=org.acme&a=artifact&repos=libs-release-local
{
"results": [
{
"version": "1.2",
"integration": false
},{
"version": "1.0-SNAPSHOT",
"integration": true
},{
"version": "1.0",
"integration": false
}
]
}
Artifact Latest Version Search
Description: Search for the latest artifact version by groupId and artifactId.
Search can be limited to specific repositories (local, remote and virtual) by settings the parameter. repos
:Unless the parameter is specified, the search returns the latest artifact release version. When Latest release vs. latest integration version ver
isspecified, e.g. , the result is the latest integration version. Integration versions are determined by the of sion 1.0-SNAPSHOT repository layout
the repositories searched. For integration search to work the repository layout requires an 'Artifact Path Pattern' that contains the token baseRev
and then the token with only literals between them. fileItegRev
: By default only local and cache repositories will be used. When specifying , Artifactory searches for versions on Remote searches remote=1
remote repositories. that this can dramatically slow down the search. NOTE!
For Maven repositories the remote will be consulted. For non-Maven layouts, remote file listing runs for all maven-metadata.xml
remoterepositories that have the 'List Remote Folder Items' checkbox enabled.
The parameter can accept the * and/or ? wildcards which will then filter the final result to match Filtering results (Artifactory 3.0.2+): version
only those who match the given version pattern.
: 2.6.0 Since
:Requires a privileged user (can be anonymous) Security
:GET /api/search/latestVersion?[g=groupId][&a=artifactId][&v=version][&remote=1][&repos=x[,y]] Usage
:text/plain Produces
: Sample Output
GET
/api/search/latestVersion?g=org.acme&a=artifact&v=1.0-SNAPSHOT&repos=libs-release-loca
l
1.0-201203131455-2
Build Artifacts Search
Description: Find all the artifacts related to a specific build.
: 2.6.5 Since
: POST /api/search/buildArtifacts Usage
:application/vnd.org.jfrog.artifactory.search.BuildArtifactsRequest+json Consumes
: Sample Usage
POST /api/search/buildArtifacts
{
+"buildName": "build-name" // The build name for search by
+"buildNumber": "15" // The build number to search by, can be LATEST to search for
the latest build number
-"buildStatus": "Released" // Optionally search by latest build status (e.g:
"Released")
-"repos": ["libs-release-local,ext-release-local"] // Optionally refine search for
specific repos, omit to search within all repositories
-"mappings" [ // Optionally refine the search by providing a list of regexp patterns
to search by
{
"input": "(.+)-sources.jar"
},
{
"input": "(.+)-javadoc.jar"
}
]
}
: Produces application/vnd.org.jfrog.artifactory.search.BuildArtifactsSearchResult+json
: Sample Output
POST /api/search/buildArtifacts
{
"results" : [
{
"downloadUri":
"http://localhost:8080/artifactory/libs-release-local/org/acme/lib/ver/lib-sources.jar
"
},{
"downloadUri":
"http://localhost:8080/artifactory/ext-release-local/org/acme/lib/ver/lib-ver-javadoc.
jar"
}
]
}
SECURITY
Get Users
Description: Get the users list
: 2.4.0 Since
: GET /api/security/users Usage
: application/vnd.org.jfrog.artifactory.security.Users+json Produces
: Sample Output
GET /api/security/users
[
{
"name": "davids"
"uri" : "http://localhost:8080/artifactory/api/security/users/davids"
}, {
"name": "danl"
"uri" : "http://localhost:8080/artifactory/api/security/users/danl"
}
]
Get User Details
Description: Get the details of an Artifactory user
: 2.4.0 Since
: GET /api/security/users/{userName} Usage
: Produces application/vnd.org.jfrog.artifactory.security.User+json
: Sample Output
GET /api/security/users/davids
{
user.json
}
Create or Replace User
Description: Creates a new user in Artifactory or replaces an existing user
: 2.4.0 Since
Missing values will be set to the default values as defined by the consumed type.
: PUT /api/security/users/{userName} Usage
: Consumes application/vnd.org.jfrog.artifactory.security.User+json
: Sample Usage
PUT /api/security/users/davids
{
user.json
}
Update User
Description: Updates an exiting user in Artifactory with the provided user details.
: 2.4.0 Since
: POST /api/security/users/{userName} Usage
: Consumes application/vnd.org.jfrog.artifactory.security.User+json
: Sample Usage
POST /api/security/users/davids
{
user.json
}
Delete User
Description: Removes an Artifactory user.
: 2.4.0 Since
: DELETE /api/security/users/{userName} Usage
: Sample Usage
DELETE /api/security/users/davids
User 'davids' has been removed successfully.
Get Groups
Description: Get the groups list
: 2.4.0 Since
: GET /api/security/groups Usage
: Produces application/vnd.org.jfrog.artifactory.security.Groups+json
: Sample Output
GET /api/security/groups
[
{
"name": "readers"
"uri" : "http://localhost:8080/artifactory/api/security/groups/readers"
}, {
"name": "tech-leads"
"uri" : "http://localhost:8080/artifactory/api/security/groups/tech-leads"
}
]
Get Group Details
Description: Get the details of an Artifactory Group
: 2.4.0 Since
: GET /api/security/groups/{groupName} Usage
: Produces application/vnd.org.jfrog.artifactory.security.Group+json
: Sample Output
GET /api/security/groups/dev-leads
{
group.json
}
Create or Replace Group
Description: Creates a new group in Artifactory or replaces an existing group
: 2.4.0 Since
: PUT /api/security/groups/{groupName} Usage
: Consumes application/vnd.org.jfrog.artifactory.security.Group+json
: Sample Usage
PUT /api/security/groups/dev-leads
{
group.json
}
Update Group
Description: Updates an exiting group in Artifactory with the provided group details.
: 2.4.0 Since
: POST /api/security/groups/{groupName} Usage
: Consumes application/vnd.org.jfrog.artifactory.security.Group+json
: Sample Usage
POST /api/security/groups/dev-leads
{
group.json
}
Delete Group
Description: Removes an Artifactory group.
: 2.4.0 Since
: DELETE /api/security/groups/{groupName} Usage
: Sample Usage
DELETE /api/security/groups/dev-leads
Group 'dev-leads' has been removed successfully.
Get Permission Targets
Description: Get the permission targets list
: 2.4.0 Since
: GET /api/security/permissions Usage
: Produces application/vnd.org.jfrog.artifactory.security.PermissionTargets+json
: Sample Output
GET /api/security/permissions
[
{
"name": "readSourceArtifacts"
"uri" :
"http://localhost:8080/artifactory/api/security/permissions/readSourceArtifacts"
}, {
"name": "populateCaches"
"uri" :
"http://localhost:8080/artifactory/api/security/permissions/populateCaches"
}
]
Get Permission Target Details
Description: Get the details of an Artifactory Permission Target
: 2.4.0 Since
: GET /api/security/permissions/{permissionTargetName} Usage
: Produces application/vnd.org.jfrog.artifactory.security.PermissionTarget+json
: Sample Output
GET /api/security/permissions/populateCaches
{
permission-target.json
}
Create or Replace Permission Target
Description: Creates a new permission target in Artifactory or replaces an existing permission target
: 2.4.0 Since
: PUT /api/security/permissions/{permissionTargetName} Usage
: Consumes application/vnd.org.jfrog.artifactory.security.PermissionTarget+json
: Sample Usage
PUT /api/security/permissions/populateCaches
{
permission-target.json
}
Delete Permission Target
Description: Deletes an Artifactory permission target.
: 2.4.0 Since
: DELETE /api/security/permissions/{permissionTargetName} Usage
: Sample usage
DELETE /api/security/permissions/populateCaches
Permission Target 'remoteCachePopulation' has been removed successfully.
Effective Item Permissions
Description: Returns a list of effective permissions for the specified item (file or folder).
Only users and groups with some permissions on the item are returned. Supported by local and local-cached repositories.
Permissions are returned according to the following conventions:
m=admin; d=delete; w=deploy; n=annotate; r=read
: 2.3.4 Since
: Requires a valid admin or local admin user. Security
: GET /api/storage/{repoKey}/{itemPath}?permissions Usage
: application/vnd.org.jfrog.artifactory.storage.ItemPermissions+json Produces
: Sample Output
GET /api/storage/libs-release-local/org/acme?permissions
{
"uri": "http://localhost:8080/artifactory/api/storage/libs-release-local/org/acme"
"principals": {
"users" : {
"bob": ["r","w","m"],
"alice" : ["d","w","n", "r"]
},
"groups" : {
"dev-leads" : ["m","r","n"],
"readers" : ["r"]
}
}
}
Security Configuration
Description: Retrieve the security configuration (security.xml).
: 2.2.0 Since
: This is an advanced feature - make sure the new configuration is really what you wanted before saving. Notes
: Requires a valid admin user Security
: GET /api/system/security Usage
: application/xml Produces
: Sample Output
GET /api/system/security
<security.xml/>
Save Security Configuration (Deprecated)
Description: Save the security configuration (security.xml).
: 2.2.0 Since
: This API is . Notes deprecated
: POST /api/system/security Usage
: application/xml Consumes
: Sample Usage
POST /api/system/security
<security.xml/>
REPOSITORIES
Get Repositories
Description: Returns a list of minimal repository details for all repositories of the specified type.
: 2.2.0 Since
: GET /api/repositories[?type=repositoryType (local|remote|virtual)] Usage
: application/vnd.org.jfrog.artifactory.repositories.RepositoryDetailsList+json Produces
: Sample Output
GET /api/repositories
[
{
"key" : "libs-releases-local",
"type" : "LOCAL",
"description" : "Local repository for in-house libraries",
"url" : "http://localhost:8080/artifactory/libs-releases-local"
}, {
"key" : "libs-snapshots-local",
"type" : "LOCAL",
"description" : "Local repository for in-house snapshots",
"url" : "http://localhost:8080/artifactory/libs-snapshots-local"
}
]
Description: Retrieves the current configuration of a repository.
: 2.3.0 Since
: Requires a valid user for a shared remote repository and admin user for anything else. Shared remote repository data is sanitized for Security
security when a non-admin user is used.
: GET /api/repositories/{repoKey} Usage
: Produces application/vnd.org.jfrog.artifactory.repositories.LocalRepositoryConfiguration+json,
application/vnd.org.jfrog.artifactory.repositories.RemoteRepositoryConfiguration+json,
application/vnd.org.jfrog.artifactory.repositories.VirtualRepositoryConfiguration+json
: Sample Output
GET /api/repositories/libs-release-local
{
repository-config.json
}
Create or Replace Repository Configuration
Description: Creates a new repository in Artifactory with the provided configuration or replaces the configuration of an existing repository.
A position may be specified using the parameter. If the map size is shorter than the repository is the last one (the default behavior). pos pos
: 2.3.0 Since
An existing repository with the same key are removed from the configuration and its content is removed!
Missing values are set to the default values as defined by the consumed type spec.
: PUT /api/repositories/{repoKey}[?pos=position] Usage
: Consumes application/vnd.org.jfrog.artifactory.repositories.LocalRepositoryConfiguration+json,
application/vnd.org.jfrog.artifactory.repositories.VirtualRepositoryConfiguration+json, application/json
: Sample Usage
PUT /api/repositories/libs-release-local?pos=2
{
}
Update Repository Configuration
Description: Updates an exiting repository configuration in Artifactory with the provided configuration elements.
: 2.3.0 Since
The class of a repository (the attribute cannot be updated. rclass
: POST /api/repositories/{repoKey} Usage
: Consumes application/vnd.org.jfrog.artifactory.repositories.LocalRepositoryConfiguration+json,
application/vnd.org.jfrog.artifactory.repositories.VirtualRepositoryConfiguration+json, application/json
: Sample Usage
POST /api/repositories/libs-release-local
{
}
Delete Repository
Description: Removes a repository configuration together with the whole repository content.
: 2.3.0 Since
: DELETE /api/repositories/{repoKey} Usage
: Sample Usage
DELETE /api/repositories/libs-release-local
Repository 'libs-release-local' and all its content have been removed successfully.
Description: Repository Configuration (Deprecated)
Gets the shared configuration of a remote repository.
: 2.2.0 Since
: This API is . Use the Get Repository Configuration API instead. Notes deprecated
: Requires a valid user for a shared remote repository and admin user for anything else. Shared remote repository data will be sanitized Security
for security when non-admin user is used.
: GET /api/repositories/{remoteRepoName}/configuration Usage
: application/vnd.org.jfrog.artifactory.repositories.SharedRemoteRepositoryConfiguration+json Produces
: Sample Output
GET /api/repositories/remote-repo/configuration
{
}
Calculate YUM Repository Metadata
Description: Calculates/recalculates the YUM metdata for this repository, based on the RPM package currently hosted in the repository.
Calculation can be synchronous (the default) or asynchronous.
Please see the documentation for more details. YUM integration
: Requires Artifactory Pro. Immediate calculation requests cannot be called on repositories with automatic asynchronous calculations Notes
enabled.
: POST /api/yum/{repoKey}[?async=0/1] Usage
: 2.3.5 Since
: Sample Output
POST /api/yum/libs-release-local?async=1
YUM metadata calculation for repository 'libs-release-local' accepted.
Calculate Maven Index
Description: Calculates/caches a Maven index for the specified repositories.
For a virtual repository specify all underlying repositories that you want the aggregated index to include.
Calculation can be forced, which for remote repositories will cause downloading of a remote index even if a locally cached index has not yet
expired; and index recalculation based on the cache on any failure to download the remote index, including communication errors (the default
behavior is to only use the cache when a remote index cannot be found and returns a 404). Forcing has no effect on local repositories index
calculation.
Please see the documentation for more details. Exposing Maven Indexes
: Requires Artifactory Pro. Notes
: POST /api/maven[?repos=x[,y]][&force=0/1] Usage
: 2.5.0 Since
: Sample Output
POST /api/maven?repos=libs-release-local,ext-release-local&force=1
Maven index refresh for repositories '[libs-release-local, ext-release-local]' has
been accepted.
CalculateMaven Metadata
Description: Calculates Maven metadata on the specified path (local repositories only).
:Requires a valid user withdeploypermissions Security
: POST/api/maven/calculateMetadata/{repoKey}/{folder-path} Usage
: 3.0.2 Since
: Sample Output
POST /api/maven/calculateMetadata/libs-release-local/org/acme
OK
SYSTEM & CONFIGURATION
System Info
Description: System Info
Get general system information.
: 2.2.0 Since
: GET /api/system Usage
: Sample Output
GET /api/system
system info output text
System Health Ping
Description: Get a simple status response about the state of Artifactory
Returns 200 code with an 'OK' text if Artifactory is working properly, if not will return an HTTP error code with a reason.
: 2.3.0 Since
: Requires a valid user (can be anonymous) Security
: GET /api/system/ping Usage
: Sample Output
GET /api/system/ping
OK
Description: Get the general configuration (artifactory.config.xml).
: 2.2.0 Since
: GET /api/system/configuration Usage
: application/xml ( ) Produces http://www.jfrog.org/xsd/artifactory-v1_4_5.xsd
: Sample Output
GET /api/system/configuration
<artifactory.config.xml/>
Save General Configuration
Description: Save the general configuration (artifactory.config.xml).
: 2.2.0 Since
: This is an advanced feature - make sure the new configuration is really what you wanted before saving. Notes
: POST /api/system/configuration Usage
: application/xml ( ) Consumes http://www.jfrog.org/xsd/artifactory-v1_4_5.xsd
: Sample Usage
POST /api/system/configuration
<artifactory.config.xml/>
Version and Add-ons information
Description: Retrieve information about the current Artifactory version, revision, and currently installed Add-ons
: 2.2.2 Since
: Requires a valid user (can be anonymous) Security
: GET /api/system/version Usage
: Produces application/vnd.org.jfrog.artifactory.system.Version+json
: Sample Output
GET /api/system/version
{
"version" : "2.2.2",
"revision" : "10427",
"addons" : [ "build", "ldap", "properties", "rest", "search", "sso", "watch",
"webstart" ]
}
PLUGINS
Execute Plugin Code
Description: Executes a named execution closure found in the section of a . executions user plugin
Execution can take parameters and be synchronous (the default) or asynchronous.
: 2.3.1 Since
: Requires anauthenticated user (the plugin can control which users/groups are allowed to trigger it) Security
: POST /api/plugins/execute/{executionName}?[params=p1=v1[,v2][|p2=v3][&async=1]] Usage
: Sample Output
POST /api/plugins/execute/cleanup?params=suffix=SNAPSHOT|types=jar,war,zip&async=1
OK
Retrieve All Available Plugin Info
Description: Retrieves all available information (subject to the permissions of the provided credentials). user plugin
: 2.5.2 Since
: Requires an authenticated user. Security
: GET /api/plugins Usage
: Sample Output
GET /api/plugins
{
"executions": [
{
"name": "execution1",
"version": "version",
"description": "description",
"users": ["user1"],
"groups": ["group1", "group2"],
"params": {}
}
],
"staging": [
{
"name": "strategy1",
"version": "1.0",
"description": "desc",
"params": {"key1": "val1"}
}
]
}
Retrieve Plugin Info Of A Certain Type

Description: Retrieves all available information(subject to the permissions of the provided credentials) of the specified type. user plugin
: 2.5.2 Since
: GET /api/plugins/{pluginType} Usage
: Sample Output
GET /api/plugins/staging
{
"staging": [
{
"name": "strategy1",
"version": "1.0",
"description": "desc",
"params": {"key1": "val1"}
}
]
}
Retrieve Build Staging Strategy
Description: Retrieves a build staging strategydefined by a . user plugin
: 2.5.2 Since
: GET /api/plugins/build/staging/{strategyName}?buildName={buildName}&[params=p1=v1[,v2][|p2=v3]] Usage
:application/vnd.org.jfrog.plugins.BuildStagingStrategy Produces
: Sample Output
GET /api/plugins/build/staging/strategy1?buildName=build1?params=types=jar,war,zip
{
"defaultModuleVersion":
{
"moduleId": "moduleId",
"nextRelease": "nextRelease",
"nextDevelopment": "nextDevelopment"
},
"vcsConfig":
{
"useReleaseBranch": true,
"releaseBranchName": "branchName",
"createTag": true,
"tagUrlOrName": "tagUrl",
"tagComment": "comment",
"nextDevelopmentVersionComment": "comment"
},
"promotionConfig":
{
"targetRepository": "repoKey",
"comment": "comment",
"status": "statusName"
}
}
Execute Build Promotion
Description: Executes a named promotion closure found in the section of a . promotions user plugin
: 2.5.2 Since
: POST /api/plugins/build/promote/{promotionName}/{buildName}/{buildNumber}?[params=p1=v1[,v2][|p2=v3]] Usage
: Sample Output
POST /api/plugins/build/promote/promotion1/build1/3?params=types=jar,war,zip
OK
IMPORT & EXPORT
Import Repository Content
Description: Import one or more repositories.
: 2.2.2 Since
: POST: /api/import/repositories Usage
Requests Params:
path - The base path to import from (may contain a single repo or multiple repos with named sub folders)
repo - Empty/null repo -> all
metadata - Include metadata - default 1
verbose - Verbose - default 0
: Sample Output
POST: /api/import/repositories?path=pathToRepos&verbose=1
Import System Settings Example
Description: Returned default Import Settings JSON.
: 2.4.0 Since
: GET: /api/import/system Usage
: Produces application/vnd.org.jfrog.artifactory.system.ImportSettings+json
: Sample Usage
GET /api/import/system
{
"importPath" : "/import/path",
"includeMetadata" : true,
"verbose" : false,
"failOnError" : true,
"failIfEmpty" : true
}
Full System Import
Description: Import full system from a server local Artifactory export directory.
: 2.4.0 Since
: POST: /api/import/system Usage
: Consumes application/vnd.org.jfrog.artifactory.system.ImportSettings+json, application/json
: Sample Usage
POST /api/import/system
{
import-settings.json
}
Export System Settings Example
Description: Returned default Export Settings JSON.
: 2.4.0 Since
: GET: /api/export/system Usage
: Produces application/vnd.org.jfrog.artifactory.system.ExportSettings+json
: Sample Usage
GET /api/export/system
{
"exportPath" : "/export/path",
"includeMetadata" : true,
"createArchive" : false,
"bypassFiltering" : false,
"verbose" : false,
"failOnError" : true,
"failIfEmpty" : true,
"m2" : false,
"incremental" : false,
"excludeContent" : false
}
Export System
Description: Export full system to a server local directory.
: 2.4.0 Since
: POST: /api/export/system Usage
: Consumes application/vnd.org.jfrog.artifactory.system.ExportSettings+json, application/json
: Sample Usage
POST /api/export/system{ export-settings.json }
Repository Configuration JSON
Repository Configuration JSON
Legend
+ Mandatory element in create/replace queries
- Optional element in create/replace queries
default) The default value when in create/replace queries whenunspecified
application/vnd.org.jfrog.artifactory.repositories.LocalRepositoryConfiguration+json
{
- "key": "local-repo1",
+ "rclass" : "local",
- "description": "The local repository public description",
- "notes": "Some internal notes",
- "includesPattern": "**/*" (default),
- "excludesPattern": "" (default),
- "checksumPolicyType": "client-checksums" (default) | "server-generated-checksums"
- "handleReleases": true (default),
- "handleSnapshots": true (default),
- "maxUniqueSnapshots": 0 (default),
- "snapshotVersionBehavior": "unique" | "non-unique" (default) | "deployer",
- "suppressPomConsistencyChecks": false (default),
- "blackedOut": false (default),
- "propertySets": ["ps1", "ps2"]
}
application/vnd.org.jfrog.artifactory.repositories.RemoteRepositoryConfiguration+json
{
- "key": "remote-repo1",
+ "rclass" : "remote",
+ "url" : "http://host:port/some-repo",
- "username": "remote-repo-user",
- "password": "pass",
- "proxy": "proxy1",
- "description": "The remote repository public description",
- "remoteRepoChecksumPolicyType": "generate-if-absent" (default) | "fail" |
"ignore-and-generate" | "pass-thru",
- "handleReleases": true (default),
- "handleSnapshots": true (default),
- "maxUniqueSnapshots": 0 (default),
- "suppressPomConsistencyChecks": false (default),
- "hardFail": false (default),
- "offline": false (default),
- "blackedOut": false (default),
- "storeArtifactsLocally": true (default),
- "socketTimeoutMillis": 15000 (default),
- "localAddress": "212.150.139.167",
- "retrievalCachePeriodSecs": 43200 (default),
- "failedRetrievalCachePeriodSecs": 30 (default),
- "missedRetrievalCachePeriodSecs": 7200 (default),
- "unusedArtifactsCleanupEnabled": false (default),
- "unusedArtifactsCleanupPeriodHours": 0 (default),
- "fetchJarsEagerly": false (default),
- "fetchSourcesEagerly": false (default),
- "shareConfiguration": false (default),
- "synchronizeProperties": false (default),
- "propertySets": ["ps1", "ps2"]
}
application/vnd.org.jfrog.artifactory.repositories.VirtualRepositoryConfiguration+json
{
- "key": "virtual-repo1",
+ "rclass" : "virtual",
- "repositories": ["local-rep1", "local-rep2", "remote-rep1", "virtual-rep2"]
- "description": "The virtual repository public description",
- "artifactoryRequestsCanRetrieveRemoteArtifacts": false,
- "keyPair": "keypair1",
- "pomRepositoryReferencesCleanupPolicy": "discard_active_reference" (default) |
"discard_any_reference" | "nothing"
}
Security Configuration JSON
Security Configuration JSON
Legend
+ Mandatory element in create/replace queries
- Optional element in create/replace queries
! Read-only element
(default) The default value when in create/replace queries whenunspecified
application/vnd.org.jfrog.artifactory.security.User+json
{
- "name": "davids",
+ "email" : "davids@jfrog.com",
+ "password": "***" (write-only, never returned),
- "admin": false (default),
- "profileUpdatable": true (default),
- "internalPasswordDisabled": false (default),
! "lastLoggedIn": ISO8601 (yyyy-MM-dd'T'HH:mm:ss.SSSZ),
! "realm": "Internal",
- "groups" : [ "deployers", "users" ]
}
application/vnd.org.jfrog.artifactory.security.Group+json
{
- "name": "dev-leads",
- "description" : "The development leads group",
- "autoJoin" : false (default),
! "realm": "Internal",
}
application/vnd.org.jfrog.artifactory.security.PermissionTarget+json
Permissions are set/returned according to the following conventions:
m=admin; d=delete; w=deploy; n=annotate; r=read
{
- "name": "populateCaches",
- "includesPattern": "**" (default),
- "repositories": ["local-rep1", "local-rep2", "remote-rep1", "virtual-rep2"]
- "principals": {
"users" : {
"bob": ["r","w","m"],
"alice" : ["d","w","n", "r"]
},
"groups" : {
"dev-leads" : ["m","r","n"],
"readers" : ["r"]
}
}
}
System Settings JSON
System Settings JSON
Legend
+ Mandatory element
- Optional element
(default) The default value when unspecified
application/vnd.org.jfrog.artifactory.system.ImportSettings+json
{
+ "importPath" : "/import/path" (A path to a directory on the local file system of
Artifactory server),
- "includeMetadata" : true (default),
- "verbose" : false (default),
- "failOnError" : true (default),
- "failIfEmpty" : true (default)
}
application/vnd.org.jfrog.artifactory.system.ExportSettings+json
{
+ "exportPath" : "/export/path" (A path to a directory on the local file system of
Artifactory server),
- "includeMetadata" : true (default),
- "createArchive" : false (default),
- "bypassFiltering" : false (default),
- "verbose" : false (default),
- "failOnError" : true (default),
- "failIfEmpty" : true (default),
- "m2" : false (default),
- "incremental" : false (default),
- "excludeContent" : false (default)
}
application/vnd.org.jfrog.artifactory.system.Version+json
{
"version" : "2.2.2",
"revision" : "10427",
"addons" : [ "build", "ldap", "properties", "rest", ... ] (list of active addons)
}
Artifactory Pro
Introduction
Artifactory offers a set of powerful features as part of Artifactory Pro.
Artifactory Pro is a set of Add-ons bundled of the open-source Artifactory version. on top
Artifactory Pro is available commercially or with selected support contracts. Here you can . find out more about Artifactory Pro
The Add-ons included in the Power Pack are:
Build Integration
License Control
Repository Replication
YUM Repositories
P2 Repositories
NuGet Repositories
RubyGems Repositories
Advanced REST (APIs stating "Requires Pro")
Properties
User Plugins
Repository Layouts
Smart Searches
LDAP Groups
Single Sign-on and Atlassian Crowd Integration
Filtered Resources
Watches
WebStart and Jar Signing
Contrasting Artifactory OSS, Pro and Artifactory Online
Refer to the in order to compare the features and services offered with each Artifactory Artifactory Version Comparison Matrix
version.
For any queries or to receive further information, please contact . support@jfrog.com
1.
2.
Installation
Please see the following instructions on . How to Install Add-ons
Installing the Artifactory Pro Power Pack
Introduction
Installing the Artifactory Pro Power Pack is a two-step process:
Install the Artifactory Pro Power Pack or upgrade an exiting Artifactory to include the Pro Power Pack
Activate the Pro Power-Pack by entering your Artifactory Pro License.
1. Downloading
Purchase or request an evaluation of the Artifactory Pro Power Pack . By return email you receive a download link to from JFrog's web site
download the Artifactory Pro Power Pack and a unique license key.
2. Installing
Installing and Upgrading
If you are setting up a clean installation of Artifactory Pro Power Pack, follow the regular . Installing Artifactory with the Pro Installation Instructions
Power Pack is identical to installing the Artifactory OSS version.
When upgrading from a previous version of Artifactory, Artifactory OSS or Artifactory Pro Power Pack, follow the regular . Upgrade Instructions
Configuring a License Key
As part of your purchase/evaluation you were also provided with a unique product license key.
To activate your Artifactory Pro you must enter this license key in Artifactoy's license configuration page.
This is performed by an Artifactory administrator. From the Admin tab go to and entering the data in the License Configuration -> RegisterPro
field.
Upgrading from OSS to Pro will keep all your data
Upgrading an instance of Artifactory OSS to Artifactory Pro of the same-version only requires replacing the file artifactory.war
and configuring a valid license key.
You then have a fully functional Pro version with the same settings and content as the OSS version you upgraded from.
Once you have configured a valid License key, Artifactory Pro Power Pack is fully active and the Pro Power Pack Add-ons appear as 'Activated'
on Artifactory's home page screen.
Enjoy using Artifactory Pro!
Artifactory Version Comparison
Choose the Artifactory Version that Fits You Best
Artifactory OSS Artifactory Pro Artifactory Online
Proxy and Cache Remote
Repository Artifacts
Deploy Artifacts via the UI or
via REST/HTTP
Bulk Artifact Deployment
(from Archive)

Intuitive Slick Web UI
LDAP Authentication
Role Based Authorization
Include/exclude patterns for
Stored Artifacts
Search by Name, Class,
Module Info, XPath Values
UI-based Move/Copy/Delete
Smart "No-Duplicates"
Storage
Share Remote Repository
Configuration

Incremental and Historical
Backup Services
Integration with All Leading
CI-servers
Managing Build Artifacts for
Reproducible Builds
Promotion, Demotion and
Cleanup of Build Artifacts
Automatic 3rd Party License
Violation Detection per Build
Powerful RESTful API for
Release Automation
Annotate Artifacts with
Searchable Properties
Custom Repository Layout for
Non-Maven Module Mgmt.
YUM Repositories
P2 Repositories
Aggregate and Run Bulk
Operations on Search Results
Focused Email Notifications
for Artifact Changes
On Demand Jar Signing and
Web Start Application Hosting
Support for Multiple LDAP
Servers
LDAP Groups Synchronization
Atlassian Crowd Authenticatio
n
Atlassian Crowd Groups
Synchronization
Powerful SSO integration for
NTLM, Kerberos, Etc.
Extend Artifactory with
Groovy-based User Plugins
JFrog Email Support
Free Add-ons for the Time of
your Contract
SaaS-based Maintenance-free
Hosted Repository
Always up-to-date Artifactory
Version
Setup Free Automated
Backups
SLA-based Support
Build Integration
Introduction
Assimilating Artifactory into a continuous integration build process is very straightforward.
Treat the CI server as a regular build client and, as such, the CI server resolves dependencies from Artifactory and deploys artifacts into a
dedicated repository wihtin Artifactory.
The feature of Artifactory takes this integration one step further, by closely integrating your Artifactory and your CI server to Build Integration
provide fully-reproducible builds and full visibility of deployed artifacts, used dependencies and information regarding the build environment.
By using the Build Integration Add-on you are able to:
See all the builds that are published and their build results in Artifactory.
Explore each build's modules, including published artifacts and dependencies with their scope.
Obtain information about the original build environment.
Check if a specific artifact is required/a result of a build, including alerting if such an artifact should be targeted for removal.
Manipulate all the artifacts and/or dependencies from a specific build as a single unit (move, copy, export etc.).
Receive bidirectional links between build and artifact information inside the build server and Artifactory pages.
Jenkins/Hudson, Team City and Bamboo Integrations
The Build Integration currently supports / , and . Similar integration with other build technologies stacks, are Jenkins Hudson TeamCity Bamboo
currently being worked-on - stay tuned.
The build technologies supported are: , , , and builds (look under each CI server to see the Maven 3 and 2 Gradle Ivy/Ant .Net Generic
technologies supported by the plugin for this server).
To learn more about installation and usage instructions specific to your CI server, follow these links:
The Jenkins/Hudson Artifactory Plug-in
The TeamCity Artifactory Plug-in
The Bamboo Artifactory Plug-in
Inspecting and Managing Builds

Builds and Per-Build History
Once you have run a build in your your CI server that deployed to Artifactory, you can immediately see the corresponding build results inside
Artifactory. A new ' ' menu item lists all known CI server projects that published their build results: Builds
The difference between the open source and the commercial version of Build Integration
When using the OSS version of Artifactory, Build Integration includes the Generic View and the ability to traverse and BuildInfo
view build information using Artifactory's REST APIs.
Module Artifacts and Dependencies View, Repository View of Builds and the ability to export and
manipulate build items require the Artifactory Power Pack.
1.
2.
3.
Each build corresponds to its CI server project (job) counterpart and contains a build history of all runs, that reflect the build history in the CI
server:
For each build item in the history you can drill down and obtain more fine details about it, as explained in the next section.
You can also view the build in the CI server by selecting 'Show in CI Server'. In addition, you can also navigate back to Artifactory from the CI
server UI.
Build-level Information
Drilling-down into the single build level, each build contains three sections of information:
Visual general build information about the build and its environment.
Visual display for modules with their artifacts and dependencies.
Generic view of the build information in JSON format.
General Build Information
This section contains general information about the build.
From here, you can save the build's artifacts and/or dependencies as a Smart Search Result to further manipulate the search, as explained
below.
To view build information users must have a 'deployer' permission on some repository path (at minimum).
Build Modules
Each build publishes module(s) into Artifactory, displayed in this view, together with the number of artifacts and dependencies which they
contain.
Module Artifacts and Dependencies
If you drill down even further, you can inspect each module's published artifacts and dependencies.
NOTE!the deployed artifacts are collected with their types and dependencies contain the scope(s) that the dependencies used in during the
build.
You can also go from each item to its tree view in Artifactory and view other details about it.
Build Environment
In the Environment tab, you can view build properties and other environmental details that are otherwise lost if you want to replay the build at a
later point in time (e.g. JDK used, system architecture etc.).
Licenses
In the Licenses tab, you receive a centralized view of all the artifacts and dependencies involved and their license analysis.
Governance
The Governance tab displays the integration status of this build with a Black Duck Code Center application. In this tab you can also find the
components approval statuses, licenses and security vulnerabilities.
See the to learn more about this feature. License Control Documentation
See the to learn more about this feature. Black Duck Code Center Integration
Build Diff
In the Diff tab, you can compare the current build artifacts/dependencies/environment with an older build to see what has changed (new artifacts
added, old dependencies deleted etc).
Release History
The Release History tab displays a timeline of the selected build's release landmarks.
Generic View BuildInfo
The generic view displays a JSON representation of the data used to form the visual build information in Artifactory. BuildInfo
This can be used by REST or for debugging and is also exposed in the basic OSS version of Artifactory.
Exporting and Manipulating Build Items
From the build's general information panel, you can save the build's artifacts and/or dependencies as a Smart Search Result and then
manipulate it in order to promote it to another repository, copy it or export all the items to disk to have an external distributable unit of the build
with all its dependencies and artifacts.
1.
2.
Repository View of Builds
Artifacts inside Artifactory are also aware of their possible association to builds. When an artifact is associated with a build, either as a published
artifact or as a dependency it is visible on a new tab (when selecting the artifact in the tree view). Builds
Moreover, you also receive warnings when trying to remove from the user interface, an artifact that is associated with one or more builds and
which without, build reproducibility is affected.
You can navigate directly from the Builds view to the build information in Artifactory or to the build page in your CI
Server:
Behind the Scenes
Behind the scenes the Artifactory plug-in for your CI server performs two major tasks:
It deploys all the artifacts in one go to Artifactory. This is performed in an optimized and expedient manner and only at the end of the
build, guaranteeing a more coherent deployment when building multi-module projects (Maven's and Ivy's methods deploy at the end of
each sub-module cycle, which can result in partial deployments if the build fails in a later module).
It sends a data object to Artifactory via REST at the end of deployment. is a structured JSON object containing BuildInfo BuildInfo
all the data about the build environment, artifacts and dependencies, in a standard and open manner.
Jenkins (Hudson) Artifactory Plug-in
Before You Begin
Setting-up Jenkins/Hudson
The Jenkins/Hudson Plug-in
Artifacts association with builds is retained regardless if you move or copy the artifact inside Artifactory, since this association is
maintained by the artifact's checksum which remains constant, regardless of the artifact's location.
You can find the latest Java-bindings artifacts and the source . BuildInfo here here
Please make sure to read the general information about before reading the Jenkins-specific Artifactory's Build Integration
documentation.
1.
2.
To integrate with Jenkins you must install the OSS Artifactory Jenkins Plug-in from Jenkins's Plug-ins Manager.
The plug-in provides:
Easy setup for deploying to Artifactory.
Enhanced deployment transferring additional important build information to Artifactory.
UI integration allowing moving from a Jenkins build directly to Artifactory.
Release Management with Staging and Promotion.
Supported Build Technologies:
The plug-in currently supports: , , , and builds. Maven 3 Maven 2 Gradle Ivy/Ant
Installing and Configuring the Plug-in
To install the Jenkins Artifactory plug-in please follow the instructions on the . Jenkins's Plug-in Center
The configuration involves two steps:
Setting up Jenkins to recognize your Artifactory server
Pointing a Jenkins build at a target local repository in Artifactory to which it should deploy the build artifacts - Jenkins queries
Artifactory's available target repositories using Artifactory's REST API and allows you to select one.
It is recommended that you also configure Jenkins to use Artifactory for dependency resolution.
This is currently not part of the plug-in and is performed in the regular way that a build is configured, typically by changing the or settings.xml
the of the user running Jenkins. ivysettings.xml.xml
Navigating Between Jenkins and Artifactory
Each build viewed in Artifactory corresponds to its Jenkins job counterpart and contains a build history of all runs, that reflect the build history in
Jenkins:
For each build item in the history you can . drill down and obtain more details about it
You can also view the build in the CI server by selecting 'Show in CI Server'.
You can also navigate back to Artifactory from Jenkins, as shown below:
TeamCity Artifactory Plug-in
Overview of TeamCity Artifactory Plugin
The TeamCity Artifactory plugin brings CI Build Integration to TeamCity users. This allows you to capture information about deployed artifacts,
resolved dependencies and environment data associated with TeamCity build runs. There is also full traceability for your builds.
Build Integration also takes care of deploying your artifacts to Artifactory efficiently.
You can read more about the concept of Build Integration, BuildInfo and how it is used in Artifactory . here
Installing the Plugin
Requirements
Some features of the plugin only run on the recent versions of Artifactory and TeamCity.
To make the most of the plugin, the recommended requirements are:
Artifactory 2.2.5 or later.
JetBrains TeamCity 5.1.3 or later.
Installation
Download the version of the plugin according to the compatibility matrix below:
For TeamCity 7.1.xteamcity-artifactory-plugin-2.1.5.zip.
Before you begin
Please make sure you read the general information about before reading the TeamCity-specific Artifactory's Build Integration
documentation.
Release Management with the TeamCity Artifactory Plugin
Version 2.1.0 of the plugin introduces powerful capabilities. Release Management and Promotion
Support for multiple Build Runner types
The TeamCity Artifactory plugin supports almost all build runner types, including: , (with Ivy modules support), Maven2/3 Ivy/Ant Gradl
, , , and . e NAnt MSBuild FxCop Ipr
For TeamCity 6.5.x . teamcity-artifactory-plugin-2.1.2.zip
For TeamCity 6.x . teamcity-artifactory-plugin-2.0.1.zip
For TeamCity 5.x . teamcity-artifactory-plugin-1.1.3.zip
Plugins are deployed to TeamCity by placing the packaged plugin into the folder and $TEAMCITY_USER_HOME/.BuildServer/plugins
restarting TeamCity.
NOTE! thatif you have an older version of the plugin, make sure to remove it.
Compatibility Matrix
Artifactory plugin version TeamCity version Artifactory version
1.0 5.1 2.2.4
1.0.1 5.1.1 2.2.5+
1.1.1 - 1.1.2 5.1.3 2.3.0+
1.1.3 5.1.5 2.3.0+
2.0.0 6.0+ 2.3.0+
2.0.1 6.0+ 2.3.0+
2.1.0 6.5+ 2.3.4+
2.1.1 6.5+ 2.3.4+
2.1.2 6.5.5+ 2.3.4+
2.1.3 6.5.5+ 2.6.0
2.1.4 7.1+ 2.6.0+
2.1.5 7.1+ 2.6.6+
Configuration
To use the TeamCity Artifactory plugin you must first configure your Artifactory server(s) in TeamCity's server configuration. You can then set up
a project build runner to deploy artifacts and Build Info to a repository on one of the configured Artifactory servers.
Configuring System-wide Artifactory Server(s)
To make Artifactory servers globally available to project-runner configurations, they must be defined in Administration->Integrations->A
. rtifactory
Click on " " and fill in the URL of the Artifactory server. Create new Artifactory server configuration
Deployer credentials can be set at the global level for all builds. Deploy credentials can be set or overridden at a project build level.
Resolving repository username and password is optional and only used when querying Artifactory's REST API for a list of configured repositories
(credentials are only required if the target instance does not allow anonymous access).
Configuring Project-specific Runners
Editing Project-specific Configuration
To set up a project runner to deploy build info and artifacts to Artifactory go to Administration->$PROJECT_NAME->$BUILD_NAME->Edit-
. >Runner (Step 3)->Deploy artifacts to Artifactory
When selecting an Artifactory server URL, the server is queried for a list of configured repositories (using the credentials in the server
configuration, if configured). This populates the "Target Repository" combobox with a list of target repositories to deploy to.
If the repository list remains empty, ensure the specified Artifactory server URL, credentials and proxy information (if provided) are valid.
Any information about communication errors that might occur can be found in the TeamCity server logs.
The option is only available when using a 'Maven2' Build Runner. 'Deploy Maven Artifacts'
Running License Checks
Use the Artifactory Pro feature to discover and handle third party dependency licensing issues as part of the build. License Control
Check the 'Run License Checks'checkbox if you want Artifactory to scan and check the licenses of all
dependencies used by this build.
If you want to inform selected users about any license violations detected while scanning, enter a list of email
addresses in the notification recipients text box.
Advanced Options
In addition, you have more advanced options:
The area allows you to specify which artifact files produced by the build are published to Artifactory. At the end of 'Published Artifacts'
the build the plugin locates artifacts in the build's checkout directory according to the specified artifact patterns and publishes them to
Artifactory to one or more locations, optionally applying mapping for the target path of each deployed artifact. The pattern and mapping
syntax for Published Artifacts is similar to the one used by TeamCity for . Build Artifacts
The area lets you specify dependency patterns for published artifacts that should be downloaded from 'Downloaded Artifacts'
Artifactory before the build is run. You can have detailed control over which artifacts are resolved and downloaded by using query-based
resolution, adding to your artifact paths a query with the properties that the artifact should have before it can be downloaded. For further
information read here about . Resolution by Properties
Attaching Searchable Parameters to Build-Info and to Published Artifacts
Under Administration->$PROJECT_NAME->$BUILD_NAME->Edit->Runner (Step 6)->Properties and Environment
, it is possible to define parameters to be attached to the build-info and produced artifacts. Variables
To define a parameter click on the "Add new property" or "Add new variable" buttons (both system properties and environment variables are
supported).
Available parameter types:
buildInfo.property.* - All properties starting with this prefix are added to the root properties of the build-info
artifactory.deploy.* - All properties starting with this prefix are attached to any deployed produced artifacts
It is also possible to point the plugin to a properties file containing the aforementioned properties.
To point to such a file, define a property by the name and set its value to the absolute path of the buildInfoConfig.propertiesFile
properties file.
As of version 2.1.4, the above configuration is not backward compatible and you may need to re-save the builds configuration for them
to run properly.
The given path and file should be present on the machine running the build agent - . not the server!
Viewing Project-specific Configuration
Existing project configuration can be viewed from : Projects->$PROJECT_NAME->$BUILD_NAME->Settings->Runner settings
1.
2.
3.
Running a Build with the Artifactory Plugin
Once you have completed setting up a project runner you can run a project build. The Artifactory plugin takes effect at the end of the build and:
For all build runner types - Publishes the specified Published Artifacts to the selected target repository and applies proper path
mappings.
For Maven or Ivy/Ant build runner - Deploys all artifacts to the selected target repository in one go (as opposed to the deploy at the end
of each module build, used by Maven and Ivy).
Deploys the Artifactory BuildInfo to Artifactory, providing , with links back to the build in TeamCity. full traceability of the build in Artifactory
3.
You can also link directly to the information in Artifactory from a build run view:
Triggering Builds in Reaction to Changes in Artifactory
The plugin allows you to set a new type of trigger that periodically polls a path in Artifactory, a folder or an individual file. Whenever a change is
detected to this path, for example new artifacts have been deployed, the TeamCity build is triggered.
This feature can only be used with the Artifactory Pro Power Pack.
To configure a new build trigger, first select the Artifactory Build Trigger from Administration->$PROJECT_NAME->$BUILD_NAME->Edit->
: Build Triggering
Select the server, repository and paths in the repository for which you would like to automatically trigger a build following a change in the item
content.
Complete the username and a password fields of a valid deployer.
NOTE! that the user must have deploy rights on any local repository).
Proxy Configuration
Currently, TeamCity does not provide a global point of proxy configuration; so where the target Artifactory server must be accessed via a proxy,
proxy configuration can be achieved by setting the following properties inside the $TEAMCITY_USER_HOME/.BuildServer/config/intern
file. al.properties
Narrow down the scope for scanning
When scanning a remote folder for changes, Artifactory has to traverse the folder content and decide if any content has changed. For
deep folders this traversal can become quite expensive.
Therefore, it is recommended to keep the scanning scope to a minimum.
1.
2.
1.
2.
1.
2.
3.
4.
1.
1.
2.
3.
1.
2.
1.
2.
3.
4.
1.
2.
3.
4.
org.jfrog.artifactory.proxy.host
org.jfrog.artifactory.proxy.port
org.jfrog.artifactory.proxy.username
org.jfrog.artifactory.proxy.password
License
The TeamCity Artifactory plugin is available under the Apache v2 License.
To see the Teamcity plugin in action you can watch the short demo screencast below.
Changelog
2.1.5 (07 Jul 2013)

Fix security issue - TCAP-172
Improve generic resolution - BI-152
2.1.4 (21 Aug 2012)
Compatible with TeamCity7.1.
Bug Fixes
2.1.3 (30 May 2012)
Compatible with TeamCity7.
Support 'Perforce' in releasemanagement.
Support multiple deploy targets for the same source pattern in generic deploy.
Support for custom build dependencies resolution per build.
2.1.2 (12 Dec 2011)
Compatible with Gradle 1.0-milestone-6.
2.1.1 (09 Aug 2011)
Support for Gradle milestone-4
Better support for releasing nested Maven projects
Fixed minor Maven deployments discrepancies
2.1.0 (14 Jul 2011)
Release management capabilities
Bug fixes
2.0.1 (9 Jan 2011)
Auto Snapshot/Release target repository selection
Add ivy/artifact deploy patterns
Improved Gradle support
Bug fixes
2.0.0 (5 Dec 2010)
Support for Gradle builds
Support for maven3 builds
Default deployer add resolver credentials
Support for muti steps builds
1.
1.
2.
3.
1.
2.
3.
4.
5.
1.1.3 (21 Nov 2010)
Include/exclude pattern for artifacts deployment
1.1.2 (7 Nov 2010)
Control for including published artifacts when running license checks
Limiting license checks to scopes
Control for turning off license discovery when running license checks
TeamCity Artifactory Plugin - Release Management
General
The Artifactory plugin includes release management capabilities for Maven and Gradle runners that use Subversion, Git or Perforce for VCS.
The plugin allows you to manually stage a release build, allowing you to:
Change values for the release and next development version
Choose a target staging repository for deployment of the release, and
Create a VCS tag for the release.
Staged release builds can later be promoted or rolled-back, changing their release status in Artifactory and, optionally, moving the build artifacts
to a different target repository.
Inside Artifactory the history of all build status change activities (staged, promoted, rolled-back, etc.) is for full Recorded and Displayed
traceability.
Maven Release Management
Release management with Maven is performed entirely by the plugin and executes the Maven build only once.
These are the basic steps that the plugin performs:
Change the POM versions to the release version (before the build starts)
Trigger the Maven build (with optionally different goals)
Commit/push changes to the tag (Subversion) or the release branch (Git)
Change the POM versions to the next development version
Commit/push changes to the trunk
In case of a failure, the plugin does its best to rollback the changes (local and committed).
Configuring Maven Runners
To enable release management in Maven runners, edit the runner's step configuration and check the "Enable Artifactory release management"
checkbox.
Staging a Maven Release Build
Once the release management is enabled, the Artifactory Release Management tab appears at the top of the build page.
Clicking on the tab reveals configuration options for the release build:
The release staging page displays the last built version (the version is of the root pom and it is taken from the last non-release build). Most of the
fields in the form are completed with the default values.
Version configuration controls how the plugin changes the version in the pom files (global version for all modules, version per module or no
version changes).
If the Create VCS checkbox is marked (default), the plugin commits/pushes the poms with the release version to the VCS system with the
commit comment. When using Git, there's also an option to create a release branch.
If the target Artifactory server is the Pro edition, the last section allows you to change the target repository (the default is the release repository
configured in Artifactory publisher) and to add a staging comment which is included in the build info deployed to Artifactory.
Click on the "Build and Release to Artifactory" button to trigger the release build.
Promoting a Release Build
After a release build successfully completes, it is possible to promote the build.
This step is not mandatory, but very useful if you want to mark the build as released in Artifactory and to move/copy the built artifacts to another
repository so the artifacts are available to the customers.
To activate the action browse to the build's result page and click the Artifactory Release Promotion link.
1.
2.
3.
4.
5.
NOTE!that Artifactory Pro is required for promotion.
Clicking on the link will open the promotion dialog:
Select the target status (Released or Rolled-Back) of the build and optional comment to display in the build in Artifactory. To move or copy the
build artifacts, select the target repository.
Gradle Release Management
The release management in Gradle relies on version (and other) properties managed by the file. You add all the relevant gradle.properties
properties to the release management configuration, and the plugin will read and modify those properties in the file. gradle.properties
Changes the gradle.properties with release values (before the build starts)
Triggers the Gradle build (with optionally different tasks and options)
Commits/pushes changes to the tag (Subversion) or the release branch (Git)
Changes the gradle.properties with next integration values
Commits/pushes changes to the trunk
Configuring Gradle Runners
The release management is also available for Gradle runners.
To enable Gradle release management, edit the runner's step configuration and mark the "Enable Artifactory release management" checkbox.
Staging a Gradle Release Build
Once the release management is enabled, the Artifactory Release Management tab appears at the top of the build page.
Clicking on the tab reveals configuration options for the release build:
1.
2.
The release staging tab displays the release and next development properties configured for the runner. The values are read from the gradle.pro
file and calculation of the release and next integration version is attempted and displayed in the text fields. perties
If create VCS tag is checked (default), the plugin commits/pushes the poms with the release version to the VCS
system with the commit comment. When using Git, if 'Use release branch' is marked, the next release version
changes are carried out on the branch instead of the current checkout branch.
The final section allows you to change the target repository (the default is the release repository configured in Artifactory publisher) and optional
staging comment which includes the build info deployed to Artifactory.
Promotion is same as in . RTD:Maven
Working with Subversion
The release management supports Subversion SCM when using one checkout directory.
During the release the plugin performs the following:
Commits the release version directly to the tag (if create tag is checked). The release version is not committed to the to the working
branch.
Commits the next development version to the working branch
Working with Git
The project must perform source checkout on the agent side; if the build is configured to checkout on the server, the release plugin modifies the
checkout configuration for the duration of the build and reverts the change when the build is performed.
1.
2.
3.
4.
5.
6.
The remote URL should allow Read+Write access.
If create branch is checked, creates and switches to the release branch
Commits the release version to the current branch
Creates a release tag
Pushes the changes
Switches to the checkout branch and commit the next development version
Pushes the next development version to the working branch
NOTE!that changes are only committed if changes are made to the files (pom files or gradle.properties).
Bamboo Artifactory Plug-in

Before You Begin
Overview
The Bamboo Artifactory plug-in brings CI Build Integration to Bamboo users, allowing the capture of information about deployed artifacts,
resolved dependencies and environment data associated with Bamboo build runs. In addition, you have full traceability for your builds.
The plug-in also efficiently deploys your artifacts to Artifactory.
Installing the Plug-in
Requirements
Artifactory 2.2.5 or later. For best results and optimized communication it is recommended to use the latest version of Artifactory.
is required for advanced features, such as and enhanced . Artifactory Pro License Control Build Integration
Atlassian Bamboo 2.6.0 or later running on JDK 1.6 or later.
Maven 3.
Gradle 0.9 or later.
Ant + Ivy 2.1.0 or later.
Installation
Download the latest version of the plugin:
For Bamboo 2.x: . bamboo-artifactory-plugin-1.1.0.jar
For Bamboo 3.x: . bamboo-artifactory-plugin-1.2.0.jar
For Bamboo 3.1.x: . bamboo-artifactory-plugin-1.4.0.jar
For Bamboo 3.4.2+: . bamboo-artifactory-plugin-1.5.2.jar
For Bamboo 4.0: . bamboo-artifactory-plugin-1.5.3.jar
For Bamboo 4.1+:bamboo-artifactory-plugin-1.5.5.jar
For Bamboo 4.2+,4.3+:bamboo-artifactory-plugin-1.5.6.jar
For Bamboo 5.0+:bamboo-artifactory-plugin-1.6.0.jar
Put the packaged plug-in archive inside the folder and restart Bamboo. If you have an older $BAMBOO_HOME/webapp/WEB-INF/lib
version of the plug-in, make sure to remove it first.
(The plug-in uses the installation method). Bamboo Plug-in Version 1
Please make sure you read the general information about before reading the Bamboo-specific Artifactory's Build Integration
documentation.
Supported build technologies
The Bamboo Artifactory plug-in currently provides full support for , and builds. are Maven 3 Gradle Ivy Generic Deployment Tasks
available for all builder types.
Release Management
Version 1.4.0 introduces . Release Management Capabilities
1.
2.
3.
4.
1.
2.
3.
Configuration
To use the Bamboo Artifactory plug-in you must configure your Artifactory server(s) in Bamboo's server configuration. You can then set up a
project builder to deploy artifacts and build-info to a repository on one of the configured Artifactory servers.
Configuring Maven 3, Gradle and Ivy Builders
Before you begin with any Artifactory-specific setup, ensure that Maven 3, Gradle and/or Ivy builders are available for project configurations.
To define build capabilities as standard:
Go toAdministration -> Build Resources -> Server Capabilities:
Select "Executable" as the Capability Type
Select "Artifactory Maven 3", "Artifactory Gradle" or "Artifactory Ivy" as the type from the "Types" list.
Ensure "Path" points to an installation directory of the selected builder type.
Configuring System-wide Artifactory Server(s)
To make Artifactory servers available to project configurations, they must be defined underAdministration -> Plugins ->
. Enter the Artifactory server URL in the " " form. Artifactory Plugin Add New Server Configuration
NOTE! that username and password are optional and only used when querying Artifactory's REST API for a list of configured repositories
(credentials are only required if the target instance does not allow anonymous access).
Configuring a Project Builder
To set up a project task to deploy build-info and artifacts to Artifactory:
Go to the step of your jobs configuration. Tasks
When adding a task type, select the Artifactory Maven 3, Gradle or Ivy builder.
3. The builder configuration fields appear and include Artifactory and build-info configuration options.
Selecting an Artifactory Server URL
The list is populated with a list of available target repositories as returned by the server (queried with the credentials in the 'Target Repository'
server configuration, if provided).
If the repository list remains empty, ensure the specified Artifactory server URL and credentials (if provided) are valid.
Select the target repository you want Bamboo to deploy artifacts and build-info to.
Running License Checks
Use the Artifactory Pro feature to discover and handle third party dependency licensing issues as part of the build. License Control
Check the'Run License Checks'checkbox if you want Artifactory to scan and check the licenses of all
dependencies used by this build.
If you want to inform selected users about any license violations detected while scanning, enter a list of e-mail
addresses to the notification recipients text box.
Generic (Freestyle) Deploy tasks
The Generic Deploy task can be used in any job with any combination of tasks; made to provide minimal Build Info support for all types, the task
collects all available information from Bamboo regarding the build and provides a deployment mechanism for produced artifacts.
Adding the Generic Deploy task automatically deploys Build Info including artifacts collected from the Published
Artifacts declaration.
The 'Published Artifacts' declaration lets you specify which artifact files produced by the build are published to Artifactory. At build conclusion,
the plugin locates artifacts in the build's checkout directory according to the specified artifact patterns and publishes them to Artifactory, optionally
applying mapping for the target path of each deployed artifact.
Make sure to add the Generic Deploy task as a final step!
Attaching Searchable Parameters to Build-Info and Artifacts Deployed by the Plug-in
Under , it is possible to define parameters that are attached to the Administration -> Build Resources -> Global Variables
build-info and produced artifacts.
To define a parameter complete the blank parameter row and click "Save".
The available parameter types are:
buildInfo.property.*- All properties starting with this prefix will be added to the root properties of the build-info.
artifactory.deploy.*- All properties starting with this prefix will be attached to any deployed produced artifacts.
It is also possible to point the plug-in to a properties file containing the aforementioned properties.
To point to such a file, define a property namedbuildInfoConfig.propertiesFileand set its value to the
absolute path of the properties file.
Running a Build with the Artifactory Plug-in
The given path and file should be present on the machine that is running the build agent, . not the server
1.
2.
1.
1.
1.
2.
1.
2.
1.
Once you have completed setting up a project builder you can run it. The Artifactory plug-in commences at the end of the build and:
Deploys all artifacts to the selected target repository in one go (as opposed to the deploy at the end of each module build, used by
Maven/Ivy).
Deploys the Artifactory build-info to the selected server, which provides , with links back to the full traceability of the build in Artifactory
build in Bamboo.
You can also link directly to the information in Artifactory from a build run view in Bamboo:
License
The Bamboo Artifactory plug-in is available under the Apache v2 License.
Changelog
1.6.0 (16 Jul)
Support form Bamboo 5.0
1.5.6 (03 Sep)
Support form Bamboo 4.2
1.5.5 (03 Sep)
Support for include/exclude captured environment variables ( ) BAP-143
Bug fixes ( ) MAP-41 MAP-40 GAP-129 BAP-148 IAP-32
1.5.4 (25 Jun)
Support Bamboo 4.1.
Bug fixes. ( ) JIRA
1.5.3 (02 Apr)
1.
1.
2.
1.
2.
3.
4.
1.
2.
1.
1.
2.
1.
2.
3.
1.
1.
1.
1.
1.
2.
3.
1.
2.
1.
2.
3.
Support Bamboo 4.0.
1.5.2 (02 Apr)
Support Perforce for release management. ( ) BAP-133
Bug fixes. ( ) JIRA
1.5.1 (05 Jan)
Compatible release plugin for version 3.4.2. ( ) BAP-116
Support for Gradle properties deployment. ( ) BAP-117
Unique icon for each Artifactory task type.
Setting Bamboo job requirements correctly for all builder types. ( ) BAP-125
1.5.0 (11 Dec)
Compatible with bamboo version 3.3.x.
Compatible with Gradle 1.0-milestone-6.
1.4.2 (19 Sep)
Bug fix ( ) BAP-91
1.4.1 (01 Aug)
Support for Bamboo 3.2.x
Bug fix ( ) BAP-90
1.4.0 (14 Jul)
Introducing Release Management capabilities.
Generic Build Info support for all job types.
Bug fixes.
1.3.2 (14 Jun)
Bug fix ( ) BAP-65
1.3.1 (13 Jun)
Bug fix ( ) BAP-64
1.3.0 (30 May 2011)
1.2.0 (2 Mar 2011)
Support for Bamboo 3.x
1.1.0 (2 Jan 2011)
Gradle Support - Gradle builds are now fully supported with the new Gradle builder
Ivy builds now support custom Ivy patterns for artifacts and descriptors
1.0.3 (21 Nov 2010)
Add Include/exclude pattern for artifacts deployment
Bug fix ( ) BAP-26
1.0.2 (7 Nov 2010)
Control for including published artifacts when running license checks
Limiting license checks to scopes
Control for turning off license discovery when running license checks
1.
2.
3.
4.
5.
Bamboo Artifactory Plugin - Release Management
General
The Artifactory plugin includes release management capabilities for Maven and Gradle jobs using Subversion, Git or Perforce for VCS.
The plugin allows you to manually stage a release build, allowing you to:
Change values for the release and next development version
Choose a target staging repository for deployment of the release, and
Create a VCS tag for the release.
Staged release builds can later be or , changing their release status in Artifactory and, optionally, moving the build promoted rolled-back
artifacts to a different target repository.
Inside Artifactory, the history of all build status change activities (staged, promoted, rolled-back, etc.) is for full recorded and displayed
traceability.
Maven Release Management
Release management with Maven is performed entirely by the plugin and executes the Maven build only once.
Changes the POM versions to the release version (before the build starts)
Triggers the Maven build (with optionally different goals)
Changes the POM versions to the next development version
In case of a failure, the plugin attempts to rollback the changes (local and committed).
Configuring Maven Jobs
To enable release management in Maven jobs, edit the job configuration and mark the "Enable Artifactory release management" checkbox.
Staging a Maven Release Build
Once the release management is enabled, the Artifactory release staging link appears on the top header bar in the job page.
Clicking on the release staging link opens a new page with configuration options for the release build:
The release staging page displays the last build version (the version is of the root pom and it is taken from the last non-release build).
Most of the fields in the form are completed with the default values.
Version configuration controls how the plugin changes the version in the pom files (global version for all modules, version per module or no
version changes).
If the create VCS checkbox is marked (default), the plugin commits/pushes the poms with the release version to the VCS system with the commit
comment. When using Git, there is also an option to create a release branch.
If the target Artifactory server is the Pro edition, the last section lets you change the target repository (the default is
the release repository configured in Artifactory publisher) and to add a staging comment included in the build info
deployed to Artifactory.
After a release build completes successfully, it is possible to promote the build. This is not a required step, but very useful if you want to mark the
build as released in Artifactory and to move/copy the built artifacts to another repository so the artifacts are available to other users.
To activate the action click on the 'Artifactory' tab link in the build result page.
Artifactory Compatibility
Artifactory Pro is required for promotion
1.
2.
3.
4.
5.
Clicking on the link will open the promotion page:
Select the target status (Released or Rolled-Back) of the build and optional comment to display in the build in Artifactory.
To move or copy the build artifacts select the target repository.
Gradle Release Management
The release management in Gradle relies on version (and other) properties managed by the file. gradle.properties
Add all the relevant properties to the release management configuration, and the plugin reads and modifies those properties in the gradle.propert
file. ies
Changes the gradle.properties with release values (before the build starts)
Triggers the Gradle build step (with optionally different tasks and options)
Changes the gradle.properties with next integration values
Configuring Gradle Jobs
The release management is also available for Gradle tasks in the Gradle Artifactory task.
To enable Gradle release management, edit the Artifactory Gradle Task configuration and mark the "Enabled Release Management" checkbox.
Staging a Gradle Release Build
Once the release management is enabled, the Artifactory release staging link appears in the top header bar on the job page.
Clicking on the release staging link opens a new page with configuration options for the release build:
The release staging page displays the release and next development properties configured for the job. The values are read from the gradle.prop
file and calculation of the release and next integration version is attempted and displayed in the text fields. erties
If the Create VCS checkbox is marked (default), the plugin commits/pushes the POMs with the release version to the VCS system with the
commit comment. When using Git, if 'Use Release Branch' is checked, the next release version changes are performed on the branch instead of
the current checkout branch.
The last section allows you to change the target repository (the default is the release repository configured in
Artifactory publisher) and optional staging comment which is included in the build info deployed to Artifactory.
1.
2.
1.
2.
3.
4.
5.
6.
Promotion is the same as . RTD:as in Maven
Working with Subversion
The release management supports Subversion SCM when using one checkout directory.
Commits the release version directly to the tag (if the Create Tag checkbox is marked). The release version is not committed to the to
the working branch.
Working with Git
To work with Git, the Git plugin must be configured to build one branch to checkout to the same local branch. AND
The remote URL should allow Read+Write access.
The plugin uses the Gitclient installed on the machine and uses its credentials to push back to the remote Git repository.

If create branch is marked, creates and switches to the release branch
Commits the release version to the current branch
Creates a release tag
Pushes the changes
Switches to the checkout branch and commits the next development version
Pushes the next development version to the working branch
1.
2.
Working withPerforce
The release management supports Perforce SCM when using one checkout directory.
Commits the release version to the working branch and creates a label pointing to the changed files (if create VCS tag is checked).
NOTE!that changes are only committed if changes were made to the files (POM files or gradle.properties)
License Control
Controlling Third Party Licenses
The License Control Add-on completes the Add-on allowing you full control over the licenses of the dependencies Artifactory Build Integration
used by your builds (and eventually in your software).
This Add-on is part of the Artifactory Pro Power Pack.
As part of the Build Server deployment to Artifactory, it analyzes the used dependencies and tries to match them against a set of license
management rules.
Notifications can be sent to a selected list of recipients about dependencies with unknown or unapproved license information.
To support this feature Artifactory includes a new license management facility where rules about license matching and approval status are
defined. These rules are consulted as part of the license analysis.
Central License Management
Licenses are managed under the Admin tab and then . Configuration -> Licenses
Shallow Clones
Bamboo's Git plugin allows the use of shallow clones. However, this causes the 'push' not to work.
Therefore, when using the Artifactory-Bamboo plugin, you must have shallow clones . unchecked
You can read more about shallow clones here
How does license analysis work?
Automatic analysis is performed upon deployment by examining information found in artifact module files. Currently and Maven POM I
files are supported. vy Descriptor
You can always override the automatic results and assign license information manually to dependencies. You can also compare the
current license status to the auto calculated one and decide what results of the automatic analysis to accept.
License information is stored with the artifact and reused by the automatic license analysis on subsequent builds.
Editing License Information
For each license, you can configure general license information, the regular expression by which to match the license (by comparing it to license
information in module files) and whether the license is an approved one or not.
Artifactory comes preconfigured with all the common licenses and JFrog has already tuned these licenses against common project builds. OSI
If you leave the regexp field blank, Artifactory attempts an exact match against the license key.
Finally, you can export the license list and import it later on to new Artifactory instances.
Using Build Licenses
Build Server Configuration
When you run a build from your CI server (Hudson, TeamCity or Bamboo), configure the Artifactory Plugin to run license checks as part of the
build.
Below is a sample section from the Hudson configuration of the Artifactory Plugin:
You can configure whether or not you wish license checks to take place as part of deploying Build Info to Artifactory (the Build Info Bill of
Materials must be deployed to Artifactory for license checks to run).
You can also set a list of recipients to be notified about license violations as soon as they occur. This way whenever a dependency with an
unknown or unapproved license is added to the build recipients receive an immediate email notification and can tend to any potential license
violation.
Examining Build Licenses
Once the build has finished on the build server and Build Info has deployed to Artifactory, license checks are run.
The build license information is available under the Artifacts tab and then Drill down to the specific build and select the Browse -> Builds.
tab. Licenses
The licenses tabs contains information about all the dependencies used in the build (with selectable scopes) and the license they are associated
with.
Sending license violation notifications is performed through Artifactory and requires a to be configured. valid mail server
Not failing the build
Currently, Artifactory does not fail the build as a result of license violations.
This is an informed decision in the spirit of allowing technical development to continue, while alerting others about the advent of
unauthorized dependencies in near or real-time, so they can be addressed early on by the appropriate parties.
1.
2.
3.
You can export this information as a CSV file.
The summary panel displays the overall count of licenses by status and inside the table itself, licenses are displayed in different colors according
to their status:
License Status Description
Unapproved
The license found is not an approved license

Unknown License information was found but cannot be related to any license
managed in Artifactory
Not Found No license information could be found for the artifact.
Neutral The license found is unapproved, however another approved license
was found for the artifact
(Only applicable for artifacts that are associated with multiple
licenses)
Approved The license found is an approved license
Inline License Editing
Admins can also change the license information directly from the decency in the table, using the pop-up action: Edit License
Running Manual License Discovery
Manually run the license discovery rules after a build has already run. There are several reasons why you may want to do this:
License rules (configured licenses and regular expressions) have changed and you want to compare the existing build licenses with the
results of the new rules, or use them to complete missing license information.
To test the current rules against the dependencies and tweak the rules, if necessary.
To check which license information can come from rules and which license information must be set manually.
1.
2.
3.
To trigger license discovery select the button. Auto-find Licenses
Any license conflicts are displayed to the right of the table, with the option to override the existing license
information with the discovered license (you must have annotate permissions for the artifacts you want to override
licenses for).
Setting License Information Manually
To set license information for artifacts manually:
Navigate to the artifact from the tree browser or from the pop-up action on a dependency in the the build's licenses Show in Tree
table.
Select the artifact in the tree browser
Select the panel and under the label choose or to change the artifact's licenses. General License Add Edit
NOTE!that an artifact can be associated with multiple licenses.
Scanning artifact Maven/Ivy model for license
Another option for editing the license information is by scanning the Maven/Ivy model for licenses.
Once you have the artifact selected in the tree browser go to the tab and under the label choose and confirmlicenses General License Scan
found in the scan results, if any.
License Information as Properties
Internally, license information is stored as regular , using the built-in property name. properties artifactory.licenses
Therefore, all operations with properties are available to license information (searches, recursive assignment, property-based deployment and
resolution etc.)
Licenses REST API
License-oriented searches and management operations are available through the REST API.
Refer to the for usage information. REST API Documentation
To see the License Control Add-on in action you can watch the short demo screencast below.
Black Duck Code Center Integration
Introduction
The integration between Black Duck Code Center and Artifactory offers you an automated, non-invasive approach to the open source component
approvalprocess, in addition to proactively monitoring for security vulnerabilities that may be associated with specific binary components.
License, security vulnerability and approval status are pulled from theBlack Duck Knowledge Base.
This chapter describes:
How to configure Artifactory with the Code Center
Additional Artifact Information
Artifactory Code Center Build Integration
The add-on adds a Governance tab in Builds, allowing automation of the approval process of an existingBlack Duck application in accordance
with the build info.
Configuring Artifactory with Code Center
To configure Artifactory with Code Center click on the Admin tab and then go to . Configuration -> Governance
Server URI URI of the Black Duck Code Center instance
Username Black Duck Code Center authentication username
Password Black Duck Code Center authentication password
Connection Timeout Network timeout in milliseconds. Default is set to 20 seconds
NOTE! that you can click on the Test button to verify that the credentials are correct.
Additional Artifact Information
The window is divided into three sections with the information coming from the Code Center Knowledge Base:
General Information including the Component Name, Version and ID together with a link to the Homepage and description of the artifact
Details of the license
List of known security vulnerabilities, if any.
To view the additional metadata received from the Code Center in the Tree Browser click on the Artifacts tab and then go toBrowse -> Tree
. Browser
From the Tree Browser select the artifact to be viewed and select the Governance tab.
NOTE! that you can click on Editto manually edit the Code Center Component ID.
The information appearing in the Governance tab is also cached in the Properties tab and can be both searched for
and edited.
Artifactory Code Center Build Integration
Builds performed in the CI Server and deployed in Artifactory can be integrated into the Code Center approval process in an automated
andnon-invasive approach. When a build completes successfully, Artifactory can run compliance checks and allow you to receive a report to
see the current state of the build in terms of governance via the user interface.
CI Configuration
To run the Code Center compliance checks, you must first configure the CI Server Job.
The Application Name and Application Version are mandatory fields and represent the . You can optionally existing Code Center application
add the email address of where the compliance report is to be sent.
For additional information on the remaining fields, click on the icon on each field. ?
Governance Status Summary View
Once the CI Job is completed, compliance checks are run automatically.
To view the build integration of the Code Center click on the Artifacts tab and then go to and select the required build from the Browse -> Builds
list. Once you have selected the required build, click the Governance tab.
The Code Center Application section displays application information as it appears in the Code Center and includes the overall approval status.
In addition, the Components and Vulnerabilities are displayed.
The Components section shows how many components were found in the BOM and created in the Code Center application. Details of their
status (pending, rejected etc..) are given together with licensing details taken from the knowledge base of Black Duck.
The Vulnerabilities section displays the aggregated vulnerabilities found in the application. These details are also taken from the knowledge
base of Black Duck.
Grouping and Sorting

Components can be sorted according to any field. You can also group components according to License, Status or
Once you have updated the status in the Code Center - either approve or reject, click on the Governance tab again to refresh the
updated information in Artifactory.
Hovering over the component with the mouse displays a bubble
providing you with a number
of possible actions such as "Show Request" which links you to
the Code Center UI and allows
you to perform other tasks such as approve and reject.
Scope by clicking on the group icon on the column header providing you with a variety of comprehensive
views of the current status of the build.
For example, the screenshot below shows the build components displayed according to various types of license.
LDAP Groups
Overview
The LDAP Groups Add-on allows you to synchronize your LDAP groups with Artifactory and leverage your existing organizational structure for
managing group-based permissions.
Unlike many LDAP integrations, LDAP groups in Artifactory use super-fast caching, and has support for both Static, Dynamic and Hierarchical
mapping strategies. Powerful management is accomplished with multiple switchable LDAP settings and visual feedback about the up-to-date
status of groups and users coming from LDAP.
LDAP groups synchronization works by instructing Artifactory about the external groups authenticated users belong to. Once logged-in, you are
automatically associated with your LDAP groups and inherit group-based permission managed in Artifactory.
Usage
LDAP Groups settings are available under the Admin tab and then . Security -> LDAP Settings
To use LDAP groups you must first from the LDAP Settings screen. You set up an LDAP server for authentication must also alert
Artifactory about the correct LDAP group settings to use with your existing LDAP schema.
Group Synchronization Strategies
Artifactory supports three ways of mapping groups to LDAP schemas:
Static: Group objects are aware of their members, however, the users are not aware what groups they belong to.
Each group object such as or holds its respective member attributes, typically or groupOfNames groupOfUniqueNames member uni
, which is a user DN. queMember
Dynamic: User objects are aware of what groups they belong to, but the group objects are not aware of their members.
Each user object contains a custom attribute, such as , that holds the group DNs or group names of which the user is a member. group
Hierarchical: The user's DN is indicative of the groups the user belongs to by using group names as part of user DN hierarchy.
Each user DN contains a list of 's or custom attributes that make up the group association. ou
For example,
indicates that belongs to two groups: and . uid=user1,ou=developers,ou=uk,dc=jfrog,dc=org user1 uk developers
Settings Name The name of the LDAP setting Unique ID.
LDAP URL The location of the LDAP server in the form of:
ldap://myserver:myport/dc=sampledomain,dc=com
User DN Pattern A DN pattern that can be used to login users directlyto LDAP.
This pattern is used for creating a DN string for 'direct' user authentic
ation, here the pattern is relative to the base DN in the LDAP URL.
The pattern argument {0} is replaced with the username.
This works only if anonymous binding is allowed and a direct user
DN can be used, which is not the default case for Active Directory
use User DN search filter instead).
For example: uid={0},ou=People
Auto Create Artifactory Users Marking this checkbox determines whether users should be
auto-created when using LDAP, otherwise they are transient and
associated with auto-join groups defined in Artifactory.
Email Attribute An attribute that can be used to map a user's email to a user created
automatically in Artifactory.
Search FIlter A filter expression used to search for the user DN used in LDAP auth
entication.
This is an LDAP search filter (as defined in 'RFC 2254') with optional
arguments. In this case, the username is the only argument, denoted
by '{0}'.
(uid={0}) - this searches for a username match on the attribute.
Authentication to LDAP is performed from the DN found, if
successful.
Search Base Context name to search in, relative to the base DN in the LDAP URL.
ex: ou=users
With LDAP Group Add-on enabled, it is possible to enter multiple
search base entries separated by the '|' sign. ex:
ou=internalUsers,ou=hq|ou=externalUsers
This parameter is optional.
Manager DN Used only with "search" authentication method.
It is the full DN of the user that binds to the LDAP server to perform
user searches.
Manager Password Used only with "search" authentication method.
It is the password of the user that binds to the LDAP server to
perform the search.
Sub-tree Search Enables deep search through the sub tree of the LDAP URL +
search base. True by default.
Test Username The Username to test the LDAP connection with.
Test Password The Password to test the LDAP connection with.
Synchronizing LDAP Groups with Artifactory

Once you have configured how groups should be retrieved from your LDAP server, you can verify your set up by clicking the button on Refresh
the sub-panel. A list of available LDAP groups is displayed according to your settings. Synchronize LDAP Groups
You are now ready to synchronize/import groups into Artifactory. The groups tables allows you to select which groups to import and displays the
sync-state for each group:
A group can either be completely new or already existing in Artifactory. If a group already exists in Artifactory it can become outdated (for
example, if the group DN has changed) - this is indicated in the table so you can select to re-import it.
Once a group is imported (synced) a new external LDAP group is created in Artifactory with the name of the group.
Once you have imported LDAP groups, you can on them as with regular Artifactory groups. Users association to these Manage Permissions
groups is external and controlled strictly by LDAP.
Make sure the LDAP group settings is enabled (in the panel) in order for your settings to become effective. LDAP Groups Settings
Repository Replication
Overview
The Replication Add-on provides a method to synchronize content and properties from one repository to another in a remote Artifactory instance.
Synchronization uses a checksum-based algorithm to ensure only the required deltas are evertransferred over the wire.
Two types of replication are supported:
Push Replication
Pull Replication
Push Replication
Where a local repository can actively push content to another local repository on a remote Artifactory.
This is ideal for situations where you can only make an outgoing connection to the remote server, such as when pushing artifacts to a cloud
instance.
Pull replication runs as a scheduled task and/orcontinuously based on storage events.
Evented Push Replication
In addition to scheduled replication, push replication also supports continuous " . event-based replication"
When enabled, storage events (deploy, delete, move and copy) are almost immediately applied to the remote instance, making sure the
remotecontentis synced with the original content in near real-time.
Running regular scheduled replication on top of event-based replication, guarantees full copy consistency even in cases of server downtimes and
network partitions.
Pull Replication
Where a remote repository can activelypull content from another repository (local, remote or virtual) on a remote Artifactory
This provides a convenient way to proactively populate a remote cache and is very useful when waiting for new
artifacts to arrive on demand (when first requested) is not desirable due to network latency.
Pull replication runs as a scheduled task.
Replication Scheduling and Configuration
Replication is configured via the user interface as a scheduled task on local and remote repositories for push and pull, respectively.
To configure a replication task, enter the configuration of the local\remote repository you wish to replicate. Go to the Admin tab and then Config
and choose a repository. The Edit Local Repository window opens and select the tab and select uration -> Repositories Replication
the required repository.
The Edit Local Repository window is displayed.
Pull replication is also exposed via the Artifactory , with support for REST-enabled push replication coming soon. REST API
Pull and push replications are smart. Only diffs are synched and the replication plan is checksum aware.
All replication messages are directed to Artifactory's standard log file (artifactory.log).
It is highly recommended to perform the replication between servers with the same Artifactory versions.
Push Replication Local Repository Configuration
Enabled Mark this checkbox to enable continuous replication to the remote
instance based on storage events
URL The URL of the target local repository on a remote Artifactory server.
Cron Expression Defines the replication task schedule using the . cron syntax
Next Replication Time Relies on the information in the Cron Expression field.
Enable Event Replication Mark this checkbox to replicate additions and modifications as they
occur.
Username The HTTP authentication username.
Password The HTTP authentication password.
Proxy A proxy configuration to use when communicating with the remote
instance.
Socket Timeout The network timeout in milliseconds to use for remote operations.
Sync Deletes Checks if items that were deleted remotely should be deleted locally
too (also applies to properties metadata).
Sync Properties Checks if the task should synchronize the properties of synched
items.
Path Prefix(optional) A subpath to replicate within the repository.
Pull Replication Remote Repository Configuration

To see the Replication in action you can watch the short demo screencast below.
Properties
Introduction
Artifactory allows you to place properties on both artifacts and folders.
You can assign properties from the UI, via REST (see below), or on deployment, using Matrix Parameters. Properties
can also be used to Control Artifacts Resolution.
Properties are and can be combined with to search for items based on their properties and then manipulate all the searchable Smart Searches
items in the search result in one go.
You can define the collections of properties called 'Property Sets' in the use interface. In each property-set you can define properties and for
each property specify whether the property is open, single-value or multi-value.
This impacts the user interface you see when setting a property value and when searching for property values. Using searchable
properties in artifact management is a very powerful feature.
Regarding credentials of the remote repository configuration
The remote repository's file listing for replication is retrieved using the repository's credentials defined under the repository's Advanced
configuration section.
The remote files retrieved depend on the effective permissions of the configured user on the remote repository (on the other Artifactory
instance).
1.
2.
Watch this short screencast to learn more about the power of properties.
Attaching and Reading Properties via REST API
Properties are a special form of metadata and are stored on items just like any metadata - in XML form.
In fact, you can view properties not only from the tab, but also from the tab, in which you can Artifacts:Properties Artifacts:Metadata
examine properties as they are stored in XML form. The properties XML is using the root tag and has a very simple format. properties
You can set, retrieve and remove properties from repository items via REST API, as you would do with any other XML-based metadata.
Refer to the chapter for instructions on how this can be achieved. Attaching and Reading Metadata
Using Properties in Deployment and Resolution
Introducing Matrix Parameters
Matrix parameters key-value pairs parameters separated by a semicolon (;) that you can place anywhere on a URI.
This is a method for specifying parameters in HTTP (in addition to querying parameters and path parameters). standard
For example:
http://repo.jfrog.org/artifactory/libs-releases-local/org/libs-releases-local/org/jfrog/build-info-api/1.3
.1/build-info-api-1.3.1.jar;status=DEV;rating=5
Artifactory makes use of matrix parameters for:
Adding properties to artifacts as part of deployment
Controlling artifact resolution using matrix parameters
Dynamically Adding Properties to Artifacts on Deployment
You can add key-value matrix parameters to deploy (PUT) requests and those are automatically transformed to properties on the deployed
artifact.
Since matrix parameters can be added on any part of the URL, not just at the end, you can add them to the target deployment base URL. At the
time of deployment, the artifact path is added after the matrix parameters and the final deployed artifact will be assigned the defined properties.
You can even use dynamic properties, depending on our deployment framework.
When using Maven, for instance, you can add two parameters to the deployment URL: and , which Maven replaces at buildNumer revision
deployment time with dynamic values from the project properties (e.g. by using the Maven build-number plugin).
So, if you define the distribution URL as:
http://myserver:8081/artifactory/qa-releases;buildNumber=${buildNumber};revision=${rev
ision}
And deploy to the repository a jar with the following path: qa-releases
/org/jfrog/build-info-api/1.3.1/build-info-api-1.3.1.jar
Upon deployment the URL is transformed to:
Properties are for Guiding, not for Restricting
When you define a property-set with 'strongly-typed' property values, those values are used to provide an intuitive, guiding UI for
tagging and locating items.
The actual value does not force a strong relationship to the original property-set's predefined values. This is by design, to not
slow-down common repository operations and for keeping artifacts management simple by allowing properties to change and evolve
freely over time, without worrying about breaking older property rules.
Properties are therefore a helpful and non-restrictive feature.
http://myserver:8081/artifactory/qa-releases;buildNumber=249;revision=1052/org/jfrog/b
uild-info-api/1.3.1/build-info-api-1.3.1.jar
And the deployed has two new properties: build-info-api-1.3.1.jar
buildNumber=249
revision=1052
Controlling Artifact Resolution with Matrix Parameters Queries
Matrix parameters can also be used in artifact resolution, to control how artifacts are found and served.
There is currently support for two types of queries:
Non-conflicting values
Mandatory values.
Non-mandatory Properties
Resolved artifacts may either have no property with the key specified, or have the property with the key specified and the exact value specified
(i.e. the artifact is resolved if it has a property with a non-conflicting value).
Non-mandatory properties are identified by a simple parameter. key=value
For example:
Current Artifact Property Matrix Parameter Resolution Result
color=black color=black OK (200)
None or height=50 color=black OK (200)
color=red color=black NOT_FOUND (404)
Mandatory Properties
Resolved artifacts must have a property with the key specified and the exact value specified.
Mandatory properties are identified with a plus sign (+) after the property key: . key+=value
For example:
Current Artifact Property Matrix Parameter Resolution Result
color=black color+=black OK (200)
None or height=50 color+=black NOT_FOUND (404)
color=red color+=black NOT_FOUND (404)
Multi-valued Properties Support
All matrix parameters can support multiple values by separating values with a comma (,). For example:
Permissions to attach properties
You must have the 'Annotate' permission in order to add properties to deployed artifacts.
Multiple properties in queries
Multiple key-value matrix parameters are additive, forming an AND query between each key-value subsection.
colors=red,gold,green
User Plugins
About Plugins
Artifactory Pro allows you to easily extend Artifactory's behavior with your own plugins written in . Groovy
User plugins are used for running user's code in Artifactory.Plugins allow you to perform the following tasks:
Add scheduled tasks
Extend Artifactory with your own security realms
Change resolution rules
Manipulate downloaded content
Respond to any storage events on items and properties
Deploy and query artifacts and metadata
Perform searches
Query security information
Invoke custom commands via REST
Execute custom promotion logic
Provide information and strategies for . Artifactory's Build Servers Plugins
During the development phase, you can change plugin source files and have your plugins redeployed on-the-fly. You can even debug the plugin
code using your favorite IDE.
Deploying Plugins
Place your plugin files under . ${ARTIFACTORY_HOME}/etc/plugins
Any file name ending with is loaded on startup. You can have multiple plugin files which are loaded in alphabetical order. Callbacks .groovy
defined in plugins are called by the order they were loaded.
Auto Reload
By default, plugins are not reloaded after Artifactory has started-up. You can configure Artifactory to automatically detect plugin changes on disk
or new plugin files and automatically reload them in runtime (plugin removals are not detected).
To do this, set the number of seconds to check for plugin updates to a number greater than 0, by changing the following property in${ARTIFACT
, or by specifying the property with -D to the JVM running Artifactory: ORY_HOME}/etc/artifactory.system.properties
artifactory.plugin.scripts.refreshIntervalSecs=0
NOTE!that deleting or renaming plugin while auto-reloading is active is not fullysupportedand requires an Artifactory restart. files
Writing Plugins
Artifactory plugins are written as Groovy scripts in regular files and have a simple DSL to wrap users code in closures inside well-known
extension points.
Scripts have a couple of helper objects that are globally bound (see the plugin script template).
The Artifactory Public API (PAPI)
Scripts have access to the full classpath of Artifactory. However, the only API supported for plugins is the , defined in Artifactory Public API
the . artifactory-papi.jar
The can be found under folder inside the . artifactory-papi.jar WEB-INF/lib artifactory.war
Disabling Plugin Reloading for Production
Ensure plugin auto-reloading is disabled in a production environment.
Please see the and below for more details. Plugin Code Template Sample Plugin
Globally Bound Variables
Variable Name Variable Type Comments
log org.slf4j.Logger Writes to Artifactory log
logger name is the name of the script file
repositories org.artifactory.repo.Repositories Allows queries and operations on
repositories
and artifacts
security org.artifactory.security.Security Provides information about current security
context,
(e.g. current user and her permissions)
searches org.artifactory.search.Searches API for searching for artifacts and builds
Since 2.3.4
builds org.artifactory.build.Builds Allows CRUD operations on builds
Since 2.6
Plugin Execution Points
The following tablesummarizestheavailableexecution points. For more details about specific plugin look follow the section links.
Plugin Type Code block name When executed Description
Download
Event Callback (with return
values)
altResponse On any download Provide an alternative response,

by setting a success/error status
code value and an optional error
message or by setting new
values for the inputStream and
size context variables (For
succeeded resolutions).
altRemotePath When reaching out to remote
repositories
Provides an alternative
download path under the same
remote repository, by setting a
new value to the path variable.
altRemoteContent After fetching content from
remote repositories
Provide an alternative download
content, by setting new values
for the inputStream and size
context variables.
afterDownloadError After failing during content
fetching from remote repositories
Provide an alternative response,
by setting a success/error status
code value and an optional error
message or by setting new
values for the inputStream and
size context variables (For failed
resolutions).
IDE code completion
All major IDEs have good Groovy editing and debugging capabilities.
In order to make your developing experiencecomplete, we provide support for our own DSL for IntelliJ IDEA. IntelliJ IDEA's Groovy
for Artifactory User Plugins can be found in our . DSL script GitHub repo
Plugins Repository
Enhancing Artifactory with user plugins is community-driven effort.
If you are looking to go beyond Artifactory's out-of-the-box functionality take a look at , you might already contributed plugins on GitHub
find what you are thinking about. If not, your contribution is very welcome!
Event Callback (without return
value)
beforeRemoteDownload Before fetching content from

remote repositories
Handle before remote download
events.
afterRemoteDownload After fetching content from
remote repositories
Handle after remote download
events.
beforeDownload On any download Handle before download events.
Storage
value)
before/after
Create, Delete, Move,
Copy,
PropertyCreate,
PropertyDelete
Before / After selected storage
operation
Handle events before and after
Create, Delete, Move and Copy
operations
Jobs
Scheduled execution any valid Groovy (Java) literal as
execution name
According to provided
interval/delay or CRON
expression
Job runs are controlled by the
provided interval or cron
expression, which are mutually
exclusive. The actual code to run
as part of the job should be part
of the job's closure.
Executions
User-driven execution any valid Groovy (Java) literal as
execution name
By REST call External executions are invoked
via REST POST requests.
Realms
value)
any valid Groovy (Java) literal as
realm name with nested blocks:
authenticate
userExists
During user authentication Newly added realms are added
before any built-in realms
(Artifactory internal realm, LDAP,
Crowd etc.). User authentication
will be attempted against these
realms first, by the order they
are defined.
Build
value)
beforeSave Before the build info is saved in
Artifactory
Handle before build info save
events
afterSave After the build info is saved in
Artifactory
Handle after build info save
events
Promotions
User or build server exec driven
ution
any valid Groovy (Java) literal as
promotion name
By REST call Promotes integration (a.k.a.
snapshot) build to be a release
invoking any code associated
with it.
Staging Strategy
build server driven execution any valid Groovy (Java) literal as
staging strategy name
During build server driven
staging build configuration
The strategy provides the build
server with the following
information:
How the artifacts in the
staged build should be
versioned;
How the artifacts in the next
integration build should be
versioned;
Should the build server
create a release
branch/tag/stream in VCS
and how it should be called;
To which repository in
Artifactory the built artifacts
should be submitted.
Execution Context
The , , and plugin types are executed under the identity of the user request that triggered them. Download Storage Execution Build
It is possible to force a block of plugin code to execute under the "system" role, which is not bound to any
authorization rules and canthereforeperform actions that are otherwise forbidden for the original user.
To run under the "system" role wrap your code with the closure: asSystem
... someCode ...
asSystem {
//This code runs as the system role
}
... someOtherCode ...

The and plugin types already execute under the "system" role. This cannot be changed. Realm Job
Plugin Template Source
General Info
/*
* Artifactory is a binaries repository manager.
* Copyright (C) 2011 JFrog Ltd.
*
* Artifactory is free software: you can redistribute it and/or modify
* it under the terms of the GNU Lesser General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
*
* Artifactory is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public License
* along with Artifactory. If not, see http://www.gnu.org/licenses/.
*/
/**
*
* Globally bound variables:
*
* log (org.slf4j.Logger)
* repositories (org.artifactory.repo.Repositories)
* security (org.artifactory.security.Security)
* searches (org.artifactory.search.Searches) [since: 2.3.4]
* builds (org.artifactory.build.Builds) [since 2.5.2]
*
* ctx (org.artifactory.spring.InternalArtifactoryContext) - NOT A PUBLIC API - FOR
INTERNAL USE ONLY!
*/
Download
Handling and Manipulating Download Events
download {
/**
* Provide an alternative response, by one of the following methods:
* (1) Setting a success/error status code value and an optional error message.
* (2) Provide an alternative download content, by setting new values for the
inputStream and size context variables.
*
* Note that, unless specifically handled, checksum requests for altered responses
will return the checksum of the
* original resource, which may not match the checksum of the alternate response.
*
* Will not be called if the response is already committed (e.g. a previous error
occurred).
* Currently called only for GET requests where the resource was found.
*
* Context variables:
* status (int) - a response status code. Defaults to -1 (unset).
* message (java.lang.String) - a text message to return in the response body,
replacing the response content.
* Defaults to null.
* inputStream (java.io.InputStream) - a new stream that provides the response
content. Defaults to null.
* size (long) - the size of the new content (helpful for clients processing the
response). Defaults to -1.
*
*
* Closure parameters:
* request (org.artifactory.request.Request) - a read-only parameter of the request.
* responseRepoPath (org.artifactory.repo.RepoPath) - a read-only parameter of the
response RepoPath (containing the
* physical repository the
resource was found in).
*/
altResponse { request, responseRepoPath ->
}
/**
* Provides an alternative download path under the same remote repository, by
setting a new value to the path
* variable.
*
* path (java.lang.String) - the new path value. Defaults to the originalRepoPath's
path.
*
* repoPath (org.artifactory.repo.RepoPath) - a read-only parameter of the original
request RepoPath.
*/
altRemotePath { repoPath ->
}
/**
* Provide an alternative download content, by setting new values for the
inputStream and size context variables.
*
*
request RepoPath.
*/
altRemoteContent { repoPath ->
}
/**
* In case of resolution error provide an alternative response, by setting a
success/error status code value and an optional error message.
* Will not be called if the response is already committed (e.g. a previous error
occurred).
* As opposite to altResponse, called only for GET requests during which error
occurred (e.g. 404 - not found, or 409 - conflict).
*
* status (int) - a response error status code (may be overridden in the plugin).
* message (java.lang.String) - a response error message (may be overridden in the
plugin).
*
* request (org.artifactory.request.Request) - a read-only parameter of the
request.
*/
afterDownloadError { Request request ->
}
/**
* Handle before remote download events.
*
[since: 2.3.4]
request RepoPath.
*/
beforeRemoteDownload { request, repoPath ->
}
/**
* Handle after remote download events.
*
[since: 2.3.4]
request RepoPath.
*/
afterRemoteDownload { request, repoPath ->
}
/**
* Handle before local download events.
*
* responseRepoPath (org.artifactory.repo.RepoPath) - a read-only parameter of the
response RepoPath (containing the
* physical repository the
resource was found in).
*/
beforeDownload { request, responseRepoPath ->
}
}
Storage
Handling and Manipulating Storage Events
If you want to abort an action, you can do that in 'before' methods by throwing a runtime org.artifactory.exception.CancelException with an error
message and a proper http error code.
storage {

/**
* Handle before create events.
*
* item (org.artifactory.fs.ItemInfo) - the original item being created.
*/
beforeCreate { item ->
}

/**
* Handle after create events.
*
* item (org.artifactory.fs.ItemInfo) - the original item being created.
*/
afterCreate { item ->
}

/**
* Handle before delete events.
*
* item (org.artifactory.fs.ItemInfo) - the original item being being deleted.
*/
beforeDelete { item ->
}

/**
* Handle after delete events.
*
* item (org.artifactory.fs.ItemInfo) - the original item deleted.
*/
afterDelete { item ->
}

/**
* Handle before move events.
*

* item (org.artifactory.fs.ItemInfo) - the source item being moved.
* targetRepoPath (org.artifactory.repo.RepoPath) - the target repoPath for the move.
* properties (org.artifactory.md.Properties) - user specified properties to add to
the item being moved.
*/
beforeMove { item, targetRepoPath, properties ->
}

/**
* Handle after move events.
*
* item (org.artifactory.fs.ItemInfo) - the source item moved.
* targetRepoPath (org.artifactory.repo.RepoPath) - the target repoPath for the move.
*/
afterMove { item, targetRepoPath, properties ->
}

/**
* Handle before copy events.
*
* item (org.artifactory.fs.ItemInfo) - the source item being copied.
* targetRepoPath (org.artifactory.repo.RepoPath) - the target repoPath for the copy.
*/
beforeCopy { item, targetRepoPath, properties ->
}

/**
* Handle after copy events.
*
* item (org.artifactory.fs.ItemInfo) - the source item copied.
* targetRepoPath (org.artifactory.repo.RepoPath) - the target repoPath for the copy.
*/
afterCopy { item, targetRepoPath, properties ->
}

/**
* Handle before property create events.
*
* item (org.artifactory.fs.ItemInfo) - the item on which the property is being set.
* name (java.lang.String) - the name of the property being set.
* values (java.lang.String[]) - A string array of values being assigned to the
property.
*/
beforePropertyCreate { item, name, values ->
}
/**
* Handle after property create events.
*
* item (org.artifactory.fs.ItemInfo) - the item on which the property has been set.
* name (java.lang.String) - the name of the property that has been set.
* values (java.lang.String[]) - A string array of values assigned to the property.
*/
afterPropertyCreate { item, name, values ->
}
/**
* Handle before property delete events.
*
* item (org.artifactory.fs.ItemInfo) - the item from which the property is being
deleted.
* name (java.lang.String) - the name of the property being deleted.
*/
beforePropertyDelete { item, name ->
}
/**
* Handle after property delete events.
*
* item (org.artifactory.fs.ItemInfo) - the item from which the property has been
deleted.
* name (java.lang.String) - the name of the property that has been deleted.
*/
afterPropertyDelete { item, name ->
}
}
Jobs
Defining Scheduled Jobs
jobs {
/**
* A job definition.
* The first value is a unique name for the job.
* Job runs are controlled by the provided interval or cron expression, which are
mutually exclusive.
* The actual code to run as part of the job should be part of the job's closure.
*
* Parameters:
* delay (long) - An initial delay in milliseconds before the job starts running
(not applicable for a cron job).
* interval (long) - An interval in milliseconds between job runs.
* cron (java.lang.String) - A valid cron expression used to schedule job runs (see:
http://www.quartz-scheduler.org/docs/tutorial/TutorialLesson06.html)
*/
myJob(interval: 1000, delay: 100) {
}
mySecondJob(cron: "0/1 * * * * ?") {
}
}
Executions
Defining External Executions
Since: 2.3.1 - External executions are invoked via REST POST requests. For example:
curl -X POST -v -u admin:password
"http://localhost:8080/artifactory/api/plugins/execute/myExecution?params=msg=And+the+
result+is:|no1=10|no2=15&async=0"
executions {
/**
* An execution definition.
* The first value is a unique name for the execution.
*
* status (int) - a response status code. Defaults to -1 (unset). Not applicable for
an async execution.
replacing the response content.
* Defaults to null. Not applicable for an async
execution.
*
* Plugin info annotation parameters:
* version (java.lang.String) - Closure version. Optional.
* description (java.lang.String - Closure description. Optional.
* params (java.util.Map<java.lang.String, java.lang.String>) - Closure default
parameters. Optional.
* users (java.util.Set<java.lang.String>) - Users permitted to query this plugin
for information or invoke it.
* groups (java.util.Set<java.lang.String>) - Groups permitted to query this plugin
*
* params (java.util.Map) - An execution takes a read-only key-value map that
corresponds to the REST request
* parameter 'params'. Each entry in the map conatains an array of values.
*/
myExecution(version:version, description:description, users:[], groups:[],
params:[]) { params ->
}
}
Realms
Management of Security Realms
Realms defined here are added before any built-in realms (Artifactory internal realm, LDAP, Crowd etc.). User authentication will be attempted
against these realms first, by the order they are defined.
realms {
/**
* An security realm definition.
* The first value is a unique name for the realm.
*
* autoCreateUsers (boolean) - Whether to automatically create users in Artifactory
upon successul login. Defaults to
* true. When false, the user will be transient and his privileges will be managed
according to permissions defined
* for auto-join groups.
*/
myRealm(autoCreateUsers: true) {
/**
* Implementation should return true/false as the result of the authentication.
*
* groups (java.lang.String[]) - An array of groups that the authenticated user
should be associated with (since 3.0.2).
*
* username (java.lang.String) - The username
* credentials (java.lang.String) - The password
*/
authenticate { username, credentials ->
}
/**
* Implementation should return true if the user is found in the realm.
* username (java.lang.String) - The username
*/
userExists { username ->
}
}
}
Build
uild Info Events Handling B
Since 2.6
build {

/**
* Handle before build info save events
*
* buildRun (org.artifactory.build.DetailedBuildRun) - Build Info model to be saved.
Partially mutable.
*/
beforeSave { buildRun ->
}
/**
* Handle after build info save events
*
* buildRun (org.artifactory.build.DetailedBuildRun) - Build Info that was saved.
Partially mutable.
*/
afterSave { buildRun ->
}
}
Promotions
Defining Operations REST ExecutableBuild Promotion
Since 2.6
promotions {
/**
* A REST executable build promotion definition.
*
* status (int) - a response status code. Defaults to -1 (unset).
replacing the response content. Defaults to null.
*
* params (java.util.Map<java.lang.String, java.lang.String>) - Closure parameters.
Optional.
* users (java.util.Set<java.lang.String>) - Users permitted to query this plugin
*
* buildName (java.lang.String) - The build name specified in the REST request.
* buildNumber (java.lang.String) - The build number specified in the REST request.
* params (java.util.Map<java.lang.String, java.util.List<java.lang.String>>) - The
parameters specified in the REST request.
*/
promotionName(version, description, users, groups, params) { buildName, buildNumber,
params ->
}
}
Staging
Defining Build Staging Strategy Construction REST retrievable
Since 2.6.1
1.
2.
3.
/**
* Set of staging strategy definitions to be used by the build server during staging
process.
* The strategy provides the build server with the following information:
* 1. How the artifacts in the staged build should be versioned;
* 2. How the artifacts in the next integration build should be versioned;
* 3. Should the build server create a release branch/tag/stream in VCS and how it
should be called;
* 4. To which repository in Artifactory the built artifacts should be submitted.
*
* This user plugin is called by the build server using REST call.
*/
staging {

/**
* A build staging strategy definition.
*
* Closure delegate:
* org.artifactory.build.staging.BuildStagingStrategy - The strategy that's to be
returned.
*
* params (java.util.Map<java.lang.String, java.lang.String>) - Closure parameters.
Optional.
* users (java.util.Set<java.lang.String>) - Users permitted to query this plugin for
information or invoke it.
*
* buildName (java.lang.String) - The build name specified in the REST request.
* params (java.util.Map<java.lang.String, java.util.List<java.lang.String>>) - The
parameters specified in the REST request.
*/
strategyName(version, description, users, groups, params) { buildName, params ->
}
}
Sample Plugin
Sample plugin is . available to download
YUM Repositories
Overview
Artifactory can act as a full-fledged YUM repository (since Artifactory 2.4.0). As such, it provides:
RPM metadata calculation for RPMs hosted in Artifactory local repositories.
Provisioning RPMs directly from Artifactory to YUM clients.
Detailed RPM metadata views from Artifactory's web UI.
Watch this short screencast to learn how easy it is to host RPMs in Artifactory.
1.
2.
3.
4.
RPM Metadata for Hosted RPMs
The RPM metadata generated by Artifactory is identical to the basic-mode output of the Red Hat-based Linux command . createrepo
A folder named is created in the configured location within a local repository with the following files in it: repodata
primary.xml.gz - Contains an XML file describing the primary metadata of each RPM archive.
filelists.xml.gz - Contains an XML file describing all the files contained within each RPM archive.
other.xml.gz - Contains an XML file describing miscellaneous information regarding each RPM archive.
repomd.xml - Contains information regarding all the other metadata files.
Triggering RPM Metadata Updates
When enabled, the calculation is run in a number of ways:
Automatically when deploying/removing/copying/moving an RPM file.
Automatically when performing content import (both system and repository imports).
Manually via "Calculate Now" in the local repository YUM configuration tab.
Manually via Artifactory's . REST-API
The produced metadata is served to YUM clients.
Configuration
To enable RPM metadata calculation on a local repository click on the Admin tab and then Select the repository Configuration -> Repositories.
as described in and select the Packages tab. local repository configuration
YUM Support is Platform Independent!
Artifactory employes a RPM metadata calculation. pure Java-based
It does not rely on the existence of the createrepo binary or on running external processes on the host
upon which Artifactory is running.
Metadata calculation cleans up pre-existing YUM metadata (existing as a result of manual deployment or import), including RPM
metdata stored as SQLite database files.
1.
2.
The field tells Artifactory under which level of directory to search for RPMs and save the directory. Depth repodata
0 is the default and refers to the repository's root folder; the calculator searches the entire repository for RPMs and
save the repodata directory at $REPO-KEY/repodata.
Using a different depth is useful in cases where generating metadata for a repository separates its artifacts by name, version and architecture.
For example:
If the repository layout is similar to that shown below and you want to generateRPM metadata for every artifact divided by name, set the t Depth
o and the directory is saved at : 1 repodata REPO_ROOT/ARTIFACT_NAME/repodata
REPO_ROOT/$ARTIFACT_NAME/$ARTIFACT_VERSION/$ARCHITECTURE/FILE_NAME
- or -
libs-release-local/foo/1.0/x64/foo-1.0-x64.rpm
YUM Groups
Artifactory supports attaching a upon YUM calculation, essentially mimic the command. YUM Group file createrepo -g
The process of attaching YUM group metadata to a local repository is simple:
Create an xml file in the groups format used by YUM, you can either open a text editor and create the groups xml file manually or you
can run the yum-groups-manager command from yum-utils
Deploy the created group file to the 'repodata' folder, Artifactory will automatically perform the following steps:
Create the corresponding gz file and deploy it next to the deployed xml group fie.
Invoke YUM calculation on the local repository.
Metadata calculation is throttled per metadata base-folder and is asynchronous; Artifactory invokes the actual calculation only after a
certain "quiet period" following an action involving update or removal of an RPM file.
For this reason, the creation of the metadata normally occurs 1-2 minutes after an RPM-related action has been completed.
2.
3.
Attach the group information (both the xml and the gz file) to the repomd.xml file.
Make sure the group file names are listed under the Packages tab, this tells Artifactory the files to be attached as a repository group
information.
This is how the local repository appears after deploying a 'groups.xml' group metadata file to it ('repodata' is calculated on depth 0):
Viewing Individual RPM Information

It is also possible to view all the metadata that annotates an RPM by choosing the RPM file in Artifactory's tree browser and selecting the RPM
tab: Info
P2 Repositories
Overview of P2 Repositories Support in Artifactory
Artifactory supports advanced proxying and caching of P2 repositories and P2 metadata aggregation (since Artifactory 2.4).
An Artifactory virtual repository can serve as a single point of distribution (single URL) for Eclipse, and any other P2 clients. Tycho
This virtual repository aggregates P2 metadata and P2 artifacts from underlying standard local and remote repositories in Artifactory. This
provides you with full visibility of the P2 artifact sources and allows powerful management of caching and security aspects for P2 content.
The YUM Group File Names is a comma-separated list of xml group file names, each depth of 'repodata' in your repository may
contain different group file name but each 'repodata' may contain only 1 group file metadata (multiple groups should be listed as
different tags inside the xml file as stated in the ). YUM Docs
For P2 support it is recommended to use Eclipse Helios (3.6) and above.
Older Eclipse versions may not work correctly against Artifactory P2 repositories.
1.
2.
Configuring Artifactory
Virtual Repository Configuration
To enable P2 metadata aggregation on a virtual repository, create a from Artifactory's user interface and select the 'P2' tab. Virtual Repository
On this tab, you must enable P2 support and then add either a local repository that hosts your P2 metadata and content or remote P2 repository
URLs you want to aggregate.
P2 Local Repository
Local repositories do not have any P2 dedicated configuration, choose the desired local repository from the repositories combo box and add a
sub path pointing to the P2 metadata files( , etc.). When the sub path field is left content.jar, artifacts.jar, compositeContent.xml
empty, P2 metadata files are assumed to reside directlyunder the repository's root.
If you have a Tycho repository deployed to a local repository as a single archive, specify the archive's root path. For
example:'eclipse-repository.zip!/'.
For each local repository added, you can (and should) include the repository in the listof (local and remote) repositories aggregated by this
virtual repository.
The following options are proposed for a remote repository in the repositories list table:
Include: Adds the local repository to the list of repositoriesaggregatedby this virtual repository.
Included: Shows the repository is already included in the virtual repository.
P2 Remote Repository
1.
2.
1.
2.
3.
4.
Select a P2 repository URL to add to Artifactory.The URL entered here should point at the path where P2 metadata files are found (content.j
ar, artifacts.jar, compositeContent.xml, etc.).
For example:
The main Juno repository:http://download.eclipse.org/releases/juno
The Google plugins repository for Indigo (GWT, GAE, etc.):http://dl.google.com/eclipse/plugin/3.7
Artifactory analyzes the added URL and based on the remote P2 metadata, identifies which remote repositories are required to be created in
Artifactory (remote P2 repositories mayaggregateinformation from different hosts).
For each identified remote repository you can (and should) create andinclude the repository in the listof (local and remote) repositories
aggregated by this virtual repository.
The following options are proposed for a remote repository in the repositories list table:
Create: Create a new, P2 enabled, remote repository with the given key (the remote repo key is editable).
Modify: Enable P2 support in an existing remote repository.
Include: Add the remote repository to the list of repositoriesaggregatedby this virtual repository.
Included: Shows the repository is already included in the virtual repository.
Integration with Tycho Plugins

Artifactory fully supports hosting of Tycho plugins as well as resolving Tycho build dependencies.
In order to resolve all build dependencies through Artifactory, simply change the repository URL tag of your build
POM.xml file and point it to a dedicated virtual repository inside Artifactory
For example:
<repository>
<id>eclipse-indigo</id>
<layout>p2</layout>
<url>http://localhost/artifactory/p2</url>
</repository>
The P2 virtual repository should contain URLs to all local repositories with an optional sub path in them where Tycho build artifacts reside.
P2 Client Configuration
Using Artifactory P2 Virtual Repository in Eclipse
Once the virtual repository is correctly configured, you must modify your Eclipse configuration to point at the new P2 Artifactory URL.
For example, if the new virtual repository key is 'p2', you can add the following URL to the list of http://yourserver/artifactory/p2
'Available Software Sites':
When P2 metadata files reside inside an archived file, simply add '!' to the end of the URL, for example: http://eclipse.org/equ
!/ inox-sdk.zip
When created from the virtual repository, remote repositories have P2 support enabled automatically.
This flag is required so that the remote repository can manage the proxy-cache of an external P2 repository, including the expiration of
cached P2 resources (content.jar, artifacts.jar, compositeContent.xml, etc.).
This flag can also be manuallycontrolled by browsing to a 'sconfiguration panel and selecting the 'Packages' tab. remote repository
1.
2.
3.
4.
5.
NuGet Repositories
NuGet Repositories Support in Artifactory - Overview
Since version 2.5, Artifactory provides complete support for repositories enhanced by Artifactory's for advanced artifact NuGet existing support
management.
The NuGet support in Artifactory provides:
Provisioning NuGet packages from Artifactory to NuGet clients from all repository types
Metadata calculation for NuGet packages hosted in Artifactory's local repositories
Remote NuGet repository proxying and caching
Multiple NuGet repository aggregation through virtual repositories
NuGet tool (Visual Studio extension, CLI) compatible APIs for package deployment and removal
Configuration
To enable NuGet package metadata calculation on repositories, browse the Artifactory user interface to the desired repository configuration.
When configuring local and remote repositories select the tab: Packages
Metadata updates
NuGet metadata is calculated automatically when adding and removing NuGet packages (including package moving and copying).
Local Repository Layout
It is possible to store NuGet packages inside folders, Artifactory performs a property search in order to find them; Hence, the folders layout will
not impact searches.
You will need to configure a proper for the repository. This way, features like will work perfectly with NuGet custom layout versions cleanup
packages.
Below is an example of a custom layout named which stores NuGet packages in 2 level folders (this is mandatory since you nuget-default
must provide the layout with orgPath, module and baseRev).

Remote Paths Configuration
Since different implementations of NuGet servers may provide package resources on different paths, feed and download resource locations are
customizable when proxying a remote NuGet repository.
For example:
NuGet gallery exposes its feed resource at and its download resource at https://nuget.org/api/v2/Packages https://nuget.org/api/v2/pack
age
gallery's repository URL points to , and its feed context path to and its download context path to The https://nuget.org api/v2 api/v2/p
. ackage
The module exposes its feed resource at and its download resource at NuGet.Server http://host:port/nuget/Packages http://host:port/a
. pi/v2/package
The server's repository URL points to , its feed context path to and its download context path to http://myhost:myport nuget api/v2/pa
. ckage
Another Artifactory repository exposes its feed resource at and its download http://host:port/artifactory/api/nuget/repoKey/Packages
resource at . http://host:port/artifactory/api/nuget/repoKey/Download
The server's repository URL points to , its feed context path should be leftempty and its http://host:port/artifactory/api/nuget/repoKey
download context path to . Download
Virtual Repositories aggregates NuGet packages from local and remote repositories under the virtual repository that has NuGet support enabled.
This allows one to resolve NuGet packages from a single URL (the one of the virtual repository) containing both hosted and proxied libraries.
When configuring virtual repositories select the Packagestab:
NuGet metadata calculation is asynchronous and is throttled per repository and package ID; Artifactory invokes the actual calculation
only after an action involving update or removal of a NuGet package.
For this reason, the creation of the metadata normally occurs 30-60 seconds after a package-related action has completed and
depends on the system overall load.
You can invoke re-metadata indexing on the entire repository by clicking on the "Reindex Packages" which will also be asynchronous.
Usage
Artifactory exposes its NuGet resources via the REST API at the following URL: . http://myhost/artifactory/api/nuget/repoKey
This location handles all NuGet related requests (search, download, upload, delete) and supports both V1 and V2 requests.
Using the NuGet Visual Studio Extension:
Using the NuGet command line bootstrapper:
NuGet API Key Authentication
NuGet tools require that sensitive operations such as push and delete authenticate with the server using an . The API key you should API key
use is in the form of , where the password can be either clear-text or . username:password encrypted
Viewing Individual NuGet Package Information
It is also possible to view all the metadata annotating a NuGet package by choosing the NuPkg file in Artifactory's tree browser and selecting the
tab: NuPkg Info
RubyGems Repository
Introduction
Artifactory 3.0.3 and above comes with a complete support for RubyGems enabled repositories.
With just a simple configuration the Ruby Addon provides: Gems
Remote repositories proxying and caching
Local repositories support, including RubyGems API support
Virtual repositories support, aggregating multiple local and remote repositories including
gems and specs indices.
Support for common Ruby tools such as gem, bundler
1.
2.
Proxying remote RubyGems repository
In order to proxy a remote RubyGems repository, such ashttp://rubygems.org,
do the following:
Browse the Artifactory user interface to Admin -> Configuration -> Repositories, and click on New under Remote Repositories
Set the Repository Key, and set the URL value to the remote repository URL
3. Under the tab, selectEnable RubyGems Support Packages

4. Click Create
Using a remote RubyGems repository
Now, in order to allow the integration with gemcommand line tool, you have to
add the relevant source URL.
From the Tree Browser, click on the newly created repository, and copy the
source URL from the bottom of the General panel.
1.
2.
3.
4.
Then add this source to the ~/.gemrc file or using the gem source command:
Setting up local RubyGems repository

In order to setup a local RubyGems repository, do the following:
Browse the Artifactory user interface to Admin -> Configuration -> Repositories, and click on New under Local Repositories
Set the Repository Key to your desired name
Under the tab, selectEnable RubyGems Support Packages
Click Create
The source URL can be found under the General Tab as described on the previous section.
Again, you need to add this repository source URL:
You might consider removing previous source entries using 'gem sources -r'
Use 'gem sources --list' to know what are your effective sources and their order.
Anonymous access
If your Artifactory server does allow anonymous access, and gem commands (such as gem source) fails with unauthorized status, not
you can use url with embedded credentials, such as:
gem sources -a http://user:password@localhost:8081/...
Notice that there are two sources, first the remote proxy, than the local. This
will effectively allow you to retrieve gems from both of them, in the specified
order.
Using a local RubyGems repository
First, setup the appropriate for the tool, have ~/.gem/credentials file contain the API key, or issue this command: credentials gem
curl $ART_GEMS/REPO_KEY/api/v1/api_key.yaml > ~/.gem/credentials -uUSER:PASS
Where $ART_GEMS is the Artifactory gems url prefixhttp://ARTIFACTORY_HOST/artifactory/api/gems
REPO_KEY is the local repository name and
SER and PASSdenotes Artifactory user and password U
In order to gems to the local repository, you have to set the global variable to point to the local repository. push $RUBYGEMS_HOST
exportRUBYGEMS_HOST= REPO_KEY http://ARTIFACTORY_HOST/artifactory/api/gems/
You can copy this value from General Tab as described earlier, under the Target section, for example:
Another possibility is to use the with --host, and optionally, the --key to specify the relevant API key. gem push
Setting up a virtual RubyGems repository

Virtual repository can aggregate multiple local and remote repositories,
exposing them under a single url seamlessly.
Depending on your development environment, this might be the best option for
separating artifacts from different groups and environments.
On Unix system, you might need to change the permissions of the credentials to 600(chmod 600)
On Windows system, the credentials file is located at%HOME%/.gem/credentials
Note that you can modify the credentials file manually, adding different api keys for your convenience. You can later use 'gem push -k
key' to choose the relevant api key
Be sure you know what are your effective sources and their order (as in the ~/.gemrc file)
Be sure you know what is your global $RUBYGEMS_HOST before you issue a 'gem push', or use the push --host option
Setting up a virtual repository is similar procedure as setting local and remote.
In addition you will need to choosethe repositories you want to be part of the virtual
repository. You can read more about it here: . Virtual Repositories
Using a virtual repository is also a similar procedure as using local and remote
RubyGems supported repositories - add the source url as described above
REST API
The Gems Add-on is exposed per repository key via REST API at the following
URL:
http://ARTIFACTORY_HOST/artifactory/api/gems/repoKey/
The REST API supports the basic binary repository operations, such as download, deploy, delete etc.
In addition, some of the RubyGems.org API gem commands are supported:
Gem command Curl syntax example Remarks
Info curl /api/v1/gems/ $ART_GEMS/REPO_KEY
my_gem.(json|xml|yaml)
Optionally indicate JSON / XML / YAML
(default: JSON)
Search curl /api/v1/search $ART_GEMS/REPO_KEY
?query=[query] .(json|xml|yaml)
Will search for gems with name containing q
uery
Dependencies curl /api/v1/depen $ART_GEMS/REPO_KEY
dencies?gems=[gem1,...]
Use a csv of gem names for the value of ge
ms
Yank curl -X DELETE /a $ART_GEMS/REPO_KEY
pi/v1/yank
-d 'gem_name=gem_name' -d 'version=0.0.1
' -d 'platform=ruby'
Deletes the specific gem file from the
repository
Moreover, the following REST API are also available:

REST command Curl syntax example Remarks
ReIndex curl /reind $ART_GEMS_HOST/REPO_KEY
ex
Will re-create all specs index files. Shouldn't
be use directly on common usages.
Update index curl $ART_GEMS_HOST/REPO_KEY/updat
eIndex
Will update all specs index files if needed. S
houldn't be use directly on common usages.
See more at theArtifactory REST API wiki page.
Tree Browser
Through the Tree Browser, when choosing a specific gem artifact, a 'Gem' tab is shown,
providing you with some extra information on the gem including dependencies:
Repository Layouts
Background
Together 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 Layouts
With 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:
Automatic snapshot/integration versions cleanup
Group-Artifact-Version-Classifier/Organization-Module-Revision-Classifier searches
Deleting old versions
Conversions between remote and local layouts
Conversions between 2 local layouts when moving or copying
Resolution conversions from a virtual repository to its underlying repositories (where the virtual repository has its own layout defined)
Bundled Layouts
Out-of-the-box Artifactory comes with a number of default predefined layouts requiring no additional configuration:
Maven 2/3
Ivy (default layout)
Gradle (Wharf cache default layout)
Maven 1
Support for repository layouts in Artifactory OSS
Layout configuration for conversion and resolution is available only to Artifactory Power Pack users. Users of the OSS version can only
to use the default repository layouts bundled with Artifactory. Configure their Repositories
Modules and Path Pattens used by Repository Layouts
Module Fields
To 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:
Organization
Module
Base Revision.
Field Description Example Mandatory

Organization A sequence of literals that
identifies the artifact's
organization
" " org.slf4j
Module A sequence of literals that
identifies the artifact's module
" " slf4j-api
Base Revision A sequence of literals that
identifies the base revision part
of the artifact version, excluding
any integration information
" ", or in case of an 1.5.10
integration revision "1.2-SNAPS
" the base revision is " " HOT 1.2
Folder Integration Revision A sequence of literals that
identifies the integration revision
part used in folder names in the
artifact's path, excluding the
base revision
in case of an integration revision
" " the folder 1.2-SNAPSHOT
integration revision is "SNAPSHO
" T
File Integration Revision A sequence of literals that
identifies the integration revision
part in the artifact's file name,
excluding the base revision
in case of an integration revision
" " 1.2-20110202.144533-3
the file integration revision is "20
" 110202.144533-3
Classifier A sequence of literals that
identifies the artifact's classifier
" " sources
Extension A sequence of literals that
identifies the artifact's extension
" " zip
Type A sequence of literals that
identifies the artifact's type.
Typically used when the
artifact's extension cannot be
reused as the artifact's type
" " java-source
Using Module Fields to Define Path Patterns
A 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 Tokens
A path pattern is constructed of tokens (explained below), path separators (' '), optional parentheses (' ' and ' ') and literals (' ', ' ', etc.). Tokens / ( ) . -
are modeled after module fields, as presented above.
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 OSS version only supports the automaticsnapshot/integration version cleanup and deleting old version features.
or an file). .pom ivy.xml
The following tokens are available:
Token Description
[org] Represents the field where the levels are separated by Organization
dots (' '), a-la Ivy. For example:" " . org.slf4j
[orgPath] Represents the field where the levels are separated by Organization
path separators (' '), a la Maven.For example:" " / org/slf4j
[baseRev] Represents the field Base Revision
[module] Represents the field Module
[folderItegRev] Represents the field Folder Integration Revision
[fileItegRev] Represents the field File Integration Revision
[classifier] Represents the field Classifier
[ext] Represents the field Extension
[type] Represents the field Type
[customTokenName<customTokenRegex>] A custom token. Can be used to create a new type of token when the
provided defaults are insufficient.
For example, creates a new [myIntegRev<ITEG-(?:[0-9]+)>]
custom token named that matches the word follo myIntegRev ITEG
wed by a dash and a minimum of one digit.
Artifact Path Patterns
An artifact path pattern represents the typical structure that all module artifacts are expected to be stored in.
For example -
To represent a normal Maven artifact path: "org/eclipse/jetty/jetty-ajp/7.0.2.v20100331/jetty-ajp-7.0.2.v2010033
" 1.jar
Use the artifact path pattern:
Multiple Custom Tokens
Artifactory supports any number of custom tokens, but when provided with multiple custom tokens of the same key, Artifactory only
takes into account the regular expression of the first occurrence while substituting the rest with a repetition expression (even if each
occurrence has a different regular expression value.
For example:
[custom1<.+>]/[custom1<.*>]/[custom1<[0-9]+>]
Translates to:
<custom1>.+/\1/\1
Optional parts
To specify tokens or a sequence of tokens and literals as optional in the path pattern, surround the sequence with the optional
parentheses ' ' and ' ' lterals. ( )
For example, the pattern " " matches both " " and " ", and the [module](-[classifier]) bobs-tools-sources bobs-tools
pattern " " matches both " " and " ". [baseRev](-[fileItegRev]) 1.2-SNAPSHOT 1.2
[orgPath]/[module]/[baseRev](-[folderItegRev])/[module]-[baseRev](-[fileItegRev]
)(-[classifier]).[ext]
To represent a default Ivy artifact path: "org.eclipse.jetty/jetty-ajp/7.0.2.v20100331/jars/jetty-ajp-7.0.2.v20100
" 331.jar
Use the artifact path pattern:
[org]/[module]/[baseRev](-[folderItegRev])/[type]s/[module]-[baseRev](-[fileIteg
Rev])(-[classifier]).[ext]
Descriptor Path Patterns
A descriptor path pattern is used to recognize descriptor files (like or files). .pom ivy.xml
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 in cases of distinctive descriptors, such as Ivy highly recommended ivy_
and Maven . -1.0.xml bobs-tools-1.0.pom
For example -
To represent a normal Maven descriptor path: "org/eclipse/jetty/jetty-ajp/7.0.2.v20100331/jetty-ajp-7.0.2.v2010
" 0331.pom
Use the descriptor path pattern:
[orgPath]/[module]/[baseRev](-[folderItegRev])/[module]-[baseRev](-[fileItegRev]
)(-[classifier]).pom
To represent a default Gradle descriptor path: " " org.eclipse.jetty/jetty-ajp/ivy-7.0.2.v20100331.xml
Use the descriptor path pattern:
[org]/[module]/ivy-[baseRev](-[fileItegRev]).xml
Configuration
Repository 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 Configuration
Layout configuration is available to administrator users from the Admin tab and then . Configuration -> Repository Layouts
Additional layouts can be created from scratch by clicking the " " button or by duplicating an existing layout by clicking the " " button on a New Copy
selected layout.
Path Patterns
Define the artifact path pattern and the descriptor path pattern (optional), as explained above.
File and Folder Integration Revision Regular Expressions
These 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.
Use patterns in the directory part of the path
To achieve best path matching results, it is highly recommended that artifact and descriptor patterns also contain the mandatory
tokens ( or , and ) within the directory structure itself. [org] [orgPath] [module] [baseRev]
For example, Gradle's artifact path pattern:
[org]/[module]/[baseRev](-[folderItegRev])/[module]-[baseRev](-[fileItegRev])(-
[classifier]).[ext]
Avoid using capturing group syntax in regexp
Folder integration revision regular expression examples:
Maven's folder integration revision is simply the constant appended to the base revision ("1.2-SNAPSHOT"), so the regular -SNAPSHOT
expression is
SNAPSHOT
Ivy's default folder integration revision is usually equal to the file integration revision and is normally a 14 digit timestamp
("5.1-20101202161531"), so the regular expression can be
\d{14}
File integration revision regular expression examples:
Maven's file integration revision can be either the constant ("1.2-SNAPSHOT") or a timestamp, where the date and time are -SNAPSHOT
separated by a dot ('.'), with an addition of a dash ('-') and a build-number ("2.3-20110108.100922-2"), so the regular expression should
be able to fit them both
SNAPSHOT|(?:(?:\d{8}.\d{6})-(?:\d+))
Ivy's default file integration revision is is normally a 14 digit timestamp ("5.1-20101202161531") and usually equal to the folder
integration revision, so the regular expression may be the same as suggested in the file's example
\d{14}
Testing Layouts
Now 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.
Regular expressions entered in these fields are wrapped and treated as a single capturing group.
Refrain from introducing any capturing groups within the expressions. Failure to do so may result in unexpected behavior
compromise and the accuracy of the matcher.
Local Repository Configuration
Layouts 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.
Layouts 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 http://download.java.net/maven/1 stores its artifacts according to the
Maven 1 convention; you can configure the cache repository to use Maven 2's layout so that it handles Maven 2
requests and artifact storage, and configure the remote target to use Maven 1's layout so that outgoing requests are
translated to Maven 1's convention.
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 Configuration
You 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:
No module information can be constructed
The virtual module information cannot be mapped to a nested repository (missing fields on one of the side)
The virtual repository or the nested repository are not configured with a layout
Smart Searches
Introduction
Smart searches allow you to manage your artifacts by searching and performing bulk operations on search results.
This allows natural and easy support for items such as artifact promotion and procurement flows.
Artifactory allows you to save a search result, then use additional searches to add/remove new results from the
original result. Effectively, you are assembling a 'shopping cart' of artifacts, which you can then manipulate as one
unit - move, copy, export, annotate etc.
For example, you can search all artifacts deployed by a certain build (by build number), remove from the search results all the sources (by
making another search) and promote it to a public repository. Alternatively, you can search all POMs containing a specific license and move
them to a repository of approved artifacts, or attach an "approved" property to them.
From Staging to Promotion
For more detailed information about using Smart Searches for powerful, yet simple, promotion support please see . this blog entry
For a short demo of this, please watch the following screencast:
Atlassian Crowd Integration
Overview
The Artifactory Crowd Integration allows you to delegate authentication requests to Atlassian Crowd, use authenticated Crowd users and have
Artifactory participate in a transparent SSO environment managed by Crowd.
Usage
Crowd integration can then be configured from the Admin tab and then . Security -> Crowd Integration
1.
2.
3.
Enable Atlassian Crowd Integration Mark this checkbox to enable security integration with Atlassian
Crowd.
Crowd Server URL The full URL of the Crowd server to use.
Crowd Application Name The application name configured for Artifactory in Crowd.
Crowd Application Password The application password configured for Artifactory in Crowd.
Session Validation Interval The time window, in minutes, in which the session does not need to
be revalidated.
Use Default Proxy Configuration If this checkbox is marked and a default proxy definition exists, it is
used to pass through to the Crowd Server.
Auto Create Artifactory Users When automatic user creation is off, authenticated users will not be
automatically created inside Artifactory. Instead, for every request
from a Crowd user, the user is temporarily
associated with default groups (if such groups are defined), and the
permissions for these groups applies.
Without auto user creation, you will need to manually create the user
inside Artifactory in order to manage user permissions that are not
attached to his default groups.
Filter by Username Filter the search by username to see only groups of the specified
username
If unchecked, all Crowd groups are shown.
To enable Crowd integration:

First define Artifactory as a inside Crowd. Custom Application Client
Complete the Crowd server URL, and the application credentials defined in Step 1.
3.
4.
5.
6.
1.
2.
3.
4.
The session validation interval defines the principal token validity time in minutes. If left at the default of 0,
the token expires only when the session expires.
If you have a proxy server between the Artifactory server and the Crowd server, you may check the Use Default Proxy
check-box. Configuration
It is possible instruct Artifactory to treat externally authenticated users as temporary users, so that Artifactory does not automatically
create them in its security store. In this case, permissions for such users are based on the permissions given to auto-join groups.
Test the configured connection and save it.
Crowd Groups
To use Crowd groups:
Set up a Crowd server for authentication as detailed above.
Verify your setup by clicking the button on the sub-panel. A list of available Crowd groups, Refresh Synchronize Crowd Groups
according to your settings is displayed.
The groups table allows you to select which groups to import into Artifactory and displays the sync-state for each group. A group can
either be completely new or already exist in Artifactory.
Select and import the groups that you wish to import to Artifactory. Once a group is imported (synced) a new external Crowd group is
created in Artifactory with the name of the group.
You can on the synced Crowd groups as you do with regular Artifactory groups. Manage Permissions
Users association to these groups is external and controlled strictly by Crowd.
Single Sign-on
Overview
The Single Sign-on (SSO) Add-on allows you to reuse exiting HTTP-based SSO infrastructures with Artifactory, such the SSO modules offered
by Apache HTTPd.
You can have Artifactory's authentication work with commonly available SSO solutions, such as native NTLM,
Kerberos etc.
SSO works by letting Artifactory know what trusted information it should look for in the HTTP request, assuming this request has already been
authenticated by the SSO infrastructure, which sits in front of Artifactory.
Usage
The Single Sign-On (SSO) Add-on is available under the Admin tab and then . Security -> HTTP SSO
To enable SSO you must alert Artifactory that it is running behind a secure HTTP server that forwards trusted requests to it.
Then you must tell Artifactory where is the request to look for trusted authentication information.
The default is to look for a REMOTE_USER header or the request variable, which is set by Apache's AJP and JK
connectors.
You can choose to use any request attribute (as defined by the Servlet specification) by providing a different variable name.
System properties
Crowd configuration properties may be added to the Runtime system properties or to the $ARTIFACTORY_HOME/etc/artifactory
file. .system.properties
NOTE! that setting a configuration through properties overrides configurations set through the user interface.
Ensure the Crowd group settings is enabled in order for your settings to become effective.
Finally, you can instruct Artifactory to treat externally authenticated users as temporary users, so that Artifactory does not create them in its
security database.
In this case, permissions for such users are based on the permissions given to auto-join groups.

Artifactory is Proxied by a Secure HTTP Server When this checkbox is marked, Artifactory trusts incoming requests
and reuses the remote user originally set on the request by the SSO
of the HTTP server.
This is extremely useful if you want to use exiting enterprise SSO
integrations, such as the powerful authentication schemes provided
by Apache (mod_auth_ldap, mod_auth_ntlm, mod_auth_kerb, etc.).
When Artifactory is deployed as a webapp on Tomcat behind
Apache:
If using mod_proxy_ajp, make sure to set
tomcatAuthentication="false" on the AJP connector.
If using mod_jk, make sure to use the "JkEnvVar
REMOTE_USER" directive in Apache's config.
Remote User Request Variable The name of the HTTP request variable to use for extracting the user
identity. Default is: REMOTE_USER.
Auto Create Artifactory Users When automatic user creation is unchecked, authenticated users are
not automatically created inside Artifactory. Instead, for every
request from a SSO user, the user is temporarily associated with
default groups (if such groups are defined) and the permissions for
these groups apply.
Without auto user creation, you must manually create the user inside
Artifactory to manage user permissions not attached to its default
groups.
Integrating Apache and Tomcat
When Artifactory is deployed as a webapp on Tomcat behind Apache:
If using - Make sure to set on the AJP connector. mod_proxy_ajp tomcatAuthentication="false"
If using - Make sure to use the directive in Apache's configuration. mod_jk JkEnvVar REMOTE_USER
If using (requires , and - There are two known working methods that forward mod_proxy mod_proxy_http mod_headers mod_rewrite
the header:
Adding Your Own SSO Integration
You can write a simple servlet filter to integrate with custom security systems and set a request attribute on the request to be trusted
by the SSO add-on.
1.
2.
3.
4.
5.
6.
7.
8.
9.
RequestHeader set REMOTE_USER %{REMOTE_USER}e
or
RewriteEngine On
RewriteCond %{REMOTE_USER} (.+)
RewriteRule . - [E=RU:%1]
RequestHeader set REMOTE_USER %{RU}e
SAML SSO Integration
SAML (Security Assertion Markup Language)
SAML is an XML standard that allows you to exchange user authentication and authorization information between web domains.
JFrogs Artifactory offers a SAML-based Single Sign-On service allowing federated Artifactory partners (identity providers) full control over the
authorization process.
Using SAML, Artifactory acts as service provider which receives users authentication information from external identity providers.
In such case Artifactory is no longer responsible to authenticate the user although it still has to redirect the login request to the identity provider
and verify the integrity of the identity providers response.
Artifactorys SAML configuration
To use our SAML-based SSO in Artifactory:
Login as administrator to Artifactory
Click on the admin tab
Click on SAML Integration in the Security menu
Enable the SAML integration by checking the SAML Integration checkbox
Enable or disable the Auto create Artifactory users (Using SAML login) which allows to persist new users in the database
Provide the Identity provider http login redirect URL
Provide the identity provider http logout redirect URL
that in order to simultaneously logout from IDP and Artifactory, theIDPs logout URL must be provided, settingany other URL in NOTE!
the SAML Logout field, will logout from Artifactory but not from the identity provider
Provide the service provider name (Artifactory name in SAML federation)
Provide X.509 certificate that contains the public key. The public key can use either the DSA or RSA algorithms. Artifactory uses this key
to verify SAML response origination and integrity. It is important to match the embedded public key in the X.509 certificate with the
private key used to sign the SAML response.
9.
1.
2.
3.
4.
5.
6.
7.
8.
9.
Understanding Artifactory's SAML-based SSO Login Process

The user attempts to reach a hosted Artifactory, Home Page.
Artifactory generates a SAML authentication request.
The SAML request is encoded and embedded into the identity provider URL.
Artifactory sends a redirect to the user's browser. The redirect URL includes the encoded SAML authentication request that should be
submitted to the identity provider.
The identity provider decodes the SAML message and authenticates the user. Authentication process could be by asking for valid login
credentials or by checking for valid session cookies.
The identity provider generates a SAML response that contains the authenticated user's username. In accordance with the SAML 2.0
specification, this response is digitally signed with the identity providers private DSA/RSA keys.
The identity provider encodes the SAML response and returns that information to the user's browser. The identity provider redirects back
to Artifactory with signed response.
Artifactorys ACS verifies the SAML response using the partner's public key. If the response is successfully verified, ACS redirects the
user to the destination URL.
The user has been redirected to the destination URL and is logged in to Artifactory.
Figure (2) Artifactorys SAML-based SSO login process.
9.
1.
2.
3.
4.
5.
Understanding the Artifactory's SAML-based SSO Logout Process
The user attempts to reach a hosted Artifactory, logout link.
Artifactory logs-out the client and generates a SAML logout request.
Artifactory redirects to the identity provider with the encoded SAML logout request.
The identity provider decodes the SAML message and logs out the user.
The user is redirected to the configured URL in the identity provider.
Figure (3) Artifactorys SAML-based SSO logout process.

Artifactory Profiles and Bindings
Artifactory currently supports the Web Browser SSO and Single Logout Profiles.
The Web Browser SSO Profile uses http redirect binding to send the AuthnRequest from the service provider to the identity provider and
http POST to send the authentication response from the identity provider to the service provider.
Similar to the previous profile, the Single Logout Profile uses http redirect binding to send the LogoutRequest from the service provider to
the identity provider and http POST to send the logout response from the identity provider to the service provider.
If your IDP supports uploading service provider metadata, you can use the following metadata XML:
Figure (4) Artifactorys service provider metadata XML.
Artifactory SP metadata XML
<ns2:EntityDescriptor xmlns="http://www.w3.org/2000/09/xmldsig#"
xmlns:ns2="urn:oasis:names:tc:SAML:2.0:metadata" entityID="<SP_NAME_IN_FEDERATION>">
<ns2:SPSSODescriptor WantAssertionsSigned="true" AuthnRequestsSigned="false"
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

<ns2:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</ns2:NameIDFor
mat>
<ns2:AssertionConsumerService index="1"
Location="<ARTIFACTORY_URL>/artifactory/webapp/saml/loginResponse"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
</ns2:SPSSODescriptor>
</ns2:EntityDescriptor>
NOTE! that to use the service provider metadata:
Do not forget to update the following fields in the service provider metadata XML:
entityID - Artifactorys ID in the federation
Location - Artifactory's home URL
After SAML Setup
Using SAML Artifactory automatically redirects the request to IDP which Authenticate the user and after
success login redirects back to Artifactory.if Anonymous user is enabled , Artifactory doesnt have to authenticate the user
therefore it doesnt redirects to the IDP, if the user still wants to sign in through SAML, he can do so by clicking the "SSO login" link in the
login page.
Login Failure
In case of IDP failover or bad configuration, Artifactory allows you to bypass SAML login by using Artifactory
login page: http://<ARTIFACTORY_URL>/webapp/login.html
Filtered Resources
Overview
The Filtered Resources Add-on (introduced in Artifactory version 2.3.3) allows treating any textual file as a filtered resource by processing it as a
template. FreeMarker
Each file artifact can be marked as 'filtered' and upon a download request, the content of the artifact is passed
through a FreeMarker processer before being returned to the user.
This feature is extremely powerful and flexible since Artifactory provides some of its own API to the filtering context (see below), allowing you to
create and provision dynamic content, based on information stored in Artifactory.
For example, you can provision different content base on the user originating IP address or based on changing property values attached to the
artifact.
1.
2.
3.
4.
5.
Marking an Artifact as a Filtered Resource
Each artifact can become filtered by selecting it in the artifacts Tree Browser and marking the checkbox labeled 'Filtered' located in the 'General'
tab.
that you must have 'annotate' permissions on the artifact. NOTE!
Filtering Context
Artifactory provides the following environment variables for the FreeMarker template:
"properties" - Contains the of the requested artifact and any matrix params included in the ( ) org.artifactory.md.Properties properties
request; when a clash of properties with identical keys occurs, the former takes precedence
"request" - The current request that was sent for the artifact ( ) org.artifactory.request.Request
"security" - Artifactory's current security object ( ) org.artifactory.security.Security
Provisioning Build Tool Settings
When logged-in as an admin user, you can provision your user-generated settings for the various build tools (Maven, Gradle and Ivy) using the
Filtered Resources features.
To provision user-generated settings:
Browse to the settings generator of the desired build tool.
Select the appropriate repositories.
Edit the settings as required.
Under the "Settings Provisioning" section: select a target repository and path
Click Generate.
Example
The following example demonstrates provisioning a different resource based on the current user group and a property on the requested artifact.
In this example, the artifact 'vcsProj.conf.xml' has a property 'vcs.rootUrl' which holds the root URL for
the version control system. Depending on the user group a different project version control URL is returned.
For the template of : 'vcsProj.conf.xml'
<servers>
<#list properties.get("vcs.rootUrl") as vcsUrl>
<#list security.getCurrentUserGroupNames() as groupName>
<vcs>${vcsUrl}/<#if groupName == "dev-product1">product1<#elseif groupName ==
"dev-product2">product2<#else>global</#if></vcs>
</#list>
</#list>
</servers>
If, for example, the value of the the property on the artifact is and the 'vcs.rootUrl' 'vcsProj.conf.xml' 'http://vcs.company.com'
file is downloaded by a developer belonging to the group, then the returned content is: 'dev-product2'
<servers>
<vcs> http://vcs.company.com/product2 </vcs>
</servers>
Watches
Overview
The Watches feature allows you to monitor selected artifacts, folders or repositories for storage events (create/delete/modify) and receive
detailed email notifications on repository changes that are of interest to you.
You can add and remove Watches from the 'General' tab in the tree browser. Watches or folders intercept changes on all children. An admin
can view and manage watches via the 'Watches' tab in the tree browser.
Watch notifications are aggregated at around 1 minute intervals and sent in a single email message.
All notifications respect the read permissions of the watcher on the watched item(s).
WebStart and Jar Signing
Resources used in the screencast
The JavaFX Maven Plugin provided by JFrog has it's own . documentation page
The personal test PKS (acme-demo.store file) was done using the java keytool:
keytool -keystore acme-demo.store -keypass password -storepass password -alias
acme-demo \
-genkeypair -dname "cn=Acme Dev, ou=r&d, o=ACME, S=United States, c=US"
-validity 365
The FishSim demo subversion is . here
You can test this Add-on for free (no questions asked) for 30 days, with the two main repositories required (jfrog plugins, jfrog libs), using
. Artifactory Online
How to build FishSim
If you are not using Artifactory as illustrated in the screencast, you can activate the profile "jfrog" to access the repo.jfrog.org required resources.
This enables build running "mvn -Pjfrog install" to work.
Bintray Integration
Bintray is the industry's first social platform for storage and distribution of software libraries from JFrog. It is the new way for developers to
publish, download and share software across one unified community around the world.The free, cloud-based platform empowers developers to
control and streamline the entire process of making software libraries publicly available, with all the services needed to collaborate, advertise and
deploy a new software solution.
Naturally, Artifactory integrates with Bintray in more than one way:
Remote Search in Bintray's JCenter repository - the most comprehensive collection of Maven artifacts.
Information insight from Bintray on artifacts - package description and latest released version.
Pushing artifacts to Bintray (one by one or a whole build outcomes).
Complete continuous delivery stack for selected OSS projects based on oss.jfrog.org and Bintray.
Bintray info panel
As part of the new Artifactory and Bintray integration, additional information about stored components is fetched from Bintray and displayed in the
tree browser.
The information is provided by Bintray and can be found in the Tree browser's info panel: Artifacts->Browser->Tree Browser.
The panel appears under the following conditions:

The user is logged in
The user configured Bintray API Key in his profile
The file type is supported (e.g., pom, jar, war, ear)
Push To Bintray
Overview
This page describes the process of pushing a single artifact or a complete release build from Artifactory to . Bintray
Bintray is a public online service through which you can share your release binaries with the world.Note that once artifacts are pushed, you need
to publish them in Bintray in order to make them world-visible.
General
Under the hood Artifactory utilizes the feature to save the Bintray push information, these are: Properties
bintray.repo -A target repository in Bintray, in the format of {username}/{repository}
- bintray.package A target package name under the repository.You must create the package in Bintray first if it does not exist.
- bintray.version A target version under the package.If the version does not yet exist in Bintray, it is auto-created.
- bintray.path A target path in the repository to save the file under.
Entering your Bintray credentials

Before you start pushing artifacts to Bintray, you need to enter your and in the profile page, see Bintray username API key Updating Your
. Profile
Pushing A Single Artifact
Pushing a single artifact is done from the Tree Browser, simply click on the file and choose the General Info tab:
The path is considered optional as Artifactory will use the same path the file is stored in the repository.
Usually, these properties will not exist on the artifact if it was not pushed before, using the UI above will attach them according to the
user input.
All of the properties can be pre-populated (for example by your build tool), in this case Artifactory will use any existing property and will
the user input from the UI unless the property doesn't exist. ignore
Push A Complete Build
Pushing a complete released build is done from the build General Info panel and it essentially pushes all the build artifacts one by one:
Use Bintray-specific artifact properties - Marking this option tells Artifactory to look for the properties attached to each build artifact and
ignore the input from the UI (in case a property exists).
Send Email Notification - Mark it to receive an email once the operation is finished (regardless of it's status).
Push - pushes all the build artifactssynchronously.
Background Push - pushes all the build artifactsasynchronously (usually best when usedwith an email notification).
Deploying Maven and Gradle snapshots to OJO (oss.jfrog.org)
1.
2.
3.
1.
2.
Target Audience
OSS contributors who want a free repository to host build snapshots and eventually publish release versions to distribution via without Bintray
hassle.
What is OJO
oss.jfrog.org or for short, is a Cloud instance for hosting your maven-compatible build snapshots, provided free of charge for OJO Artifactory
selected opensource software projects.
All projects in OJO are public (all the artifacts and the builds are viewable to all).
Exiting Bintray usersare granted deploy permissions to relevant folders in Artifactory, according to the Maven group ID of the packages they
build.
In a Glance
This page describes the process of on-boardingto OJO; working with it to deploycontinuoussnapshots;and, finally, promoting these snapshots
from OJO to Bintray for distribution.
It only takes three simple steps:
Creating an account on OJO
Build and deploy to the OJO Artifactory
Promote a snapshot build to Bintray
Getting Started with OJO
To get account on OJO you have to have an account on Bintray.
Create a Maven repo on Bintray if it does not exist yet, and create your package inside this repo.
You can give your package any logical name, for example: maven2gradle
Ask for inclusion of the package in JCenter, by clicking the " " button in the package main page. Add to JCenter
In the request form, check " snapshot Host my build artifacts on the OSS Artifactory athttps://oss.jfrog.org" and enter the desired
Maven group ID for your package.
For example: org.github.jbaruch.maven2gradle
After your request has been approved byBintray Team(usually within just a couple of hours), you'll receive two confirmation emails - one for the
inclusion of your package in JCenter and another one for your new OJO account.
Working with OJO
After your OJO account has been created you (and all the team members in case of organization repository) should be able to login to OJO
using your and as the password. Bintray username API key
You will see that a folder corresponding to the Maven group ID has been created in OJO in the and the oss-release-local oss-snapshot-
repositories: local
OJO is Artifactory!
OJO is just a regular Artifactory Pro server, so is recommended. getting familiar with Artifactory
Bintray Organizations Support
When asking OJO account for an organizational repository, the permissions in OJO will be granted to all the organization members,
not only the member who asked for the OJO account.
1.
a.
b.
2.
You have deploy permissions to these folders:
Resolving from and Publishing to OJO
Working with snapshots repository is nothing special, you can configure your build tool to resolve release and snapshot dependencies from the l
and the OJO virtual repositories, respectively; and to deploy build snapshots to the re ibs-release libs-snapshot oss-snapshot-local
pository.
As long as the <groupId> in your pom (for Maven) or the project.group (for Gradle) matches the group ID you requested during
onboarding, the deployment should succeed.
Please consult the Artifactory documentation on how to set up your or for resolution and deployment. Maven Gradle
Releasing to Bintray
Currently, you have two ways to deploy artifacts to Bintray:
Thiswill promote snapshot artifacts to release and the deploy them to Bintray:
Use promotion from the Jenkins Artifactory plugin-This allows you to use the Jenkins UI to promote the snapshot artifacts from
a selected job run.
Invoking promotion with REST-This allows promotion of a build created with any build server/tool and full programatic
automation of the promotion process.
Uploading Release Artifacts
Directly upload deployed release artifact to Bintray. If you have a released version of an artifact or a build you can deploy them to Bintray
using the . regular Bintray integration
Artifactory Build Info is a must!
In order to release and promote snapshots to Bintray you need to deploy a Build Info BOM to Artifactory. The easiest way to achieve
this automatically it is to use feature of Artifactory or the ; These and other options are Build Integration Gradle Artifactory Plugin
described in the next section.
1.
2.
3.
Promoting a Build from Jenkins
Promotion from Jenkins is performed by invoking a custom " "promotion plugin. Here's what you need to do: snapshotsToBintray
Install the and configure Artifactory servers and repositories in Jenkins configuration as described in Jenkins Artifactory Plugin the
. You should configure the and as release and snapshot targets, documentation oss-release-local oss-snapshot-local
respectively.
In your build configuration, add the "Deploy artifacts to Artifactory" post build action and check "Deploy Maven artifacts", "Capture and
publish build info" and "Allow promotion of non-staged builds":
Run your build. Upon successful completion, the build result page will have a link to the "Artifactory Release Promotion" action:
3.
4.
a.
b.
5.
1.
In the promotion configuration screen, select "snapshotsToBintray" promotion plugin:
There are two parameters to configure here:
Override the release version. By default, the version is calculated by removing the -SNAPSHOT suffix from the snapshot
version, e.g. will be released to Bintray as version . 1.0-SNAPSHOT 1.0
Specifying a value in this field overrides the default version scheme.
Append a timestamp to the version. This will add a timestamp string (in Maven's timestamp format: ) to the yyyyMMdd.HHmmss
release version. Values of , or will cause the timestamp suffix to be appended. true y 1
Click the "Update" button. Your release artifacts are in Bintray now.
Promoting a Build Using REST API
If you don't use Jenkins or if you need fully automated promotion, you can issue a HTTP PUT request that will trigger promotion and release to
Bintray.Promotion still operates on a Build Info BOM, previously saved in Artifactory.
Here's what you need to do:
1.
a.
b.
c.
2.
Deploy a build to Artifactory in one of the following ways:
Using a build server with Artifactory plugin. Plugins currently exist for Jenkins, Hudson, Bamboo and TeamCity. Please see the
for further instructions on getting build info BOM into Artifactory. Artifactory Build Integration documentation
Using the . Gradle Artifactory Plugin
Configure Maven to use Artifactory Listener as described . here
Execute the . The call accepts the same parameters as the . Here's an build promotion plugin call invocation of Jenkins promotion plugin
example using CURL:
curl -X POST -u bintrayUser:apiKey
http://oss.jfrog.org/api/plugins/build/promote/snapshotsToBintray/buildName/3
Troubleshooting
The Artifactory Mailing Lists
The best way to get help is to use our mailing list: Artifactory Users
Archive using Nabble
Subscribe using mailman
Release Notes
Artifactory 3.0.0
Artifactory 3.0.2
Artifactory 3.0.1
Artifactory 2.x
Artifactory 2.6.7
Artifactory 2.6.6
Artifactory 2.6.5
Artifactory 2.6.4
Artifactory 2.6.3
Artifactory 2.6.2
Artifactory 2.6.1
Artifactory 2.6.0
Artifactory 2.5.2
Artifactory 2.5.1.1
Artifactory 2.5.1
Artifactory 2.5.0
Artifactory 2.4.2
Artifactory 2.4.1
Artifactory 2.4.0
Artifactory 2.3.4.1
Artifactory 2.3.4
Artifactory 2.3.3
Artifactory 2.3.2
Artifactory 2.3.1
Artifactory 2.3.0
Artifactory 2.2.5
Artifactory 2.2.4
Artifactory 2.2.3
Artifactory 2.2.2
Artifactory 2.2.1
Artifactory 2.2.0
Artifactory 2.1.3
Artifactory 2.1.2
Artifactory 2.1.1
1.3.0-RC2
1.3.0-RC1
1.3.0-beta-6
1.3.0-beta-5
1.3.0-beta-4
1.3.0-beta-3
Artifactory 2.x
Artifactory 2.6.7
Artifactory 2.6.6
Artifactory 2.6.5
Artifactory 2.6.4
Artifactory 2.6.3
Artifactory 2.6.2
Artifactory 2.6.1
Artifactory 2.6.0
Artifactory 2.5.2
Artifactory 2.5.1.1
Artifactory 2.5.1
Artifactory 2.5.0
Artifactory 2.4.2
Artifactory 2.4.1
Artifactory 2.4.0
Artifactory 2.3.4.1
Artifactory 2.3.4
Artifactory 2.3.3
Artifactory 2.3.2
Artifactory 2.3.1
Artifactory 2.3.0
Artifactory 2.2.5
Artifactory 2.2.4
Artifactory 2.2.3
Artifactory 2.2.2
Artifactory 2.2.1
Artifactory 2.2.0
Artifactory 2.1.3
Artifactory 2.1.2
Artifactory 2.1.1
1.3.0-RC2
1.3.0-RC1
1.3.0-beta-6
1.3.0-beta-5
1.3.0-beta-4
1.3.0-beta-3
1.3.0-RC2
Artifactory 1.3.0-RC2
We are pleased to announce the availability of Artifactory 1.3.0-RC2.
Major Features and Changes in This Release
Deleting (undeploying) artifacts immediately updates the relevant maven-metadata.xml.
Ability to upload and deploy a bundle of multiple artifacts (zip archive) arranged in m2 format.
Bug fixes.
Enjoy
The Artifactory Team
Installing
Please refer to the section of the current user guide, which still applies. Installing
Upgrading from 1.3.0-RC1
Just replace the war file. If you are running on Tomcat make sure to also remove the exploded artifactory webapp directory.
Upgrading from 1.2.2-rc0 through 1.3.0-beta-6.1
Artifactory is available for immediate download from . here
You can browse the full JIRA release notes . here
1.
2.
1.
2.
3.
1.
2.
3.
4.
5.
1.
2.
a.
b.
3.
4.
Upgrading Artifactory from older version can be done in two ways:
From the UI
By using the command line tool artadmin
Upgrading Using the Web UI
Upgrading from the UI is currently supported only from previous 1.3.0-x versions.
From your old Artifactory installation run Full System Export and save the export to a destination directory.
Perform a new clean server installation of the new Artifactory (It should not contain repository data or your customized version of the
Artifactory configuration xml file).
Install the new Artifactory version, go to , select your previous export target directory and let Admin/Export&Import/System/Import System
the import run. That's it!
Upgrading Using the Tool artadmin
While upgrading from the web UI is easy and straightforward, sometimes the upgrade process can take a long time, especially with very large
repositories. In such cases the original web request may time out and the upgrade progress will proceed in the background.
Therefore, if you wish to monitor the progress of the upgrade process in the most reliable way and gain access to more advanced dump options,
it is recommended to use the command-line tool. artadmin
Here are step-by-step instructions:
Stop your old Artifactory.
Execute the command on the old or on a copy of it (recommended): artadmin dump $ARTIFACTORY_HOME
artadmin dump $ARTIFACTORY_HOME
This will generate a folder under the current execution directory with the old repository data in a format suitable for dumpExport
importing into a current Artifactory.
NOTE: By default, caches (e.g. repo1) are . To export caches add the parameter. not exported --caches
Perform a new clean server installation of the new Artifactory (It should not contain repository data or your customized version of the
Artifactory configuration xml file).
Start the new Artifactory.
Import the folder into Artifactory, either from the UI, as explained in the previous section or by running: dumpExport
artadmin import dumpExport --username admin --password password
The output will display the progress of the import. NOTE: If the process is killed, the import will still run in artadmin artadmin
Artifactory.
Important Information
If you are running Artifactory under JDK 1.6 you MUST use and above due to incompatibilities with older JAXB versions JDK 1.6u4
embedded in previous JDK 1.6 releases. JDK 1.5 users are not affected by this.
If you have used a previous version of Artifactory it is highly recommended to:
Use a fresh version of Artifactory from the distribution and not try to patch the previous installation.
Clear your browser's cache before using this version.
The default Artifactory user for the standalone installation has been changed to (instead of ). You might have to artifactory jetty
update the provided install script or your file system permissions accordingly.
Please note that not all documentation has been updated yet to reflect the latest changes in this release.
Please read this carefully before installing or upgrading:
Important information about the import process
During the import binary artifacts are copied over into a working copy and are imported into Arifactory in by a background thread. This
speeds up the import process dramatically and makes Artifactory ready for serving requests as soon as possible. The background
import process will take some time to completes, depending on the size of your repository. During this time Artifactory might perform
more slowly than usual, but it will still serve any artifact immediately. The log does provide visible information about the progress of this
process.
Repeating the upgrade process
Should you wish to repeat the upgrade process from scratch, make sure to remove the folder from your $ARTIFACTORY_HOME/data
Major Features and Changes in release 1.3.0-rc-1
Flexible validation for remote checksums: Generate if absent (the default), Fail, Ignore and generate and Pass-through (please see the
UI for description of each policy).
Many bug fixes and stability improvements.
Better support. MySql
Improved support for Safari.
Artifactory and artadmin are now under a single downloadable distribution.
Better overall performance.
Major Features and Changes in release 1.3.0-beta-6
Artifactory is 100% configurable via the newly designed user interface
Support for running Artifactory with for greater scalability, performance and tools support. MySql
Support for running Artifactory under . Websphere
Install script for automatic set up under a dedicated instance. Tomcat
Ability to remove deployed versions with all their sub-artifacts in one go.
Dynamic log tailing from the UI.
Global offline flag for disconnected environments.
Out of the box support for running standalone Artifactory as a (in additional to the existing Unix service installer). Windows service
Unified CLI tool for all administrative tasks. artadmin
Greatly improved backup and restore speed.
Many internal performance and concurrency improvements.
The usual bug fixes.
In place incremental backup.
Performance improvements around security authentication and authorization.
Fixed a UI bug with remote repositories cache access control setup.
Improved - support for multiple DNs, for non-anonymous binding against MS Active Directory and for sub-tree searches. LDAP Support
Fixed a critical issue with deployment using the lightweight HTTP wagon (RTFACT-629).
UI and performance improvements and the usual bug fixes.
Group support with an intuitive powerful UI for groups management.
Improved permissions control for including/excluding specific repository paths (e.g. disallow certain users/groups from downloading
sources). Simple management - no regexp gurus required.
Support for delete permission and for preventing users from overriding exiting artifacts.
Revised repository tree browsing using tabs and effective permissions per item view.
Improved import speed by committing binary imports asynchronously.
Improved procedure. #upgrade
Better transaction management using Spring Modules for JCR.
Even faster in-place incremental backup.
Low-level admin-only direct WebDAV access to the underlying jackrabbit repository (use: to http://localhost:8081/artifactory/jcr/default/
connect).
The usual bug fixes, stability and speed improvements.
The complete release notes from Jira are available here:
1.3.0-rc-2
1.3.0-rc-1
1.3.0-beta-6
1.3.0-beta-5
1.3.0-beta-4
1.3.0-beta-3
1.3.0-RC1
Artifactory 1.3.0-RC1
We are pleased to announce the availability of Artifactory 1.3.0-RC1.
Major Features and Changes in this Release
new Artifactory installation before doing so.
Flexible validation for remote checksums: Generate if absent (the default), Fail, Ignore and generate and Pass-through (please see the
UI for description of each policy).
Many bug fixes and stability improvements.
Better support. MySql
Improved support for Safari.
Artifactory and artadmin are now under a single downloadable distribution.
Better overall performance.
Artifactory is 100% configurable via the newly designed user interface
connect).
1.3.0-rc-1
1.3.0-beta-6
1.3.0-beta-5
1.3.0-beta-4
1.3.0-beta-3
Artifactory 1.3.0-beta-6 is available for immediate download . here
Enjoy
Important Notes Before You Install
You can browse the full JIRA release notes . here
1.
2.
a.
b.
3.
4.
5.
1.
2.
3.
4.
1.
2.
3.
4.
5.
6.
7.
a.
b.
a.
b.
c.
8.
Artifactory now includes a convenience method for specifying system properties. Instead of having to configure properties in the runtime
configuration of the hosting container, you can now edit the file and restart $ARTIFACTORY_HOME/etc/artifactory.properties
the container. As this affects the whole container VM it is recommended to use this feature for specifying Artifactory related properties
only (such as repository ids substitution, etc.).
Please note that not all documentation has been updated yet to reflect the latest changes in this beta release.
Below is important information that will make it into the final Artifactory 1.3.0 documentation.
Installing
Upgrading from 1.2.2-rc0 through 1.3.0-beta-6.1
To upgrade from older versions you first need to dump the data from you old Artifactory into a 1.3 compatible format and then import it to the new
Artifactory.
We expect that with 1.3.0 and above upgrading can be done directly on an existing repository without the need to export it first.
Dumping the old version
Since Artifactory 1.3.0-beta-5, JFrog merged the tool with the main CLI administration tool: - creating the CLI " " artdump artadmin dump
command.
The tool can be found under the folder. artadmin $ARTIFACTORY_HOME/bin
Important Information for Running the Dump
By default, cached repositories (e.g. repo1) are . To export cached repositories pass the parameter. not exported --caches
You should shut down the old Artifactory before executing the export.
It is recommended to work on a copy of the old folder (even though the export should be a read only process). $ARTIFACTORY_HOME
If you do not specify a destination folder with option, the dump command will create a folder under the current --dest tmpExport
execution directory, where it will export all the data from your old Artifactory.
Step by Step Instructions
Here are step by step instructions for running the full upgrade process:
Stop the old Artifactory.
Optional: Copy the folder to a new location. $ARTIFACTORY_HOME
If you created a copy and wish the old Artifactory to keep serving requests while performing the export, you can start it now.
Execute the command on the old or on a copy of it, by running dump #artadmin $ARTIFACTORY_HOME artadmin dump
(This will generate a folder if you did not specify a destination folder with option). $ARTIFACTORY_HOME tmpExport --dest
Perform a new clean server installation of Artifactory 1.3. It should not contain repository data or your customized version of the
Artifactory configuration xml file.
Start Artifactory 1.3. Note: If in step 3 you chose to restart your old Artifactory and you installed the Artifactory 1.3 on the same machine,
you will need to alter the listening port number inside . It is also highly recommended to use a $ARTIFACTORY_HOME/etc/jetty.xml
different port in order to perform the upgrade on a "silent" instance that is not being hit by user requests in parallel.
The import can be done in 2 ways:
Import with the command line (highly recommended): artadmin
Execute artadmin import tmpExport --username username --password password.
The output will display the progress of the import. NOTE: If the process is killed, the import will artadmin artadmin
still run in Artifactory.
Import via the Web UI:
Logon with admin/password credentials, click the "Admin" tab and choose "System" from the "Import & Export"
sub-menu on the left.
Enter the export directory into the "System zip file or directory" field in the "Import System" field-set and click the
"Import" button.
The import will run and may take some time to complete (depending on the size of your database).
Once the import process completes successfully you can switch to using Artifactory 1.3. You can go back to use the old port number (if
you changed it in step 6).
8.
artadmin dump command line usage:
usage: dump [Artifactory home folder] ...
Artifactory will try to automcatically determine the previous version from
$ARTIFACTORY_HOME/webapps/artifactory.war if present.
If the war file cannot be found at this location, please do one of the
following:
1) link or copy it at this location, or pass the version.
2) pass one of the following version as second parameter:
1.2.2-rc0 1.2.2-rc1 1.2.2-rc2 1.2.2 1.2.5-rc0
1.2.5-rc1 1.2.5-rc2 1.2.5-rc3 1.2.5-rc4 1.2.5-rc5
1.2.5-rc6 1.2.5 1.2.5u1 1.3.0-beta-1 1.3.0-beta-2
1.3.0-beta-3 1.3.0-beta-4 1.3.0-beta-5
Valid options:
--dest [destination folder]: the destination folder for the new export
files. Default value: tmpExport
--version [version name]: the actual version of the old Artifactory if
the Update Manager cannot find it
--caches: include cached repositories in the export (by default caches
are not exported). If repo option is passed this option will be ignored
--security: only export the security file from DB, and set the norepo
flag
--repo [repo names separated by ':']: export only a specified list of
repositories. Default value: all-non-cached
--norepo: does not export the repositories, just convert config and
security
--convert: activate the Local and Virtual repository names conversion
--noconvert: does not activate the Local and Virtual repository names
conversion during a full export
artadmin import command line usage:
During the import binary artifacts are copied over into a working copy and are imported into Arifactory in by a background
thread. This speeds up the import process dramatically and makes Artifactory ready for serving requests as soon as possible.
The background import process will take some time to completes, depending on the size of your repository. During this time
Artifactory might perform more slowly than usual, but it will still serve any artifact immediately. The log does provide visible
information about the progress of this process.
Should you wish to repeat the upgrade process from scratch, make sure to remove the folder $ARTIFACTORY_HOME/data
from your new Artifactory installation before doing so.
usage: import [import from path] ...
Valid options:
--ssl: Activate https instead of http. Default is false
--server [the server host or ip]: The remote Artifactory server IP or
host name with optional port number. The default is localhost:8081
--timeout [timeout in seconds]: Set the timeout of the HTTP connection.
--url [root url to rest api]: The root URL of the Artifactry REST API.
The default is http://[servername]/artifactory/api
--username [username]: Optional username to use when connecting to the
remote Artifactory
--password [password]: The users's clear text password
--noMetadata: Exclude metadata information when importing/exporting
--symlinks: Use symbolic links to the original import path file (no file
copying)
--syncImport: Import directly into Artifactory without using the
background import process
--verbose: display maximum details
--failFast: fail at first error
--failIfEmpty: fail at empty directories
artadmin command line usage:
Usage: artadmin <command> [arg] [options]
Type 'artadmin help <command>' for help on a specific command.
Available commands:
help: The help message
info: Get system information
export: Export artifactory data to destination path
import: Import full system from import path
dump: Dump the database of an older version of Artifactory
compress: Compress the database tables (Derby only) in order to free up
disk space.
1.3.0-beta-6
Artifactory 1.3.0-beta-6
We are pleased to announce the availability of Artifactory 1.3.0-beta-6.
Artifactory is now fully configurable via the newly designed user interface!
Options for the import process
When used with the option, the import process can perform much faster (usually by a factor of 3-5). Note that --symlinks
when using this option your imported path effectively becomes an integral part of Artifactory and you should not move/remove
it until the background import process has completed. This is indicated by the log message: Working copy commit done
(0 files).
When using external database (like MySql) it is recommended to deactivate the working copy mechanism. To do this, use the
. --syncImport
connect).
1.3.0-beta-6
1.3.0-beta-5
1.3.0-beta-4
1.3.0-beta-3
Enjoy
1.
2.
a.
b.
3.
4.
5.
1.
2.
3.
4.
1.
2.
3.
4.
5.
6.
7.
a.
b.
a.
b.
c.
8.
Below is important information that will make it into the final Artifactory 1.3.0 documentation.
Installing
Upgrading from 1.2.2-rc0 through 1.3.0-beta-5
Artifactory.
We expect that with 1.3.0 and above upgrading can be done directly on an existing repository without the need to export it first.
Since Artifactory 1.3.0-beta-5, JFrog merged the tool with the main CLI administration tool: - creating the CLI " " artdump artadmin dump
command.
The tool can be found inside the archive, downloadable from . artadmin bin artifactory-cli-1.3.x.zip here
By default, cached repositories (e.g. repo1) are . To export cached repositories pass the parameter. not exported --caches
It is recommended to work on a copy of the old folder (even though the export should be a read only process). $ARTIFACTORY_HOME
If you do not specify a destination folder with option, the dump command will create a folder under the current --dest tmpExport
execution directory, where it will export all the data from your old Artifactory.
Execute the command on the old or on a copy of it, by running dump #artadmin $ARTIFACTORY_HOME artadmin dump
(This will generate a folder if you did not specify a destination folder with option). $ARTIFACTORY_HOME tmpExport --dest
Perform a new clean server installation of Artifactory 1.3. It should not contain repository data or your customized version of the
Artifactory configuration xml file.
Execute artadmin import tmpExport --username username --password password.
The output will display the progress of the import. NOTE: If the process is killed, the import will artadmin artadmin
Logon with admin/password credentials, click the "Admin" tab and choose "System" from the "Import & Export"
sub-menu on the left.
Enter the export directory into the "System zip file or directory" field in the "Import System" field-set and click the
"Import" button.
The import will run and may take some time to complete (depending on the size of your database).
Once the import process completes successfully you can switch to using Artifactory 1.3. You can go back to use the old port number (if
you changed it in step 6).
8.
artadmin dump command line usage:
usage: dump [Artifactory home folder] ...
Artifactory will try to automcatically determine the previous version from
$ARTIFACTORY_HOME/webapps/artifactory.war if present.
If the war file cannot be found at this location, please do one of the
following:
1.2.2-rc0 1.2.2-rc1 1.2.2-rc2 1.2.2 1.2.5-rc0
1.2.5-rc1 1.2.5-rc2 1.2.5-rc3 1.2.5-rc4 1.2.5-rc5
1.2.5-rc6 1.2.5 1.2.5u1 1.3.0-beta-1 1.3.0-beta-2
1.3.0-beta-3 1.3.0-beta-4 1.3.0-beta-5
Valid options:
--dest [destination folder]: the destination folder for the new export
--version [version name]: the actual version of the old Artifactory if
--caches: include cached repositories in the export (by default caches
--security: only export the security file from DB, and set the norepo
flag
--repo [repo names separated by ':']: export only a specified list of
--norepo: does not export the repositories, just convert config and
security
--convert: activate the Local and Virtual repository names conversion
--noconvert: does not activate the Local and Virtual repository names
artadmin import command line usage:
usage: import [import from path] ...
Valid options:
--ssl: Activate https instead of http. Default is false
--server [the server host or ip]: The remote Artifactory server IP or
--timeout [timeout in seconds]: Set the timeout of the HTTP connection.
--url [root url to rest api]: The root URL of the Artifactry REST API.
--username [username]: Optional username to use when connecting to the
remote Artifactory
--password [password]: The users's clear text password
--noMetadata: Exclude metadata information when importing/exporting
--symlinks: Use symbolic links to the original import path file (no file
copying)
--syncImport: Import directly into Artifactory without using the
--verbose: display maximum details
--failFast: fail at first error
--failIfEmpty: fail at empty directories
Usage: artadmin <command> [arg] [options]
Type 'artadmin help <command>' for help on a specific command.
Available commands:
help: The help message
info: Get system information
export: Export artifactory data to destination path
import: Import full system from import path
dump: Dump the database of an older version of Artifactory
compress: Compress the database tables in order to free up disk space.
1.3.0-beta-5
Options for the import process
When used with the option, the import process can perform much faster (usually by a factor of 3-5). Note that --symlinks
when using this option your imported path effectively becomes an integral part of Artifactory and you should not move/remove
it until the background import process has completed. This is indicated by the log message: Working copy commit done
(0 files).
When using external database (like MySql) it is recommended to deactivate the working copy mechanism. To do this, use the
. --syncImport
1.
2.
3.
4.
5.
6.
Improved - support for multiple DNs, for non-anonymous binding against MS Active Directory and for sub-tree searches. #LDAP Support
Group support with an intuitive powerful UI for groups management (see: ).
sources). Simple management - no regexp gurus required (see: ).
Revised repository tree browsing using tabs and effective permissions per item view (see: ).
Low-level admin-only direct webdav access to the underlying jackrabbit repository (use: to http://localhost:8081/artifactory/jcr/default/
connect).
1.3.0-beta-5
1.3.0-beta-4
1.3.0-beta-3
Enjoy
Please read carefully before installing or upgrading:
If you have used a previous version of Artifactory it is recommended to clear your browser's cache before using this version.
To use the new incremental backup feature, specify under the backup <retentionPeriodHours>0</retentionPeriodHours>
configuration. This will cause backups to be written into a permanent " " directory in a format that can be used by any current
incremental file-system based backup utility (such as rsync).
The M2Eclipse indexing service runs by default on all repositories every round hour. The run interval can be controlled via the artifac
file, and repositories can be excluded from being indexed (similar to the configuration of the backup service). tory.config.xml
Below is important information that will make its way into the final Artifactory 1.3.0 documentation.
Installing
LDAP Support
General
Besides its own users database, Artifactory also supports authenticating users against an LDAP server.
If LDAP is configured in Artifactory configuration file, Artifactory will first attempt to authenticate the user against the LDAP server. If the LDAP
authentication fails, Artifactory will try to authenticate via the internal database.
For every LDAP authenticated user Artifactory creates new user in the internal database if that user doesn't exist.
Configuration
LDAP Configuration is placed under the security tag in artifactory.config.xml. For example:
<security>
<anonAccessEnabled>false</anonAccessEnabled>
<ldapSettings>
<ldapUrl>ldap://127.0.0.1:389/dc=jfrog,dc=org</ldapUrl>
<authenticationPatterns>

<authenticationPattern>
<userDnPattern>uid={0},ou=People</userDnPattern>
</authenticationPattern>

<searchFilter>sAMAccountName={0}</searchFilter>
<searchSubTree>true</searchSubTree>
</authenticationPatterns>
<managerDn>cn=ReadOnlyUser,ou=People,dc=jfrog,dc=org</managerDn>
<managerPassword>password</managerPassword>
</ldapSettings>
</security>
Where:
ldapUrl - Location of the ldap server in the form of: ldap://myserver:myport/dc=sampledomain,dc=com. It should include the base DN for
searching and/or authenticating users.
authenticationPatterns - A list of user DN patterns or search criteria used to find an authenticated user. Each authentication pattern
element will be tried until a user is found and authenticated. If no user is found or authentication failed, a BadCredentials exception will
be thrown.
authenticationPattern - An authentication pattern can include either a userDnPattern for "direct" authentication or searchFilter for user
"search" (after binding with a manager DN) and then authentication of the found user. The and are not managerDn managerPassword
used for "direct" DN authentication.
userDnPattern - A DN pattern that can used to directly login users to the LDAP database. This pattern is used for creating a DN string
for "direct" user authentication, where the pattern is relative to the base DN in the ldapUrl. The pattern argument {0} will be replace with
the username in runtime. This will work only if anonymous binding is allowed and a direct user DN can be used (which is not the default
case for Active Directory).
Example:
uid={0},ou=People
searchFilter - The filter expression used for searching a user. This is an LDAP search filter (as defined in 'RFC 2254' ) with faqs.org ietf
optional arguments. See the documentation for the method of for more search javax.naming.directory.DirContext
information. The search method will be called with as , a single containing the username, a searchBase name filterArg filterExpr
with this value and search affected by the value of . Authentication to LDAP will be done from the DN searchFilter cons searchSubTree
found.
}, for use with Active Directory, or sAMAccountName={0
}, for use with other LDAP servers. uid={0
searchBase - Context name to search in, relative to the base DN in the ldapUrl. This is parameter is optional.
searchSubTree - Flag to enable deep search through the sub tree of the ldapUrl + searchBase. True by default.
managerDn - Used only with "search" authentication method. It is the DN of the user who will bind to the LDAP server to perform the
search.
managerPassword - Used only with "search" authentication method. It is the password of the user who will bind to the LDAP server to
perform the search.
Upgrading from 1.3.0-beta-3 through 1.3.0-beta-4 to 1.3.0-beta-5
Shutdown Artifactory and replace the war. If you are on Tomcat make sure the remove the expanded folder as well. webapps/artifactory
Upgrading from 1.2.2-rc0 through 1.3.0-beta-2 to 1.3.0-beta-5
Artifactory.
1.
2.
3.
4.
1.
2.
3.
4.
5.
6.
7.
a.
b.
a.
b.
c.
8.
We expect that with 1.3.0 and above upgrading can be done directly on an exiting repository without the need to export it first.
Since Artifactory 1.3.0-beta-1, JFrog provides a command line tool: for dumping (previously: ). artdump artifactoryExport
The tool can be found inside the archive, downloadable from . artdump bin artifactory-update-1.3.x.zip here
By default cached repositories (e.g. repo1) are . To export cached repositories pass the parameter. not exported --caches
It is recommended to work on a copy of the old folder (that, even though the export should be a read only $ARTIFACTORY_HOME
process).
Running the update creates a folder (if you did not specify a destination folder with option) under the current tmpExport --dest
execution directory, where it exports all data from your old Artifactory. This folder is next used to do a full system import to tmpExport
the new Artifactory.
Execute the on the old or on a copy of it, by running . This #artdump $ARTIFACTORY_HOME artdump --home $ARTIFACTORY_HOME
will generate a folder if you did not specify a destination folder with option. tmpExport --dest
Perform a new clean server installation of Artifactory 1.3. It should not contains repositories data or your specific Artifactory configuration
xml file.
Execute . Please note that --username username --password password --import tmpExport #artadmin
the tool needs to be run with JDK 1.6. artadmin
The output will display the progress of the import. NOTE: If the process is killed the import will artadmin artadmin
Logon with admin/password and go to "Export & Import" page, then into the "Full System" panel.
Enter the export directory into the "System zip file or directory" field and click the "Import" button.
The import will run and may take some time to complete, depending on the size of your database.
Once the import process completes successfully you can switch to using Artifactory 1.3. You can switch back the port number if you did
so in step 6.
artdump command line usage:
artdump
--help : displays this usage message
--home [old Artifactory home] : mandatory - the home folder of the old
Artifactory
--dest [destination folder] : the destination folder for the new export
--version [version name] : the actual version of the old Artifactory if
--repo [repo names separated by ':'] : export only a specified list of
--norepo : does not export the repositories, just convert config and
security
--convert : activate the Local and Virtual repository names conversion
--noconvert : does not activate the Local and Virtual repository names
--security : only export the security file from DB, and set the norepo
flag
--caches : include cached repositories in the export (by default caches
The parameter --home is mandatory.
The Artifactory version will be extracted from
${artifactory.home}/webapps/artifactory.war if present
If the war file is not located there, please do one of the following:
1) Link or copy it into this location, or -
2) Pass one of the following version identifiers as second parameter:
1.2.2-rc0 1.2.2-rc1 1.2.2-rc2 1.2.2 1.2.5-rc0
1.2.5-rc1 1.2.5-rc2 1.2.5-rc3 1.2.5-rc4 1.2.5-rc5
1.2.5-rc6 1.2.5 1.2.5u1 1.3.0-beta-1 1.3.0-beta-2
The parameter is the old folder (the old Artifactory should not be running). If that folder also contains a --home $ARTIFACTORY_HOME w
subfolder with the old Artifactory war file, the update manager will automatically determine the old version from it. If the update ebapps
manager cannot determine a valid version an error message will appear with a list of valid versions and you'd need to manually specify
the version of your old Artifactory as a second parameter to . artdump
artadmin
--info : Display general system information about Artifactory
--import [import from path] : Activate full system import from a
designated path
--export [export to path] : Activate full system export to path
--server [the server host or ip] : The remote Artifactory server IP or
--ssl : Activate https instead of http. Default is false
--timeout [timeout in seconds] : Set the timeout of the HTTP connection.
--url [root url to rest api] : The root URL of the Artifactry REST API.
--username [username] : Optional username to use when connecting to the
remote Artifactory
--password [password] : The users's clear text password
--noMetadata : Exclude metadata information when importing/exporting
--symlinks : Use symbolic links to the original import path file (no file
copying)
--syncImport : Import directly into Artifactory without using the
--bypassFiltering : Avoid using exiting repository filtering rules during
the export process
--createArchive : Zip the resulting folder after the export (slow)
You need to specify one of the following parameters: --info, --import or
--export
When used with the option the import, process can perform much faster (usually by a factor of 3-5). Note that when using --symlinks
this option your imported path effectively becomes an integral part of Artifactory and you should not move/remove it until the background
import process has completed. This is indicated by the log message: Working copy commit done (0 files).
1.3.0-beta-4
Improved - support for multiple DNs, for non-anonymous binding against MS Active Directory and for sub-tree searches. #LDAP Support
connect).
1.
2.
3.
4.
5.
6.
The complete release notes are available here: http://issues.jfrog.org/jira/browse/RTFACT/fixforversion/10270
Enjoy
Installing
LDAP Support
General
Configuration
<security>
<anonAccessEnabled>false</anonAccessEnabled>
<ldapSettings>
<authenticationPatterns>

<userDnPattern>uid={0},ou=People</userDnPattern>

<searchFilter>sAMAccountName={0}</searchFilter>
<searchSubTree>true</searchSubTree>
</authenticationPatterns>
<managerDn>cn=ReadOnlyUser,ou=People,dc=jfrog,dc=org</managerDn>
<managerPassword>password</managerPassword>
</ldapSettings>
</security>
Where:
ldapUrl - Location of the ldap server in the form of: ldap://myserver:myport/dc=sampledomain,dc=com. It should include the base DN for
searching and/or authenticating users.
authenticationPatterns - A list of user DN patterns or search criteria used to find an authenticated user. Each authentication pattern
element will be tried until a user is found and authenticated. If no user is found or authentication failed, a BadCredentials exception will
be thrown.
authenticationPattern - An authentication pattern can include either a userDnPattern for "direct" authentication or searchFilter for user
"search" (after binding with a manager DN) and then authentication of the found user. The and are not managerDn managerPassword
used for "direct" DN authentication.
userDnPattern - A DN pattern that can used to directly login users to the LDAP database. This pattern is used for creating a DN string
for "direct" user authentication, where the pattern is relative to the base DN in the ldapUrl. The pattern argument {0} will be replace with
the username in runtime. This will work only if anonymous binding is allowed and a direct user DN can be used (which is not the default
case for Active Directory).
Example:
uid={0},ou=People
searchFilter - The filter expression used for searching a user. This is an LDAP search filter (as defined in 'RFC 2254' ) with faqs.org ietf
optional arguments. See the documentation for the method of for more search javax.naming.directory.DirContext
information. The search method will be called with as , a single containing the username, a searchBase name filterArg filterExpr
with this value and search affected by the value of . Authentication to LDAP will be done from the DN searchFilter cons searchSubTree
found.
}, for use with Active Directory, or sAMAccountName={0
}, for use with other LDAP servers. uid={0
searchBase - Context name to search in, relative to the base DN in the ldapUrl. This is parameter is optional.
searchSubTree - Flag to enable deep search through the sub tree of the ldapUrl + searchBase. True by default.
managerDn - Used only with "search" authentication method. It is the DN of the user who will bind to the LDAP server to perform the
search.
managerPassword - Used only with "search" authentication method. It is the password of the user who will bind to the LDAP server to
perform the search.
Upgrading from 1.3.0-beta-3 to 1.3.0-beta-4
Shutdown Artifactory and replace the war. If you are on Tomcat make sure the remove the expanded folder as well. webapps/artifactory
Upgrading from 1.2.2-rc0 through 1.3.0-beta-2 to 1.3.0-beta-4
Artifactory.
1.
2.
3.
4.
1.
2.
3.
4.
5.
6.
7.
a.
b.
a.
b.
c.
8.
process).
xml file.
so in step 6.
artdump
Artifactory
security
flag
If the war file is not located there, please do one of the following:
1) Link or copy it into this location, or -
2) Pass one of the following version identifiers as second parameter:
1.2.2-rc0 1.2.2-rc1 1.2.2-rc2 1.2.2 1.2.5-rc0
1.2.5-rc1 1.2.5-rc2 1.2.5-rc3 1.2.5-rc4 1.2.5-rc5
1.2.5-rc6 1.2.5 1.2.5u1 1.3.0-beta-1 1.3.0-beta-2
The parameter is the old folder (the old Artifactory should not be running). If that folder also contains a --home $ARTIFACTORY_HOME w
subfolder with the old Artifactory war file, the update manager will automatically determine the old version from it. If the update ebapps
artadmin
designated path
remote Artifactory
copying)
the export process
You need to specify one of the following parameters: --info, --import or
--export
1.3.0-beta-3
#LDAP Support!
connect).
The complete release notes are available here: http://issues.jfrog.org/jira/browse/RTFACT/fixforversion/10250
Enjoy
1.
2.
3.
4.
5.
6.
Installing
LDAP Support
General
Configuration
1.3.0-beta-3 has a bug that prevents deployment using the simple HTTP wagon when anonymous repository access is on. This bug is
fixed in 1.3.0-beta-4 ( ), and with beta-3 the workaround is to use the dav wagon for http://issues.jfrog.org/jira/browse/RTFACT-629
deployment, which is a simple change of the URL prefix ( ): dav:http:
<distributionManagement>
<repository>
<id>repo-id</id>

<url>dav:http://localhost:8081/artifactory/libs-releases-local</url>
</repository>
</distributionManagement>
1.
2.
3.
4.
1.
2.
3.
4.
5.
6.
7.
a.
b.
a.
b.
c.
8.
<security>
<ldapSettings>
<userDnPattern>uid={0}, ou=People</userDnPattern>
<managerDn></managerDn>
<managerPassword></managerPassword>
</ldapSettings>
</security>
Where:
ldapUrl - Url or the ldap server including the base DN to start searching for users.
userDnPattern - The pattern, relative to the base DN in the ldapUrl, which will be used to search for the user. The pattern argument {0}
will contain the username.
managerDn - User name to logon the ldap server if it requires authentication to search for users
managerPassword - Password to logon the ldap server if it requires authentication to search for users
Upgrading (from 1.2.2-rc0 through 1.3.0-beta-2) to 1.3.0-beta-3
Artifactory.
process).
xml file.
so in step 6.
artdump.sh
Artifactory
security
flag
If the war file is not located there, please do:
1.2.2-rc0 1.2.2-rc1 1.2.2-rc2 1.2.2 1.2.5-rc0
1.2.5-rc1 1.2.5-rc2 1.2.5-rc3 1.2.5-rc4 1.2.5-rc5
1.2.5-rc6 1.2.5 1.2.5u1 1.3.0-beta-1 1.3.0-beta-2
The parameter is the old folder (the old Artifactory should not be running). If that folder also contains a --home $ARTIFACTORY_HOME
webapps subfolder with the old Artifactory war file, the update manager will automatically determine the old version from it. If the update
During the import binary artifacts are copied over into a working copy and are imported into Arifactory in by a background thread. This
speeds up the import process dramatically and makes Artifactory ready for serving requests as soon as possible. The background
import process will take some time to completes, depending on the size of your repository. During this time Artifactory might perform
more slowly than usual, but it will still serve any artifact immediately. The log does provide visible information about the progress of this
process.
Should you wish to repeat the upgrade process from scratch, make sure to remove the folder from your $ARTIFACTORY_HOME/data
new Artifactory installation before doing so.
artadmin
designated path
remote Artifactory
copying)
the export process
You need to specify one of the following command parameters: --info,
--import or --export
Artifactory 2.1.1
We are pleased to announce the availability of Artifactory 2.1.1.
The major features and changes included in this release are:
General
New 'annotate' permission to control who can tag items with metadata
Support for copying artifacts between repositories
Servlet 2.4 compatibility restored (Artifactory can run again under Tomcat 5.5)
Fixed intermittent wrong content-length issues
Default proxy support (no need to manually assign a proxy for each remote repository)
Ability to run the datastore garbage collection manually (Admin:Advanced:Maintenance:Storage)
File system datastore for binaries now properly syncs changes to the search index
Add-ons
Watch events are now correctly emitted for move and copy operations
Properties can now be set on cached items
For a complete list of resolved issues in this version please see the . JIRA
Instructions for simple upgrade from previous versions can be found . here
The latest Artifactory user guide is available . here
Artifactory 2.1.1 is available for immediate download from or directly from . JFrog's web site SourceForge
Enjoy!
The Artifactory Team @ JFrog
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Artifactory 2.2.4
We are pleased to announce the availability of Artifactory 2.2.4!
This release contains important improvements to Artifactory OSS and the Artifactory Pro Power Pack, as well as important maintenance bug
fixes.
Notable improvements and changes in this version are:
Performance Improvements - Lower memory footprint, better overall memory management and better JVM and storage defaults for
the OOTB installation.
Folder & Repository Replication REST API - Rsync-like replication of a remote repository or remote repository folder between two
Artifactory servers. See: 'Folder Synchronization/Replication' under the (requires Artifactory Pro). REST API documentation
Build Promotion REST API - Promote (copy/move) a CI server build published artifacts with or without dependencies from selected
scopes - all via REST. See: 'Build Promotion' under the (requires Artifactory Pro). REST API documentation
Support for Multiple LDAP Servers - Configure authentication and/or group authorization against multiple LDAP instances (requires
Artifactory Pro).
Extended Support for CI server Build Integration - supports non-numeric build numbers and better link-back to Build info integration
the CI server.
Improved Code Highlighting - Better support for Gradle scripts and JavaFx code.
Better Support for Standalone Artifactory Behind Apache - Improved request handling when running Artifactory on standalone Jetty
behind Apache.
New System Info Page - For tracking and serving as a convenient source of information when reporting issues. system resources
Improved Backups - User-edited files such as artifactory system properties and the mime types are now also part of a system backup.
Bookmarkable Tree Browser - Artifact tree nodes are fully bookmarkable and can be shared as links (copy the link from the General
tab when a node is selected).
'Chroot' Support for UI Browsing - Ability to run Artifactory with a limiting browsing the server file system from 'chrooted' UI browsing
the UI (e.g. for import/export) to a specified root path.
Instructions for upgrading to 2.2.4 from previous versions can be found . here
Enjoy Artifactory!
Artifactory 2.2.5
This is a maintenance release for 2.2.4, containing bug fixes and small improvements.
Some changes in this version are:
Selective scopes (or 'configurations' for Ivy) when saving Build Info artifacts/dependencies as a search result (requires the Pro Power
Pack).
REST API now accepts 'application/json' as content-type from clients when the return type is a json object with a more concerete json
sub-type.
Fixed a security issue with blank LDAP passwords and SunOne LDAP server.
Support for manually clearing bad checksums from the UI.
Instructions for upgrading from previous versions can be found . here
Enjoy Artifactory!
Artifactory 2.3.3
Notable new features and changes in this version are:
Artifactory Pro Power Pack 2.2.4 Free Evaluation is available for immediate download.
The Artifactory OSS 2.2.4 is available from or directly from . JFrog's web site SourceForge
1.
2.
3.
4.
5.
6.
7.
8.
9.
1.
2.
3.
4.
5.
6.
7.
Repository Replication - Rsync-like mirroring of your repository content and metadata from/to remote Artifactory repositories using pull
and push (coming soon) replication (requires Artifactory Pro)
Release Staging and Promotion Support - Works in conjunction with the new release management features in the Jenkins Artifactory
plugin. Similar support is coming to TeamCity and Bamboo (some features require Artifactory Pro)
Filtered Resources - Provision dynamic settings and configuration resources to clients. For example, provision different content base
on the user originating IP address, or based on changing property values attached to the requested artifact (requires Artifactory Pro)
S3 Remote Browsing - Browse remote repositories hosted on Amazon S3
Isolated Resolution Support for Snapshot Build Chains - When running parallel integration build chains in Jenkins, Artifactory will
return for each builds only dependencies that were produced as part of its build chain. Similar support is coming to TeamCity and
Bamboo (requires Artifactory Pro)
SSO by any HTTP Header - The HTTP-SSO add-on now also supports authentication to Artifactory based on any trusted HTTP header
RPM Distribution - Artifactory can now be installed from an RPM on any RPM-supporting OS
Bad Jars Protection - Avoid filling up your repository with bad jars. For example, when running behind a captive portal
Many bug fixes and improvements
Enjoy Artifactory!
Artifactory 2.3.4
Notable new features and changes in this version are:
Push Repository Replication - Push repository replication completes the existing pull replication feature. You can now push content
and metadata to remote Artifactory repositories on servers you are only allowed to make outgoing connections to (requires Artifactory
Pro)
Jar Entry Download - Access and download archive content directly via HTTP GET. This enables, for example, reading javadocs
documents directly from their Artifactory hosted jars (requires Artifactory Pro)
Search API for Plugins - Groovy plugins can now perform searches in Artifactory (requires Artifactory Pro)
Improved REST API - Item effective permissions, find builds using a dependency, artifacts with bad checksums search, etc.
Test Remote Repository - Verify you can successfully connect to a remote repository you have created
Compatible with the features of the upcoming version of the and the Release Management TeamCity Artifactory Plug-in Bamboo
Artifactory Plug-in
Bug fixes and many small improvements
Enjoy Artifactory!
Artifactory 2.3.4.1
We are pleased to announce the availability of Artifactory 2.3.4.1!
This version of Artifactory adds Java 7 compatibility to Artifactory!
Artifactory Pro 2.3.3 free trial is available for . immediate download
Disabling HotSpot Loop Optimizations
Due to critical Hotspot bugs in the first Java 7 release(s) ( , & ), it is to run 7070134 7044738 7068051 HIGHLY RECOMMENDED
Artifactory with the following Hotspot flag in order to avoid JVM crashes and/or Lucene index corruption:
-XX:-UseLoopPredicate
Instructions for upgrading to 2.3.4.1 from previous versions can be found . here
Please Note: Due to a minor bug, the artifactory.log file may contain the following warning after upgrading Artifactory to 2.3.4.1. You can safely
ignore this warning.
[art-init] [WARN ] (o.a.v.ArtifactoryVersionReader:102) - Version 2.3.4.1 is not an
official release version. The closest revision to 13021 will be used to determine the
current version.
Enjoy Artifactory!
Artifactory 2.1.2
We are pleased to announce the availability of Artifactory 2.1.2.
Major features and changes in this release:
General
Initial Ivy support - Preview Ivy modules and Ivy dependency declaration, XPath search in ivy.xml files, auto-guess Ivy modules
properties when uploading ivy.xml files from the UI
Sharing of remote repository definitions - You can import and reuse remote repository definitions exposed by other Artifactory instances
(new Import button in ) Admin:Repositories:Remote Repositories
Optimized binaries storage - Including configurable blobs caching and support for storing binaries as regular files (instead of as database
blobs)
Browser compatibility fixes
Add-ons
Exporting search results - Saved search results can now be exported to disk
Enjoy!
Artifactory 2.1.3
The major features and changes in this release are:
Hudson integration - Use the to deploy builds to Artifactory from Hudson together with build-time information: Hudson Artifactory Plugin
View builds in Artifactory with information about the deployed artifacts and dependencies (all scopes) and runtime environment per build,
and link back to Hudson to obtain fully-reproducible builds.
Via paid add-on: Visual artifact/dependency views per build; Promote or export all build artifacts and dependencies; See where specific
artifacts are used and receive warnings when required build dependencies are removed .
Automatic cleanup of remote repositories declared in POMs - A virtual repository can now be configured to auto- clean up rogue
remote repositories declared in POM files, causing dependency resolution issues.
Logo branding - Customize your Artifactory UI with your own logo (uploaded or URL linked) and footer
Ivy dependencies for POMs - Copy Ivy dependency declarations from the POM view.
Generic artifact deployment support - Improved upload screen with ability to deploy artifacts to any path without Maven's layout
Using this flag may not be necessary in future Java 7 releases.
Artifactory Pro 2.3.4.1 free trial is available for . immediate download
The Artifactory OSS 2.3.4.1 is available from or directly from . JFrog's web site SourceForge
1.
2.
3.
4.
5.
6.
1.
2.
constraints.
Include/exclude patterns on virtual repositories - This extra level of control supersedes the pattens define on sub-repositories.
Limit search to specific repositories
Faster searches
Enjoy!
Artifactory 2.2.0
We are pleased to announce the availability of Artifactory 2.2!
This forth major release of Artifactory is focused around significant performance improvements, resource usage optimizations, and bug fixes.
Please see important for this version. update notes
This release also brings a couple of new important features to Artifactory:
Open REST API - Artifactory's RESTful resources are now public and documented. Using the or the REST documentation
auto-generated WADL file, Artifactory can be controlled and automated from external tools or frameworks.
Enterprise-grade LDAP Groups Synchronization - this new lets you manage permissions in based on you Power Pack add-on
existing LDAP groups. It offers fast caching of LDAP data (which is a must for an organization with hundreds or thousands of users),
flexible group synchronization strategies, multiple settings, and tight integration and feedback about LDAP users and groups throughout
all security-related management screens in Artifactory.
Support for running Artifactory under . GlassFish 3
Support for of the same remote resource. queueing concurrent downloads
Ability to with administrative comments. annotate repositories
Improved . UI branding
The LDAP Groups add-on joins the existing set of commercial add-ons, that complete the Artifactory professional Artifactory Power Pack
offering. You might find the following helpful for comparing the open source version to the add-ons version. comparison table
Artifactory 2.2 is available for immediate download from or directly from . JFrog's web site SourceForge
Instructions for upgrading to 2.2 from previous versions can be found . here
Enjoy Artifactory!
Artifactory 2.2.1
This is a maintenance bug fixes release for 2.2.0.
Enjoy Artifactory!
Artifactory 2.2.2
This is a maintenance release for 2.2.1 that also adds a couple of new noticeable features to Artifactory:
Checksum Validation for Uploaded Artifacts - Local repositories can now be assigned with a custom policy for validating the
checksum of artifacts uploaded by client. You can tell Artifactory not to serve an artifact (return 404) until its checksum has been verified
against the client's checksum.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
1.
2.
3.
4.
5.
Queueing Concurrent Downloads of Same Remote Resource - Artifactory will avoid bursts of concurrent downloads requests for the
same remote resource and will queue all requests except the first one to avoid download overwriting, timeouts and bandwidth
exhausting.
Move/Copy via REST API - Allowing arbitrary move/copy automation between paths and repositories, including metadata move/copy
(requires the Artifactory Power Pack).
Trigger Download REST API - Automate a remote artifact download with or without getting the content back to the client (requires the
Artifactory Power Pack).
Property-based Download - Request an artifact for download based on the existence of certain property value on it, including support
for mandatory/non-mandatory values.
Metdata Proxying - Ability to proxy remote artifacts with their metadata.
System-wide Syntax Coloring Support - For XML, Java, Groovy files etc.
Jar/Zip Content Browsing - In tree-view you can drill down into Jars and view files, sources and the Manifest content.
View Java Source from Class - Ability to view the source of classes returned in search results or when browsing a Jar class that has a
matching sources Jar in Artifactory.
Better View of Dependent Build Artifacts - Faster and uses less memory (requires the Artifactory Power Pack).
Hide Repository in Tree Browse - For users with no read permissions on any path in the repository.
Enjoy Artifactory!
Artifactory 2.2.3
This is a maintenance release for 2.2.2, containing bug fixes and small improvements.
Notable changes in this version are:
Fixed a problem with trusted server checksums, leading to checksum errors.
Fixed a regression with Maven metadata not being merged correctly for virtual repositories.
Mime types are now configurable, allowing more file types to be viewed with syntax highlighting (requires index rebuilding).
Source of class files can be viewed not only when the sources jar is available but also when sources are contained within the same jar.
Enjoy Artifactory!
Artifactory 2.3.0
This release contains new features and improvements to Artifactory OSS and Artifactory Pro Power Pack, as well as important maintenance bug
fixes and performance improvements.
Notable new features in this version are:
License Control Add-on - A new Pro add-on that enables you to take full control over the licenses that are used by your third-party
dependencies, as part of your builds. You can get immediate notifications about any libraries that violate your organization's license
policy, so you can deal with licensing issues early on during development.
This add-on integrates with Maven, Gradle and Ivy builds using the latest version of the Artifactory plugins for: , Hudson JetBrains'
and . TeamCity Atlassian's Bamboo
Watch for a demo of License Control in action. this screencast
User Plugins - You can now extend Artifactory Pro with your own custom Groovy plugins. Using plugins you can schedule tasks, deploy
artifacts, change resolution rules and download content, tend to any storage events etc. Plugin source files are redeployed on the fly
during development, and can be edited and debugged in your favorite IDE.
Atlassian Crowd Integration - Delegate authentication request to a Crowd server and get transparent SSO in a Crowd-enabled SSO
environment (requires Pro).
Repository List Browsing - A new lightweight browsing mode that resembles simple directory listing used by web servers. List
browsing uses a unique URL prefix, which allows you to restrict public access only to it in a front-end web server.
5.
6.
7.
1.
2.
3.
4.
1.
2.
3.
4.
5.
6.
7.
8.
Repository Admin via REST - A new API that enables creating, updating and deleting all repository types via REST (requires Pro).
Automatic and Client Settings Gradle Ivy - Generate Ivy and Gradle setting for resolution and deployment directly from the UI (to
complete the Maven settings generator).
Tomcat 7 Compatibility - Artifactory is now compatible with Tomcat 7.
Enjoy Artifactory!
Artifactory 2.3.1
Notable features and changes in this version are:
License Control Improvements - Many improvements and small bug fixes mainly around third-party license violation notifications.
You will need to upgrade the to the latest version in order to take advantage of some of the Note: Artifactory plugin for your CI server
improvements (disabling scanning own artifacts, scope selection etc.).
Execute Plugin via REST - and extension point to execute any user code via REST. New REST API plugin
Richer access.log - More administrative actions and configuration changes are now reported in the file. access.log
Gzip-encoded response - Responses using gzip compression are now supported (typically returned by proxies not taking the Accept-
header into account). Encoding
Enjoy Artifactory!
Artifactory 2.3.2
Notable features and changes in this version are:
Remote Repository Browsing - Browse the content of remote folders, not yet cached locally. This also allows Ivy resolvers to take into
account remote versions when using version ranges.
Crowd Groups Integration - Sync your Atlassian Crowd groups to Artifactory and manage groups permissions on those groups
(requires Artifactory Pro).
Pluggable Authentication Realms - super-easy login integration with any external system using a new Groovy extension point in User
(requires Artifactory Pro). Plugins
Non-Maven Repository Layouts - Define the layout by which modules are identified in your repositories to achieve smart module
management in non-Maven repositories, including: automatic cleanup of integration artifacts, cross-repository layout conversion
(remote--local/cache--virtual), module metadata searches etc.
Robust WebDAV Mounts - Ability to mount any local repository or cache as a secure WebDAV share for direct browsing from your
native O/S file manager.
Automatic Cleanup of Old Builds - Use the retention defined by your CI server for cleaning up old builds, when using the Artifactory B
(requires Artifactory Pro). uild Integration
Improved Memory Consumption - Substantially improved memory utilization.
Over 90 bug fixes and improvements.
Artifactory Pro 2.3 free trial is available for . immediate download
The Artifactory OSS 2.3 is available from or directly from . JFrog's web site SourceForge
1.
2.
3.
4.
5.
6.
7.
1.
2.
3.
1.
2.
3.
4.
Enjoy Artifactory!
Artifactory 2.4.0
What's New in this Release
This major release of Artifactory introduces the following new features and changes:
YUM Repositories and RPM Provisioning - Artifactory can now act as a fully-featured YUM repository, including auto-updating repo
metadata and RPM detailed view directly from the Artifactory UI.
P2 Repositories - Artifactory can be your single access point for all Eclipse updates. Eclipse plugins proxying and hosting take
advantage of Artifactory's exiting advanced caching and security controls.
Major Performance Improvements - in storage management, CPU and memory utilization and search speeds
Security is Fully Manageable via REST API
User Regexp Tokens in Repository Layouts - You can now add your own custom regexp-based tokens to repository layout definitions
for better module identification.
New additions to the for (move, copy, search, not downloaded since, etc.) Artifactory Public API User Plugins
Usability improvements and many bug fixes
Before Upgrading - Important, Please Read This
Plan for an Upgrade Downtime - This major release involves storage-related changes, so while the upgrade process itself
automatically runs from start to finish (as always), it will take some time for it to complete.
The time between starting up Artifactory after upgrading and having it ready to serve requests can vary, depending of the size of your
repository, but it is compared to previous updates. considerably longer
. It is important that you run this upgrade while taking downtime into account
Java 6 is Required - Artifactory no longer runs on Java 5 and now requires Java 6. This enables us to improve the Artifactory codebase
and use up-to-date dependencies that require Java 6.
XML Search is Disabled by Default - XML context indexing (and thus, searching) incurs some performance overhead and has been
made optional.
If you'd like to keep using this feature you will need to opt-in and enable XML searches. It is important that you do this before upgrading
Artifactory, since newly created XMLs will not be indexed until XML indexing is enabled. Please see the details on how to do this on the
. XML Search page
Enjoy Artifactory!
Artifactory 2.4.1
This is a bug-fix minor release. Important issues addressed in this release are:
Non-unique snapshots are again updatable with 'deploy' permission (a regression caused 'delete' permission to be required)
Fixed potentially wrong checksums after upgrading to Artifactory 2.4.0
WebLogic 10.3 compatibility
Support for remote browsing of repositories that return a gzip-compressed response
Important! Before upgrading from 2.3.x or earlier
Please make sure to read the 'Before Upgrading' section in the for important information about Artifactory 2.4.0 release notes
upgrading from 2.3.x to 2.4.x.
1.
2.
3.
1.
2.
1.
2.
3.
4.
5.
Enjoy Artifactory!
Artifactory 2.4.2
Important issues addressed in this release are:
New REST API to allow tracking of replication status
Unlimited results for searches run from Artifactory plugins
Fixed a regression with Maven metadata expiry
Enjoy Artifactory!
Artifactory 2.5.0
We are pleased to announce the availability of Artifactory 2.5. Now with NuGet Support!
Important issues addressed in this release are:
NuGet Support - Artifactory has across-the-board support for NuGet. This means that .Net developers can now use the full power of
Artifactory's advanced artifact management to host, proxy and aggregate NuGet packages (via local, remote and virtual repos,
respectively) and pull libraries from Artifactory into Visual Studio projects.
A slew of bug fixes and small improvements.
Enjoy Artifactory!
Artifactory 2.5.1
Important improvements and fixes included in this minor release are:
Maven indexer can now be triggered based on a cron expression
All zip-compatible archives can now be searched (previously was limited to jars)
New tab displaying NuGet package information (extracted from its embedded nuspec file)
Replication no longer aborts on failure to replicate a single artifact
Fixed empty response when list-browsing repositories with a short name
1.
2.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Enjoy Artifactory!
Artifactory 2.5.1.1
We are pleased to announce the availability of Artifactory 2.5.1.1!
This minor release affects . Itaddresses a critical that caused proxying of the to stop working. .Net clients bug NuGet Gallery
Instructions for upgrading to 2.5.1.1 from previous versions can be found . here
Enjoy Artifactory!
Artifactory 2.5.2
We are pleased to announce the availability of Artifactory 2.5.2
This minor release addresses an important security that may allow an attackerto run a cross-site scripting attack by uploading vulnerability
malicious content to Artifactory.
All users are urged to upgrade to this version.
Other important issues addressed in this release:
YUM metadata is now correctly calculated for repositories hosted in subdirectories.
RPM installer now works correctly on SUSE.
For a complete list of resolved issues please see the . JIRA release notes
Enjoy Artifactory!
Artifactory 2.6.0
Important new features and changes in this version:
Download debugging - solve artifact resolution issues by getting detailed explain plan of the download request handling in your
browser.
Latest Maven snapshot download - it is now possible to download the latest version of a Maven snapshot via a simple non-unique
snapshot URL.(Pro)
Latest version REST- Artifactory can return the latest release or integrationversion of an artifact for any repository layout.(Pro)
Artifact versions REST - get all the release and/or integrationversions of an artifact for any repository layout.(Pro)
Improved replication - replication was optimized in terms of speed and overall resource consumption. Replication now uses streaming
and elimination (Pro) duplicate target checksum
Auto offline for remote repositories- a remote repository will now be auto put into temporal offline when encountering retrieval errors.
Before/After Build callbacks - tend to build publishing events in , including the ability to modify the build info object (e.g. user plugins
add new artifacts).(Pro)
Cron-based artifact cleanup - auto artifact cleanup can now be triggered by cron instead of using a time interval.
Custom artifact promotion- it is now possible to code custom artifact promotion logic, including interacting with builds, directly inuser
. Promotion logic can be executed via REST or via .(Pro) plugins CI integration
AfterDownloadError callback- tend to download errors in .(Pro) user plugins
Secure plugin executions - REST execution points in can be secured byspecifyingallowed users and/or groups.(Pro) user plugins
Per repository archive browsing- ability to turn on archive browsing for selected trusted repositories.
Many bug fixes and improvements
Artifactory Pro 2.5.1.1 free trial is available for . immediate download
The Artifactory OSS 2.5.1.1 is available from or directly from . JFrog's web site SourceForge
1.
2.
3.
4.
5.
1.
2.
3.
4.
5.
1.
2.
3.
Enjoy Artifactory!
Artifactory 2.6.1
Important features and changes in this version:
-GAVC and Quick Search performanceand resource consumption Faster GAVC search and quick search have been greatly
improved
Local replication fixed regression
L download now resolves much faster atest maven snapshot
Resolution repositories are now returned to Artifactory CI plugins correctly
Minor bug fixes and improvements
Enjoy Artifactory!
Artifactory 2.6.2
Event based replication -Replication now supports continuous, event-based mirroring that allows you to achieve near real-time push
synchronization between repositories. Combined with scheduled replication, repositories areguaranteed to always be consistently in
sync even when one of the replication sides becomes unavailable.
Integration Improved P2 - P2 support has been extended with more straight-forward hosting of your own P2 repositories, better
composite resolution, and and easieraggregationof local and remote P2 repositories under a single virtual repository URL.
NuGet 2.0- Artifactory is now up-to-speed with all the changes introduced by the recently released . NuGet 2.0
Consistent path handling - URL and path logic handling has been rewritten to support across-the-board correct handling of special
. character encoding
Enjoy Artifactory!
Artifactory 2.6.3
Deploy artifacts from archive - Added REST and UI support for batch-deployment of multiple artifacts contained in an uploaded
archive, in a single HTTP transaction. Currently supported archive types: zip; tar; tar.gz; and tgz.
NuGet 2.0 packagesupdateis now working in Visual Studio.
1.
2.
1.
2.
3.
4.
5.
6.
7.
1.
2.
3.
4.
Enjoy Artifactory!
Artifactory 2.6.4
Storage quota management
Bug fixes and improvements
Enjoy Artifactory!
Artifactory 2.6.5
Build Diffs: Visually compare the differences between two build runs for changes in artifacts, dependencies and environment variables
YUM Improvements: Support for YUM groups andand more efficient calculation of YUM metadata
Build Artifacts Archive: Retrieve an archive file containing all the artifacts related to a specific build
Build Artifacts Search: Find all the artifacts related to a specific build
Maven Latest Release Download: Latest release artifact query now also works for Maven-layout repositories
Configurable Request Parameters: Add custom query params to remote repository requests; This is useful, for example, when
needing to add an authentication token param, such as the one required by Maven Central SSL access.
Bug fixes and performance improvements
Enjoy Artifactory!
Artifactory 2.6.6
: Per-file License Discovery You can now manually trigger a license scan per-artifact from the tree browser. This allows you to
auto-attach license information to artifacts outside the context of a CI build.
: SAML SSO Support Login to the Artifactory UI can now be integrated with any SAML IdP (Identity Provider). Artifactory now acts as a
SAML Service Provider.
: Bintray Integration Freely distribute your release artifacts and share them with the world via the service (currently in Beta). Bintray
You can upload individual binaries or build artifacts to Bintray directly from Artifactory.
4.
5.
6.
7.
: Build Diff REST Compare two builds for their published artifacts, used dependencies and environment using the REST API.
: Running Plugin Code as System It is now possible to execute selected plugin code blocks under an unrestricted system role, by using
the ' ' closure. asSystem{}
: Property Events in Plugins New storage callbacks are available that allow plugin developers to intercept property change events.
Bug fixes and performance improvements
Enjoy Artifactory!
Artifactory 2.6.7
This minor release addresses few a critical s and . bug security improvement
Enjoy Artifactory!
Artifactory 3.0.0
We are excited to announce the major release of Artifactory 3!
21 April 2013
JFrog announces the release of the third major version of its flagship product, Artifactory, The Binaries Repository Manager. This release
delivers a huge performance boost and a fresh user interface.
Four years following Artifactory 2, the Artifactory 3 major release is available to all users (Open-source, Pro and SaaS versions).
Major Performance Boost
All the common usage scenarios such as checksum-based storage, binaries promotion, mirroring, repository management and remote proxying
have been optimized for speed. Depending on a particular usage scenario Artifactory 3 performs x10 to x100 times faster than Artifactory 2.x! On
top of that, Artifactory 3 also has a considerably lower memory footprint.
We have reimplemented from scratch the underlying metadata storage (retiring Jackrabbit, which has served us well for the last 4 years). With
this change, Artifactory utilizes SQL and relational databases in a unique way, significantly improving CI build performance over competitors and
previous versions of Artifactory.
User Interface Changes
The user interface has also undergone a facelift, providing a bright, clean and uncluttered display for users.
Black Duck Code Center Integration
In addition, the Artifactory 3 now supports BlackDuck Code-Center integration for open source license governance and vulnerability control.
Remote Searches with Bintray Integration
Artifactory users can now search for remote artifacts and get information about latest OSS releases from Bintray.com.
1.
2.
3.
4.
5.
User Tomcat 7 as the Default Container
Further, default distribution uses Tomcat 7 with both the RPM and the standalone versions of Artifactory.
System Requirements
Artifactory 3.0 requires Java 7
Supported Databases
Derby (embedded - zero configuration)
Oracle version 10g and above
MySQL with InnoDB version 5.5 and above
Microsoft SQL Server 2008 and above
Removed / Obsolete
We have discontinued support for XML Metadata, including related user plugin methods and REST API
XML XPath search
Sync resource REST API
Installation and Upgrade Instructions
For detailed installation instructions please refer to our user guide
Upgrading from 2.x versions requires only a simple process of exporting and then importing the current repository data.
For detailed upgrade instructions please refer to our upgrade guide
Changes
For a complete list of bug fixes and improvements in this version please see the JIRA Release Notes
Enjoy Artifactory!
JFrog Artifactory Team
Artifactory 3.0.1
This release includes minor improvements to the installation and several bug fixes. Notable issues addressed by this version:
NuGet 2.5 support
Improved performance Bintray info panel
HTML Content browsing also supported for files outside of an archive
Fixed failure in archive indexing with duplicate (case insensitive) entries
Preventing duplicate permission target entries
Additional info about Artifactory 3 can be found . here
Enjoy Artifactory!
Artifactory 3.0.2
The Artifactory OSS 3.0.1 is available from or directly from JFrog's web site Bintray.
1.
2.
3.
4.
5.
6.
7.
07 July 2013
This release brings back support for PostgreSQL database and includes several bug fixes and improvements. Notable issues addressed by this
version:
PostgreSQL support
YUM repository improvements and bug fixes
Users can header using a custom property override the response Content-Type
Artifacts count and storage size added to the public API user plugins
Simple patterns can be used inlatest version search
Force REST API maven metadata recalculation
Improvements and bug fixesaround storage GC
Additional info about Artifactory 3 can be found . here
To get automatic notification for new releases of Artifactory you can watch Artifactory on . Bintray
Enjoy Artifactory!
The Artifactory OSS 3.0.2 is available from or directly from JFrog's web site Bintray.

Artifactory User Guide 3.0.2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Artifactory User Guide 3.0.2

Uploaded by

Copyright:

Available Formats

Artifactory

NOTE! In order to change the defualt storage follow this . link

Running Behind Apache HTTPd

Running Behind nginx

Changing the Default Storage

Running Artifactory on MySQL

When Running the Artifactory WAR in a Servlet Container

Installation and Definition - Physical and Database

Field Name Description

Path-mapping occurs if the remote layout is different to the local

Importing Shared Configurations

Centrally Secure Passwords

Field Name Description

Deploying via the Web UI

Make Sure You Have Sufficient Permissions

Request ID: 51c808f6

Retrieve Plugin Info Of A Certain Type

Inspecting and Managing Builds

2.1.5 (07 Jul 2013)

Bamboo Artifactory Plug-in

During the release the plugin performs the following:

The license found is not an approved license

Grouping and Sorting

Synchronizing LDAP Groups with Artifactory

Watch the Screencast

altResponse On any download Provide an alternative response,

beforeRemoteDownload Before fetching content from

... someOtherCode ...

Viewing Individual RPM Information

Integration with Tycho Plugins

3. Under the tab, selectEnable RubyGems Support Packages

Setting up local RubyGems repository

Setting up a virtual RubyGems repository

Moreover, the following REST API are also available:

Field Description Example Mandatory

To enable Crowd integration:

Field Name Description

Understanding Artifactory's SAML-based SSO Login Process

Figure (3) Artifactorys SAML-based SSO logout process.

The panel appears under the following conditions:

Entering your Bintray credentials

You might also like