Artifactory User Guide.

Artifactory User Guide
Table of Content
1. Artifactory User Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Installing Artifactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.2 OS Service or Standalone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.2.1 Installing on Un*x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.2.2 Installing on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.3 RPM Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.4 Deployment on Other Servlet Containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.4.1 Deploying the WAR File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.4.2 Dedicated Tomcat Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.4.3 Deploying on JBoss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.4.4 Deploying on IBM Websphere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.5 Running Behind Apache HTTPd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.6 Changing the Default Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.6.1 Running Artifactory on MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.7 Upgrading Artifactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.7.1 Intermmediate Upgrade to Previous Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Administering Artifactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 General Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2 Managing Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2.1 Understanding Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2.2 Configuring Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2.3 Local and Remote Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2.4 Local Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2.5 Remote Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2.5.1 Managing Caches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2.5.2 Handling Offline Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2.5.3 Handling Checksums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2.5.4 Going Through Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2.5.5 Advanced Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2.5.6 Importing Shared Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2.6 Virtual Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3 Managing Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3.1 Managing Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3.1.1 Recreating the Default Admin Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3.2 Managing Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3.3 Managing Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3.4 Managing Security with LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3.5 Centrally Secure Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3.6 Access Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.4 Managing Backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.5 Importing and Exporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.6 Mail Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.7 Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.7.1 Global Configuration Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.7.2 Security Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.7.3 System Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.8 Exposing Maven Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.9 The artadmin Command Line Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.10 Clustering Artifactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.11 The Artifactory Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.12 System Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Working with Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.1 Configuring Artifacts Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.2 Configuring Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Working with Gradle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.1 Gradle Artifactory Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.1.1 Gradle Artifactory Plugin using the snapshot version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5 Working with Ivy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6 Using Artifactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.1 Browsing Artifactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.2 Attaching and Reading Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.3 Deploying Via the Web UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.4 Searching Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.4.1 Quick Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.4.2 Class Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.4.3 POM and XML Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.4.4 Property Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.4.5 GAVC Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.4.6 Checksum Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.5 Manipulating Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.5.1 Removing Single Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.5.2 Cleaning-up Complete Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4 4 5 5 6 7 8 8 9 10 10 10 13 15 16 17 19 19 21 21 23 24 24 26 26 28 29 30 31 33 34 36 37 38 39 40 43 45 47 47 49 53 53 54 55 57 57 58 60 61 62 62 63 65 66 69 73 74 78 78 82 84 86 86 87 87 88 89 90 90 90 91
1.6.5.3 Moving Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.6 Updating Your Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.7 Artifactory's REST API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.7.1 Repository Configuration JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.7.2 Security Configuration JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.7.3 System Settings JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7 Artifactory Pro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.1 Installing the Artifactory Pro Power Pack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.2 Artifactory Version Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.3 Build Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.3.1 Jenkins (Hudson) Artifactory Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.3.2 TeamCity Artifactory Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.3.2.1 TeamCity Artifactory Plugin - Release Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.3.3 Bamboo Artifactory Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.3.3.1 Bamboo Artifactory Plugin - Release Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.4 License Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.5 LDAP Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.6 Repository Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.7 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.7.1 Using Properties in Deployment and Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.8 User Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.9 YUM Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.10 P2 Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.11 NuGet Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.12 Repository Layouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.13 Smart Searches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.14 Atlassian Crowd Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.15 Single Sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.16 Filtered Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.17 Watches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.18 WebStart and Jar Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.8 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.8.1 Dealing with Broken Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91 92 93 128 129 130 131 132 133 135 142 143 152 158 163 170 174 176 178 179 181 200 202 205 208 217 217 219 220 222 223 223 223
Artifactory User Guide
Welcome to the Artifactory User Guide!

Please use the left navigation bar to find your way around the Artifactory docs.
This user guide is for Artifactory 2.1.x and higher. The previous 2.0 user guide can be found here.
Installing Artifactory
Before you install, please check the system requirements and supported platforms. Artifactory can be installed and run in a couple of ways: 1. On the bundled Jetty container as a standalone server, or as Unix or Windows service 2. Using the RPM distribution, which sets up Artifactory as a service on a bundled Tomcat container - recommended. 3. On other servlet containers as a standard WAR weapp - Tomcat 6 or 7 is recommended. You can also configure Artifactory to run on top of various storage options, for greater performance and ease of maintenance.
Requirements
JDK
You can run Artifactory with JDK 1.6 and above, but we strongly recommend using the latest JDK 1.6 update, preferably JDK 1.6 update 23 and above. When running with JDK 1.6 you wll need JDK version 1.6.04 and above (ealier versions of JDK 1.6 are bundled with a JAXB version which is incompatible with the version used in Artifactory). At least 300MB of allocated Java heap space is recommended, though you should be able to run with less RAM. If you can reserve 1g or more for Artifactory JVM, the recommended JVM option parameters are:
Copyright 2012 JFrog Ltd.
-server -Xms1g -Xmx1g -Xss256k -XX:PermSize=128m -XX:MaxPermSize=128m -XX:SurvivorRatio=8 -XX:NewSize=512m -XX:MaxNewSize=512m -XX:+UseConcMarkSweepGC
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 that support JDK 1.5 and above, though we haven't tested them.
Browsers
Artifactory has been tested with Firefox 2.0, Firefox 3.0, Internet Explorer 6, Internet Explorer 7, Safari 3.2 and Google Chrome 1.0.
OS Service or Standalone
Before installing Artifactory on the bundled standalone Jetty server make sure you have set the JAVA_HOME environment variable to point to a valid JDK 1.5+ home. Then, follow these instructions for installing the standalone version under Windows or Unix.
After successfully installing Artifactory, it should be available locally at: http://localhost:8081/artifactory.
Installing on Un*x
Unix
When using Unix, it is possible to install Artifactory as a Unix service or run it manually. Before you install is recommended you first verify your current environment by running artifactoryctl check under the $ARTIFACTORY_HOME/bin folder (this script is, in fact, a customized Jetty init script).
Installing Artifactory as Linux Service

Introduction
Artifactory is packaged with a complete install script that can be used to install it as a Unix service running under a custom user and using the standard Unix directories.
Installing
To setup Artifactory correctly as a Linux service run, as root, the $ARTIFACTORY_HOME/bin/install.sh script. Here is the main information about what this script is doing: User creation Creates a user named "artifactory" ($ARTIFACTORY_USER) by default. You can change the default user by editing the $ARTIFACTORY_USER value in /etc/artifactory/default. The install script accepts the user name as its first and only parameter. Creates the folder /etc/artifactory, copies the configuration files there and creates a soft link in $ARTIFACTORY_HOME/etc
etc config etc default
Creates the file /etc/artifactory/default that contains the main environment variables needed for artifactory to run: JAVA_HOME, ARTIFACTORY_USER, ARTIFACTORY_HOME, JAVA_OPTIONS,... The /etc/artifactory/default is included at the top of artifactoryctl and so can include whatever you wish. NOTE: The default max memory is 1GB It copies the file artifactoryctl to /etc/init.d/artifactory
init.d
Logs folder Backup folder
Creates /var/log/artifactory folder, makes it writable for the user ARTIFACTORY_USER and creates a soft link $ARTIFACTORY_HOME/logs. Creates the folder $ARTIFACTORY_HOME/backup, so you will need to create a link if you wish this folder to point to somewhere else (like /var/backup/artifactory for example). The script makes $ARTIFACTORY_HOME/backup writable for the user ARTIFACTORY_USER. Create the folder $ARTIFACTORY_HOME/data, so you will need to create a link if you wish this folder to point to somewhere else. The script will make it writable for the user ARTIFACTORY_USER. The script calls add, list (you can see the output), then activate the Artifactory service
Data folder chkconfig calls
After running the script successfully you can test the installation by running: service artifactory check or /etc/init.d/artifactory check And if everything is OK, 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
Normally Artifactory will be started as root (when running as a service) and will su internally to the $ARTIFACTORY_USER user. If the $ARTIFACTORY_USER is undefined Artifactory will run as the current user, which is not recommended, especially if the current user is root, due to security considerations.
Running Artifactory Manually on Unix

You can run artifactory manually with artifactory.sh directly to see its behavior. The console will be locked on artifactory process and you can stop it cleanly with crtl+c. You can also try executing
artifactoryctl check|start|stop
to directly run Artifactory as a daemon process, using the environment variable of the shell you are currently in.
Installing on Windows
Windows
When using Windows it is possible to install Artifactory as a Windows service or run it manually.
Installing Artifactory as a Windows Service Overview

Artifactory makes use of the Java Service Wrapper components in order to give the user a way to install the application as a Windows Service.
Requirements
The "java" system path is used in the JSW configuration file ( %ARTIFACTORY_HOME%\bin\wrapper.conf). This value can be altered to an environment variable, full-path, etc.
Installing
To install Artifactory as a Windows service, browse to %ARTIFACTORY_HOME%\bin, and execute the file InstallService.bat.
Uninstalling
To uninstall the Artifactory service, browse to %ARTIFACTORY_HOME%\bin, and execute the file UninstallService.bat.
Running Artifactory Manually on Windows

Just execute "artifactory.bat" under the bin folder. This will look for the Java executable and run Artifactory's main class.
RPM Installation
Overview
Artifactory can also be installed as an RPM package on RedHat compatible Linux distributions. The RPM distribution is available starting with Artifactory 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 that are included with the Artifactory zip distribution.
Requirements
Must be installed using the root user (or sudo). An environment variable named JAVA_HOME pointing to the installation directory of JDK 1.5+ (the latest JDK 1.6 is highly recommended).
Managed Files And Folders

Purpose Artifactory binary and Tomcat home Artifactory startup script Artifactory home Artifactory etc Artifactory logs Artifactory environment variables Location /opt/artifactory /etc/init.d/artifactory /var/lib/artifactory /etc/artifactory /var/log/artifactory /etc/artifactory/default Ownership root root artifactory artifactory artifactory artifactory
MySQL Additional Configuration

The RPM includes a small CLI tool that assists with the configuration of Artifactory to use MySQL as a storage method (recommended). After running the RPM installation process, it will offer you to run the MySQL configuration manually. The tool is located in /opt/artifactory/bin/configure.mysql.sh and requires MySQL to be pre-installed and running.
Installing Artifactory
To install Artifactory use:
rpm -ivh artifactory-rpm-<version>.rpm
Running Artifactory
To start and stop Artifactory use the init script:
/etc/init.d/artifactory start
or-
/etc/init.d/artifactory stop
Accessing Artifactory
Artifactory should be available under the following URL: http://localhost:8081/artifactory
Deployment on Other Servlet Containers

General
Artifactory is a standard Java EE web application. As such, it can be installed and run on any Servlets 2.5 compliant Container. We specifically verified Artifactory 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 generic instructions for installing the artifactory.war on any servlet container. There are also more detailed and specific instructions for installing under Tomcat and IBM Websphere and JBoss.
GlassFish requires Artifactory 2.0.1 and above.
Deploying the WAR File

"Drop the War": Zero Configuration
Artifactory can be installed under any Servlet container by simply dropping or installing the artifactory.war file into the containers web applications folder, for example, into Tomcat's webapps folder. All you have to do is deploy the artifactory.war file into your Servlet container, either by hot-deploy or by following the container's standard web application deployment procedures. The artifactory.war file is located under the webapps folder in the artifactory-x.y.x.zip distribution.
It is recommended not to include any version characters in the name of the war file, and leave it just as: artifactory.war, in order not to have version-specific information in the Artifactory base URL and in order to make future upgrades simpler.
The $ARTIFACTORY_HOME Folder

Even with zero configuration, it is important to know where the Artifactory home folder is, since this folder stores your configurations and important repository data.
When Artifactory runs for the first time, it will set up a default configuration and create all needed files and folders under a $ARTIFACTORY_HOME folder that, if unset, will default to ${user.home}/.artifactory. If you wish to control the location of $ARTIFACTORY_HOME (which you probably do when installing Artifactory on a production server), you can do one of the following: Startup the Servlet Container VM with -Dartifactory.home=$ARTIFACTORY_HOME, pointing to the location of your Artifactory home folder, or Set an $ARTIFACTORY_HOME environment variable pointing to this location. Artifactory will try to create the folder on startup if it does not already exist.
Make sure the folder is writable by the user running the Servlet Container.
Manual Deployment
You can set up Artifactory on any Servlet container by deploying the war and pointing Artifactory to a dedicated ARTIFACTORY_HOME created by extracting the Artifactory distribution zip. To do this: 1. Extract the Artifactory distribution archive (artifactory-xxx.zip) to a dedicated folder. This folder will be you ARTIFACTORY_HOME (verify this by checking the presence of the $ARTIFACTORY_HOME/etc/artifactory.config.xml file). 2. Start the Servlet Container and specify the location of ARTIFACTORY_HOME by either using a JVM argument or by using an environment variable as explained in the previous section.
Dedicated Tomcat Instance

This documentation explains the steps for automatic installation under Unix on a dedicated tomcat instance. For manual Installation (on either a dedicated or shared instance) please refer to the Generic WAR Installation documentation.
Automatic Installation on a Dedicated Tomcat Instance

You can use the automated install script to set up a dedicated Tomcat server for Artifactory.
These instructions have been verified against Tomcat 6, but should work on Tomcat 5 with minor adjustments. You can change the directory names to your liking but you'd need to adjust the install scripts accordingly (currently directory names are hard-coded).
1. Extract the Apache Tomcat download under /opt/tomcat/artifactory. 2. Extract Artifactory standalone /opt/artifactory/current 3. Run (or edit and run) the $ARTIFACTORY_HOME/bin/tomcat-install.sh script. The script will do the following: Run the $ARTIFACTORY_HOME/bin/install.sh script. Replace /etc/init.d/artifactory with $ARTIFACTORY_HOME/misc/Tomcat/artifactory. Replace tomcat's conf/server.xml with $ARTIFACTORY_HOME/misc/Tomcat/server.xml (change its ports if you wish) Create under Tomcat the conf/Catalina/localhost directory and copy the $ARTIFACTORY_HOME/misc/Tomcat/artifactory.xml into it. Replace tomcat's bin/setenv.sh with $ARTIFACTORY_HOME/misc/Tomcat/setenv.sh Change the Tomcat home owner : chown -R artifactory /opt/tomcat/artifactory
The script will change the default Tomcat configuration files and is intended to be used on a newly installed Tomcat only.
4. Start tomcat: service artifactory start, or /etc/init.d/artifactory start Artifactory will be available on this Tomcat instance on port 8081 for HTTP and 8019 for AJP13.
A Note About Pre-packaged Tomcat Distributions There have been a reports suggesting there are known problems deploying to automatically Tomcat installed as part of various Linux distros with default security settings. See, for example: http://www.nabble.com/Re%3A-java.lang.NoClassDefFoundError%3A-org-quartz-CronExpression-p13139289.html Please check the specific Tomcat installation you are using or download and install the "standard" Tomcat from the Apache site.
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'd have to tell JBoss to use the JVM's built-in MBean server. To do this, start JBoss with the jboss.platform.mbeanserver system property set. On Unix, you can do this by adding the following line to the JBoss startup script:
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

Overview
Artifactory can run under IBM's WebSphere application server (this required specific adjustments in Artifactory in order to "play nicely" with WebSphere's own way of doing things). Please note, that this is not an out-of-the-box feature and requires minimal manual setup. These instructions have been verified against WebSphere 6.1, but should work on WebSphere 7 as well.
Setup
Before deploying Artifactory into WebSphere: 1. Extract the artifactory.war file. 2. Replace the standard web.xml file under %EXTRACTED_WAR_FOLDER%/WEB-INF with the WebSphere-specific web.xml from %ARTIFACTORY_HOME%/misc/websphere. 3. Repackage (zip) the war file. 4. Start WebSphere. 5. Add the following webcontainer custom property and set it to 'true' (see: PK33090):
com.ibm.ws.webcontainer.invokefilterscompatibility
6. Save the change and restart WebSphere. 7. Deploy normally into WebSphere.
Running Behind Apache HTTPd

Setting up Apache HTTPd as a Front-end to Artifactory
You may want to a use Artifactory behind Apache HTTPd. This can be done via two alternative protocols HTTP or AJP:
10
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 mod_proxy_ajp, or with mod_jk - for greater configuration flexibility. The examples below will use mod_ajp which is distributed with Apache by default.
AJP and Jetty The AJP protocol is not recommended for use by Jetty ("It is recommended to NOT use the AJP protocol, and superior performance and clearer semantics will be achieve [sic] using HTTP."). We therefore advise not to use AJP with Jetty, but to use mod_proxy as recommended by Jetty.
Configuring Apache with mod_ajp Installed
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>
Reset your cookies Whenever changing the Artifactory context path in Apache make sure to reset your browser's host and session cookies. Having stale context path value cached by cookies can lead to strange UI issues, such as Not authorized to instantiate class errors when switching between tabs.
Configuring Apache with changing the artifactory path
Same setup as above but here the goal is to have http://artifactory.yourdomain.com/repository/ as root URL for Artifactory:
<VirtualHost *:80> ServerAdmin your@email.address.com DocumentRoot "/srv/www/httpd/htdocs" ServerName artifactory.yourdomain.com ErrorLog "logs/artifactory-error_log" ProxyPreserveHost on ProxyPass /repository/ ajp://localhost:8009/artifactory/ ProxyPassReverse /repository/ http://artifactory.yourdomain.com/artifactory/ ProxyPassReverseCookiePath /artifactory/ /repository/ </VirtualHost>
Tomcat Configuration
11
On Tomcat you need to configure the AJP connector, which is 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 here for more configuration options.
Using HTTP Proxy

Having Apache proxy Artifactory via HTTP is the recommended setup when running Artifactory from the default distribution which is Jetty-based. It is required to configure correct redirects using the pass-reverse directive as well as set the base URL in Artifactory itself so that UI links show up correctly.
Configuring Apache with mod_proxy_http Installed
The sample virtual host assumes Tomcat or Jetty HTTP connector runs on port 8081. Note that for HTTP redirects to work, you need to set a pass-reverse directive on Apache, or the underlying container base URL will be passed in redirects (in this example to http://localhost:8081/artifactory/).
<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/ http://localhost:8081/artifactory/ ProxyPassReverse /artifactory/ http://localhost:8081/artifactory/ </VirtualHost>
Tomcat Configuration
On Tomcat you need to configure the HTTP connector, which is located by default under $CATALINA_HOME/conf/server.xml:
<Connector port="8081" protocol="HTTP/1.1" maxThreads="500" minSpareThreads="20" maxSpareThreads="150" enableLookups="false" disableUploadTimeout="true" backlog="100"/>
See here for more configuration options.

Configuring a Custom URL Base in Artifactory
When not using AJP, the links produced by Artifactory as well as certain redirects will contain the wrong port. To fix this, configure a custom base URL, by going to Admin:Configuration:General:Custom URL Base. Set the base URL to the value used to contact Artifactory on Apache, for example: http://artifactory.yourdomain.com/artifactory See the General Configuration section for more details about configuring the base URL.
Proxying Apache HTTPs to Artifactory running HTTP

You may want to run Artifactory behind Apache with SSL (HTTPs). This can also be achieved via HTTP or AJP:
12
Client ----------> HTTPD ----------> Artifactory HTTPs HTTP/AJP
Using AJP
If you are not using Jetty (see above: AJP and Jetty), then AJP is recommend since it tells the servlet container everything about the correct base URL and requires zero configuration in Artifactory.
Configuring Apache with mod_proxy_ajp Installed and Tomcat
The Apache and Tomcat sample configurations are identical to the one listed on "Using AJP" on this page for non-HTTPs Apache.
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.eclipse.org/Jetty/Tutorial/Apache - Proxying SSL on Apache to HTTP on Jetty). If you do not use this connector all redirects will use the wrong scheme. We therefore recommend using Artifactory with Tomcat in this case, in favor of the default Jetty-based distribution.
Using HTTP Proxy

Configuring Apache with mod_proxy_http Installed and Tomcat
The Apache and Tomcat sample configurations are identical to the one listed on "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 will not only contain the wrong port but will use the http scheme instead of https. To fix this, configure a custom base URL, by going to Admin:Configuration:General:Custom URL Base. Set the base URL to the value used to contact Artifactory on Apache, for example: https://artifactory.yourdomain.com/artifactory See the General Configuration section for more details about configuring the base URL.
Changing the Default 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 (made possible by the underlying Jackrabbit JCR), so you can configure Artifactory to run with almost any JDBC database or even store data completely on the file system.
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 an already stored file, Artifactory will not store the new file content, but will make a link to it in the metadata of the newly deployed file. This principal applies regardless of under which repository and path artifacts are deployed - you can deploy the same file to many different coordinates, and as long as an identical content was found in the storage it will be reused.
Changing the Storage Type Used

The general principal for changing the storage used by Artifactory is to edit the $ARTIFACTORY_HOME/etc/artifactory.system.properties file:
artifactory.jcr.configDir=repo/[selected-storage-type]
The path used can be either a relative path to $ARTIFACTORY_HOME/etc or an absolute path, and is expected to contain a repo.xml file (which is a Jackrabbit configuration file).
13
For a JDBC database you will also need to: 1. Download the appropriate JDBC driver and install it in your server's shared lib directory. 2. Create a database instance to which Artifactory will connect (when using an out-of-process database). Database tables will be auto-created. 3. Change the database details in the repo.xml file to match your database.
Backing up your existing installation When changing the storage type for an exiting installation you will need to import the old Artifactory content and configuration from backup. Make sure to back up your older Artifactory system before using a different storage type.
Removing the old $ARTIFACTORY_HOME/data folder If you already run Artifactory before with a different storage type you will need to remove (or move-aside) the existing $ARTIFACTORY_HOME/data folder, or Artifactory will still use part of the old storage definitions and will fail to start up (you will see record not found exceptions on startup). Starting with a clean or no $ARTIFACTORY_HOME/data folder will fix this.
Changes to repo.xml Except for updating the database details in repo.xml, do not make any other changes to the repo.xml file or try to manually replace it with a repo.xml from a newer Artifactory version. All changes to the repo.xml file as part of an Artifactory upgrade are always applied automatically.
When Artifactory is Deployed as a WAR
If you deployed Artifactory as a WAR and have not specified a location for the $ARTIFACTIORY_HOME directory, it will be auto-created by Artifactory under '$user.home/.artifactory'. To use the bundled configuration files for common storage types, you may want to copy the etc/repo folder from the Artifactory distribution to your $ARTIFACTORY_HOME/etc. Then edit the $ARTIFACTORY_HOME/etc/artifactory.system.properties file as described above to point at the desired configuration.
The Bundled Storage Configurations

Out-of-the-box Artifactory comes with built-in configurations (repo.xml files) for the several storage types, as listed below.
Database Storage Types

The following configurations use a JDBC database for storage, and manage binaries as blobs with file system blob caching (1Gb by default) 1. 2. 3. 4. 5. derby mysql - Please follow the MySQL-specific instructions postgresql oracle mssql
File System Storage Types

The following configurations store all binaries as files (in $ARTIFACTORY_HOME/data/filestore), and use a JDBC database for repository metadata management. This setting typcially yields the best performance with large repositories. 1. 2. 3. 4. 5. filesystem-mysql - The recommended setup. Please follow the MySQL-specific instructions. filesystem-derby (the default) filesystem-postgresql filesystem-oracle filesystem-mssql
14
For raw Artifactory data backup, the folder $ARTIFACTORY_HOME/data/filestore needs to be backed up in parallel of a DB dump since both are needed. This does not impact Artifactory's own backup system which is storage-agnostic.
Accessing a Remote Database

In order to avoid network latency issues when reading and writing artifacts data, it is highly recommended to create the database on the same machine on which Artifactory will be running or on a fast SAN disk.
This is critical if the files are served from database blobs and the file system cache size is low.
Running Artifactory on MySQL

Overview
The instructions below describes how to set up Artifactory on MySQL. By using MySQL (over the built-in Derby DB) you can leverage exiting MySQL infrastructure and use the MySQL backup, restore and high-availability features. The setup involves creating the dedicated MySQL database instance and then configuring Artifactory to use that instance.
Please make sure to read the general section about changing the default storage before configuring MySQL.
Create the Artifactory MySQL Database

Supported MySQL versions For best performance please use MySQL 5.5 and above with the InnoDB engine (the default with this version). Please note that versions of MySQL below 5.0.3 will not work with Artifactory.
You can use the $ARTIFACTORY_HOME/misc/mysql/createdb.sql SQL script to execute the SQL commands below to create a database. Please review and edit this script before executing it, according to your environment.
[root@pond artifactory]# mysql -u root Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 3 Server version: 5.0.45 Source distribution Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> create database artifactory character set utf8; Query OK, 1 row affected (0.00 sec) mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,ALTER,INDEX on artifactory.* TO 'artifactory_user'@'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 (see: max_allowed_packet
15
increase, for reference). We recommend changing this in the /etc/my.cnf file. Create this file if it does not already exist (under the absolute path, not under $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

1. Add (or uncomment) the following line in $ARTIFACTORY_HOME/etc/artifactory.system.properties:
artifactory.jcr.configDir=repo/filesystem-mysql
Note: this path is relative to $ARTIFACTORY_HOME/etc. 2. Adjust the connection definitions in the file $ARTIFACTORY_HOME/etc/repo/filesystem-mysql/repo.xml to match the attributes of the Artifactory database you created (if you don't have this file you can grab it from the standalone zip distribution or directly from here .). Jackrabbit uses 3 separate connection configurations for each of the following: a. The basic JCR repository metadata (configured under FileSystem tag) - minimal load and no connection pooling. b. The JCR datastore for all the binaries (configured under DataStore tag) - heavy load and uses connection pooling. c. The JCR workspace metadata (configured under PersistenceManager tag) - minimal load and no connection pooling. For each one of these tags you need to configure the database parameters and username/password to use. The schema and tables will be created on first run of Artifactory against the database. 3. Download the MySQL JDBC driver and copy the mysql-connector-java-x.x.x.jar jar file into the server's shared lib directory ( $ARTIFACTORY_HOME/lib in the standalone version), $TOMCAT_HOME/lib etc. 4. Start Artifactory.
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 $ARTIFACTORY_HOME/data/store). This is the recommended setup. It is possible, but not recommended, to store BLOBs inside MySQL, provided that 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 wish to store BLOBs inside MySQL, please use repo/mysql instead of repo/filesystem-mysql, and change the max_allowed_packet above to the maximum artifact size you are planing to store in Artifactory, for example 128M.
Upgrading Artifactory
Upgrading Artifactory to Version 2.6.x
(from 1.3.0-RC, 2.0.x-2.5.x) Storage Type Changes: if you also wish to change the underlying storage type used by Artifactory, please read the following instructions instead. The instructions below assume the upgraded Artifactory will use the existing storage type.
When Running the Artifactory WAR in a Servlet Container

1. Unzip the Artifactory distribution archive. 2. Replace the previously deployed artifactory.war file with the archive's webapps/artifactory.war file. On servlet containers such as Tomcat it is also necessary to remove the exploded artifactory webapp directory.
16
Starting with version 2.1.1 Artifactory's only distribution format is a single zip archive (artifactory-x.y.z.zip) that also contains the artifactory.war file in the webapps directory.
When Running Standalone Artifactory

1. Unzip the Artifactory distribution. 2. Replace the following files and folders in you current $ARTIFACTORY_HOMEwith the same files from the new version:
artifactory.jar clilib/ (/bin/clilib, in 1.3.0-RCs) lib/ webapps/artifactory.war etc/jetty.xml misc
The misc folder contains configuration files for specialized environments such as a standalone Tomcat server or Websphere. Although these files are not required for runtime, it is recommended to replace this folder as well.
3. Delete Jetty's work folder ($ARTIFACTORY_HOME/work) before starting up Artifactory.
When Running the RPM Installation

1. Log in as root (or use 'sudo su -'). 2. Execute 'rpm -U artifactory-x.y.z.rpm'
When upgrading from Artifactory prior to 2.6.0, please make sure to manually stop the current Artifactory service before running the upgrade, and verify the process has exited.
Upgrading From Legacy Versions

If you would like to upgrade from Artifactory versions below 1.3.0-RC, you will need to upgrade Artifactory to version 2.0.x first. Please follow these steps.
When upgrading from 2.1.x or 2.0.x The Artifactory upgrade process is fully automated. However, the automatic upgrade to this version will likely run longer than you are used to: As part of the performance improvements done for this version we had to upgrade the way artifact metadata is stored and indexed inside Artifactory. The result is much faster searches and significantly improved performance of the whole system under load. However, since repository metadata and index need to be rebuilt, the upgrade process may take some time to complete (this time varies depending on your CPU and disk speed). Artifactory will not serve incoming requests until the automatic upgrade process completes, so you may want to schedule the upgrade accordingly. You can follow the progress of the upgrade process in the the artifactory log file. Preserving Build Information Please also note that using the upgrade process is the only way to move deployed build-information forward. You cannot import an export of 2.1.x with BuildInfo data into 2.3.x. This is a result of a bug that has already been resolved.
Intermmediate Upgrade to Previous Versions

Upgrading to 2.0.0 from 1.3.0-RC1 or 1.3.0-RC2
17
Simply replace the artifactory.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

This section covers upgrading from the following versions:
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 1.3.0-beta-6 1.3.0-beta-6.1
Upgrading Artifactory from older version can be done in two ways: 1. From the UI 2. By using the artadmin command line tool
Upgrading Using the Web UI

Upgrading from the UI is supported only when upgrading from version 1.3.0-x. 1. From your old Artifactory installation run Full System Export and save the export to a destination directory. 2. 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). 3. Install the new Artifactory version, go to Admin/Export&Import/System/Import System, select your previous export target directory and let the import run. That's it!
Upgrading Using the artadmin Tool

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 artadmin command-line tool. Here are step-by-step instructions: 1. Stop your old Artifactory. 2. Execute the artadmin dump command on the old $ARTIFACTORY_HOME or on a copy of it (recommended):
artadmin dump $ARTIFACTORY_HOME
This will generate a dumpExport folder under the current execution directory with the old repository data in a format suitable for importing into a current Artifactory. NOTE: By default, caches (e.g. repo1) are not exported. To export caches add the --caches parameter. 3. 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). 4. Start the new Artifactory. 5. Import the dumpExport folder into Artifactory, either from the UI, as explained in the previous section or by running:
artadmin import dumpExport --username admin --password password
The artadmin output will display the progress of the import. NOTE: If the artadmin process is killed, the import will still run in Artifactory.
Important Information
Please read this carefully before installing or upgrading:
18
1. If you have used a previous version of Artifactory it is highly recommended to: a. Use a fresh version of Artifactory from the distribution archive and not try to patch the previous installation. b. Clear your browser's cache before using the new version. 2. The default Artifactory user for the standalone installation has been changed to artifactory (instead of jetty). You may need to update the provided install script or your file system permissions accordingly.
Important information about the import process During the import binary artifacts are copied over into a working copy and are imported into Artifactory 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 (it will still serve any artifact immediately, though). The Artifactory log should 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 $ARTIFACTORY_HOME/data folder from your new Artifactory installation before doing so.
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 The artadmin Command Line Tool Clustering Artifactory The Artifactory Log Files System Information
General Configuration
Overview
The Admin:Configuration section lets you set up various parameters that globally affect Artifactory:
19
General Settings
1. The server name, displayed on the tile of each page. 2. 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. 3. Maximum allowed size for files uploaded via the web interface. 4. The date format for displaying dates inside the web interface. 5. A global offline flag that tells 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)

Here you can customize artifactory with your own logo presented on the upper left of the screen and footer text.
You can either upload a logo image or use an exiting image on a remote URL. The uploaded file will be copied into the ARTIFACTORY_HOME/etc/ui folder. For a footer, input the desired text in the 'Additional Footer' field.
20
To make the changes visible you need to save them first.
Add-on Settings
This configuration setting is for controlling Artifactory's behavior with regards to the Artifactory Add-ons Power Pack. 1. The Server ID is used to activate the Artifactory Add-ons Power Pack on the current Artifactory server. You can leave it empty when using the open source version with no add-ons installed. 2. You can decide whether or not to show available add-ons information in Artifactory's for add-ons you do not have installed. Available add-on information typically looks like this:
As an admin, you can decide whether users will see add-ons information or not. Note that enabling add-ons information display overrides any previous user-specific preference for hiding it (a user will still be able to choose to hide this information again).
Managing Repositories
This section explain the common controls available for each repository type. Understanding Repositories Configuring Repositories Local and Remote Repositories Local Repositories Remote Repositories Virtual Repositories
Understanding Repositories
Copyright 2012 JFrog Ltd. 21
Local, Remote and Virtual Repositories

Artifactory hosts two kinds of repositories: local and remote. Both local and remote repositories can be aggregated under virtual repositories, in order to create controlled domains for artifacts resolution and search, as we will see in the next sections.
Managing Repositories
Repositories can be created, deleted, edited, ordered and aggregated using the administration UI: Admin:Configuration:Repositories
Local Repositories
Local repositories are physical locally-managed repositories that one can deploy artifacts into. Artifacts under a local repository are directly accessible via a URL pattern of http://<host>:<port>/artifactory/<local-repository-name>/<artifact-path> Artifactory comes with a couple of pre-configured local repositories for deploying internal and external releases, snapshots and plugins.
Remote Repositories
A remote repositories 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 a URL pattern of http://<host>:<port>/artifactory/<remote-repository-name>/<artifact-path> or http://<host>:<port>/artifactory/<remote-repository-name>-cache/<artifact-path> (the second URL will only serve already cached artifacts while the first one will fetch a remote artifact int the cache if it is not already stored). Artifactory comes with pre-configured common remote repositories, which you can, of course, change. Remote repositories configuration can also be imported from another Artifactory instance. JFrog public repository contains up-to-date standard list of remote repositories available on the net.
22
A remote repository acts as a proxy not as a mirror. Artifacts are note stored eagerly in remote repository caches, but are fetched and stored on demand when they are requested by a client. It therefore makes perfect sense for a remote repository to contain zero artifacts immediately after its creation.
Virtual Repositories
A virtual repository (or "repository group", if you prefer this term) aggregates several repositories under a common URL. The repository is virtual in the sense that you can resolve and get artifacts from it but you cannot deploy anything to it.
The Default Virtual Repository

By default, Artifactory uses a global virtual repository that is available at http://<host>:<port>/artifactory/repo This repository contains all local and remote repositories.
Virtual Resolution Order

The search/resolution order when requesting artifacts from a virtual repository 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 that shows the effective repositories order per virtual repository. This is particularly helpful when nesting virtual repositories.
General Resolution Order

Managing the global configuration order is done in the administration UI Admin:Configuration:Repositories. For each lists of repositories (local, remote, virtual) you can reorder using drag-and-drop or select with the up and down arrow buttons. When your order is done you can use the "Save" button, or "Reset" to cancel the reordering. Repositories resolution if 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 repositories configuration.
Repository Key
The repository identifier needs to be valid XML ID Name, and be unique for the whole Artifactory configuration data. So, repository keys cannot starts with a number, and it is recommended to suffix local repository with "-local".
Description
Free text describing the content and goal of the repository. This will help user configuration, UI screens and repository sharing.
Include and Exclude Patterns
23
It is extremely important to use include and exclude patterns for repositories. This is especially important for remote repositories in order to: 1. Avoid Looking up remote artifacts on repositories that will never contain those artifacts, or that contain only a limited range of group ids. 2. Not disclosing sensitive business information that can be derived from your artifact queries to whoever can intercept the queries, including the owners of the remote repository itself. As best practices, it is easier to manage the list of remote repositories used in an organization under one virtual repository ( for example: remote-repos ). In this case, you can globally stop querying remote repositories for companies 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 Admin:General:Repositories:Edit. Specify a comma separated list 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 ones (defaults to everything). for example:
Includes Pattern: org/apache/**,com/acme/** Excludes Pattern: com/acme/exp-project/**
Will cause Artifactory to submit queries to the repository in question for org/apache/maven/parent/1/1.pom and com/acme/project-x/core/1.0/nit-1.0.jar but not for com/acme/exp-project/core/1.1/san-1.1.jar.
Local and Remote Repositories

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 release artifacts. The repository will reject deployments that are conflicting with this policy and will not participate in conflicting resolution requests.
Snapshot and release handling are currently supported for artifacts that follow the Maven naming conventions. Support for flexible non-Maven snapshot and release identification will be introduced in the upcoming release of Artifactory.
Repository Blackout
It is possible, if desired for whatever reasons, to completely black-out a repository by marking its "Blacked Out" flag, making it effectively disabled. A blacked-out repository does not participate in any artifacts resolution and artifacts cannot be downloaded from it or deployed to it.
Suppressing POM Consistency Checks

By Default, Artifactory tries to keep your repositories healthy by refusing bad POMs that have wrong coordinates (path). If the information groupId:artifactId:version inside the POM does not match the deployed path, Artifactory will reject the deployment. You can disable this behavior by selecting the "Suppress POM Consistency Checks" checkbox.
Local Repositories
Overview
This section covers the controls that are specifics to local repositories.
Centrally Controlled Maven Unique Snapshot Policy
24
One of the unique features of Artifactory is you can gain centralized control on how snapshots are be deployed into a repository, regardless of end user-specific settings. This can guarantee standardized format for deployed snapshots within your organization. You can choose between: Non-unique snapshots. Unique snapshots - with unique time-stamp and build number suffix. Deployer-respecting behavior - Artifactory will respect the user snapshot policy, i.e. act as a standard, non-smart, repository.
Maven 3 Only Supports Unique Snapshots Maven 3 has, unfortunately, dropped support for resolving and deploying non-unique snapshots. Therefore, if you have a snapshot repository that is using non-unique snapshot, it is recommended to change its Maven snapshot policy to 'Unique' and to 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 were 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 Build Integration support.
Cleaning-up Unique Snapshots

Putting aside the question of usefulness in using unique snapshots (see the section above), you can tell Artifactory to automatically clean up old unique snapshots by setting the repository's Max Unique Snapshots value to the 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 deployed resource is missing or conflicts with the locally calculated checksum (bad checksum). Checksum checking effectively verifies the integrity of the deployed resource.
25
The options are: 1. Verify against client checksums (default) - Until a client has sent a valid checksum for a deployed artifact that matches the server's locally calculated checksum, the artifact will not be available and will return 404 (not found). If the client has sent a checksum that conflicts with the one calculated on the server a 409 (conflict) will be returned until a valid checksum is deployed. 2. Trust server generated checksums - Do not verify against checksums sent by clients and trust the ones store server's locally calculated checksums. An uploaded artifact will be available for consumption immediately, but integrity might be compromised.
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 are 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 controlled period of time. For Maven artifacts, this is applicable only for snapshots, since releases are assumed never to change.
26
When a request arrives at Artifactory for an artifact that's caching timeout has expired, Artifactory will check if there is an updated artifact remotely.
We experimented with timeout settings in many different locations before deciding on the default values. It is therefore recommended not to change the defaults, unless there's a compelling reason to do so.
Socket Timeout
This is the timeout period (for socket and connection) that Artifactory will wait before giving up on retrieving an artifact from a remote repository. After a timeout Artifactory will cache the fact that a retrieval failure has happened for the amount of time defined in "Failed Retrieval Cache Period". Artifactory will answer future requests for that particular artifact with NOT_FOUND (404) for a period of "Failed Retrieval Cache Period" seconds and will not attempt to retrieve it it again until that period expired.
Keep Unused Artifacts

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
27
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.
Failed Retrieval Cache Period

See the explanation for Socket Timeout.
Missed Retrieval Cache Period

The number of seconds to cache artifact retrieval misses. A value of 0 means no caching. A miss is a 404 response (NOT_FOUND) received from a remote 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 Artifacts:Tree Browser and clicking (or 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 Browser and clicking (or selecting, if right-clicking the item) the "Zap Caches" action.
Handling Offline Scenarios

Overview
Artifactory supports two kind of offline cases: when the whole organization is disconnected from remote repositories and 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 that are using a separate secured network (such as military or financial institutes) and are disconnected from the rest of the world. In such cases, you can turn on (and off) the Global Offline Mode flag, under Admin:Configuration:General.
28
Single Repository Offline

A less rigid case is where one or more remote repository has become offline for some reason. In this case, it is possible to tell Artifactory to treat the individual remote repository as offline, so that only artifact already present in the cache will be used.
Handling Checksums
Overview
Artifactory can help you block broken artifacts by activating checksum handling - Artifactory will then query the remote checksum prior to storing the file locally.
Configuring Checksum Policies

Using the configuration for a remote repository, you can choose between failing on bad checksums (blocking them), recalculating bad checksums,
29
calculate only missing checksums and accepting bad checksums.
Going Through Proxies

Overview
In a corporate environment it is often required that, in order to access remote resources, you need to go through a proxy server. Artifactory supports both regular network proxies and NTLM proxies.
Defining Proxies
To use a proxy you first need to create a proxy definition via Admin:Configuration:Proxies. 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).
Checking the "System Default" checkbox, will activate a popup with the question "Do you wish to use this proxy with existing remote repositories (and override any assigned proxies)?":
Pressing "OK" will assign this proxy to all remote repositories (see below). If the proxy is defined as "System Default" then Artifactory will use 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 will be
30
reused by requests redirected to any of these hosts.
Using Proxies
A remote repository will use a proxy, only if one is selected in the configuration panel for that repository. A "System Default" proxy is assigned by default when creating a new remote repository, but not used by default. A remote repository without a proxy defined will not use any proxy!
Advanced Settings
31
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 *.jar immediately when *.pom is queried. Try and fetch a *-sources.jar when *.jar is queried. Having these options on can speeds up first downloads by a factor.
Suppressing POM Consistency Checks

By Default, Artifactory tries to keep your repositories healthy by refusing bad POMs that were deployed on remote repositories with wrong information. Artifactory will check that the coordinates (path) of POMs retrieved remotely match the groupId:artifactId:version information inside the POM, and will reject POMs that conflict with their path. You can disable this behavior by selecting the 'Suppress POM Consistency Checks" checkbox.
Cleaning-up Unique Snapshots

If the remote repository managed unique snapshots names (The same groupId:artifactId:version will have many jars and pom with date and build number), you can tell Artifactory to automatically clean up old unique snapshots by setting the repository's Max Unique Snapshots value to the maximum number of unique snapshots of an artifact that should be maintained in the repository. Clean up takes effect each time a
32
new snapshot file name is downloaded and cached.
Remote Repository Authentication

If a remote repository requires authentication you can provide a username and password as part of the repository definition.
List Remote Folder Items

If you wish to browse the contents of a remote repository that has not been cached yet, you can enable this checkbox. This will allow to navigate the contents of the remote repository via the Simple Browser or List Browser.
Proxying Maven 1 repositories

To proxy Maven 1 repositories, simply set the remote repository type 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 wish to use for remote connections under the "Local Address" field.
Importing Shared Configurations

Overview
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
In the main panel of Admin:Repositories:Remote Repositories:Edit the checkbox "Share Configuration" will tell Artifactory to expose this remote repository configuration to other Artifactory instance. When check, all configuration parameters will be shared from REST API queries except: Connection credentials (username,password) and Proxy configuration.
You can declare a remote repository with a URL pointing to yourself in order to expose access to your Artifactory. Be careful that this remote repository is not usable.
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.
33
You can then enter the artifactory root URL of the server exposing remote repositories configuration. By default it points to JFrog public repository. Then activating "Load" will issue a request to the server.
If you have a "System Default" proxy defined, Artifactory will use it for doing this HTTP query.
A list of remote repositories can be selected and the repository key for each of them can be changed.
Important points to notice: 1. If the repository key already exists, the configuration of the existing remote repository will be modified. 2. If HTTP proxy is used, each of the new repository will have to be associated with the local proxy definition. 3. You will have to add new remote repositories to existing virtual repositories in order for them to be visible to virtual repository requests.
Overview
Artifactory lets you define a virtual repository that is a collection of local, remote and other virtual repositories under a single logical URL. A virtual repository hides the underlying repositories and lets users work against a single well-known URL, while allowing you to change the participating repositories and their rules without requiring any client-side changes. The main features supported by a virtual repository are: 1. 2. 3. 4. Nesting, Include Exclude patterns filter, Automatic removal of repository references, WebStart automatic signing and JNLP file conversion.
Setting Up a Virtual Repository

From the UI go to Admin:Configuration:Repositories:Virtual Repositories and create a new virtual repository. Add the repositories you wish to be part of the virtual repositories to the virtual repository list of selected repositories.
34
The actual list of effectively resolved repositories (after expanding nested virtual repositories) will be displayed and automatically updated.
The search/resolution order when requesting artifacts from a virtual repository is always: local repositories, remote repository caches and finally remote repositories themselves.
Nesting Virtual Repositories

The ability to nest virtual repositories is unique to Artifactory. It allows for greater reuse of virtual repositories between themselves.
Artifactory will detect when overly nesting repositories ends up in an infinite loop and will warn against that.
35
Include Exclude Patterns in Virtual Repositories

The coupling of Include/Exclude patterns of Artifactory Configuring Repositories to virtual repositories nesting provides a powerful feature. You can now define in a single virtual repository "remote-repos" the company groupId exclusion, and it will ensure that no requests for internal artifacts will be sent outside. Another example for this feature, is defining virtual repository for a project, and filter undesirable groupId, sources or versions, that won't be visible to developers.
Serving Requests from Other Artifactory Instances

By setting the 'Artifactory Requests Can Retrieve Remote Artifacts' flag, you can instruct Artifactory whether the virtual repository should include remote repositories in artifacts resolution when answering requests coming from other Artifactory instances. This is useful when deploying Artifactory in a mesh (grid) architecture, where you do not want all remote Artifactories to act as remote proxies for other Artifactory instances.
Currently, to control remote artifacts resolution for other Artifactory instances for the global virtual repository 'repo', you'd have to use the artifactory.artifactoryRequestsToGlobalCanRetrieveRemoteArtifacts system property, which is set to false by default.
Making Sure Artifactory is Your Sole Artifacts Provider

One very bad practice (sadly heavily used on public POMs), is to add a direct reference to external repository in a POM. When any of
<project><repositories><repository>
or
<project><pluginRepositories><pluginRepository>
are present, Maven will dynamically add external repository URL to the build. This will shortcut Artifactory. The solution until now was the usage of mirrorOf like described here. Artifactory provide at the virtual repository level, an automatic cleanup of POM file. Three level of cleanup policy are configurable: 1. Discard Active References - Will removes repository elements that are declared directly under project or under a profile in the same pom that is activeByDefault. 2. Discard Any References - Will removes all repository elements regardless of whether they are included in an active profile or not. 3. Nothing - Don't removes any repository elements declared in the POM.
Managing Security
Copyright 2012 JFrog Ltd. 36
Overview
One of the main strengths of Artifactory is the strong security model it offers: You can assign role-based or user-based permissions to areas in your repositories (called Permission Targets), allow sub-administrators for theses 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 users management is available from the web UI under Admin:Security:Users. An administrator needs to create users (unless external authentication, such as LDAP is active) and assign them 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 signle password shared between all individuals in the same department, while only an administrator can update the password. When external authentication, such as LDAP, is active you can disable the fallback to using internal password by checking the "Disable Internal Password" checkbox.
Passwords are always stored as hashes or encrypted hashes inside Artifactory.
Administrator Users
37
An administrator user is to Artifactory like a root in 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 (that are in charge of a specific repository path). See the permissions management section.
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 the first time you log in. It is possible to recover the default admin account by following these instructions.
The Anonymous User

Artifactory supports the concept of anonymous users. A built-in, unmodifiable 'anonymous' user exists in Artifactory, that can be assigned permissions, just as any regular user. A global "Allow Anonymous Access" flag controls whether this 'anonymous' user is active or not, and must be turned on before you can fine tune the anonymous user permissions. Anonymous access is turned on by default. It can be turned on and off from the Admin:Security:General page:
When the global anonymous access is on, anonymous download requests will be able to download cached artifacts and populate caches, regardless of other permissions definitions.
Users Management
Other users management such as editing, removing and assigning groups to selected users can be done under Admin:Security:Users
Recreating the Default Admin Account
38
This action is applicable only from version 2.0.6 (including).
Obtaining A Security Configuration File
If your instance of Artifactory is configured to perform backups, you can find the security.xml file at the top backup directory, Make a copy of this file, open up it up with a text editor, change the admin's "password" field to
<password>5f4dcc3b5aa765d61d8327deb882cf99</password>
(which is 'password' in hash) and keep it aside. In case no backup is available, you may contact us for further help.
Resetting The Password
Take the modified security configuration file, place it under $ARTIFACTORY_HOME/etc and rename it to: security.xml for versions 2.0.6 - 2.0.8. security.import.xml for versions 2.1.0 - latest. Now restart Artifactory, and the admin password should be reset.
Managing Groups
Overview
Groups are managed in Artifactory from the web UI under Admin: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 in 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 will auto-join. This is particularly useful when using external authentication, like LDAP, where users are automatically created on successful login and you want them to automatically be part of a certain group.
39
Managing Permissions
Overview
Artifactory allows you to manage permissions per a Permission Target. A permission target is an concept that denotes a physical (non-virtual) repository and include and exclude patterns on the repository + a set of permissions. Multiple permissions for groups or users, hence ACLs, can be attached to a single permission target. An example permission target might be: 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 at Admin:Security:Permissions.
Creating a Permission Target

When creating a permission target, you first have to select the repositories the permission target will be applicable for. Then, select multiple include and exclude patterns in Ant-like format. The combination of these patterns constitutes the set of paths that will be governed by this permission target. In the example below sources are specifically excluded from the permissions. You can use the drop down lists to insert common predefined include and exclude patterns and customize them for your needs.
40
Finally, select the groups and users you wish to grant/revoke permissions. There are four possible permissions: 1. 2. 3. 4. 5. 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.
41
Permissions are additive and negative (actions not specifically granted are forbidden) by default.
Permission Target Admins

Permission targets administrators are local administrators to the specific permission target. As such, they can assign new permissions on the permission target to other users or groups. Upon logging-in to the web application, these users will 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 wish to delegate to teams the role of managing their repositories. The 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
You can examine the effective permissions of any item by selecting it in the Tree Browser (Artifacts:Tree Browser) and selecting the Effective Permissions tab.
42
Only users and groups that have assigned permissions will show up. If you don't see a user or a group in the table this means they do not have any permissions on the selected item.
By User
You can also select a specific user from the user management panel (Admin:Security:Users) to view the permission targets the users is part of (directly or by group association).
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 will first attempt to authenticate the user against the LDAP server. If the LDAP authentication fails, Artifactory will try to authenticate via its internal database. For every LDAP authenticated user Artifactory will create a new user in the internal database, if that user doesn't already exist, and will assign the user the default (auto-join) groups.
43
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 uses 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 LDAP Groups feature is bundled as one of the add-ons in the Artifactory Power Pack.
Configuration
LDAP authentication is configurable from Admin:Security:LDAP Settings.
The configuration parameters for connecting to LDAP are: Ldap Url - 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. User DN Pattern - 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). For example: uid={0},ou=People Search Filter - A filter expression used to search for the user DN that will be used in LDAP authentication. This is a LDAP search filter (as defined in 'RFC 2254') with optional arguments. In this case, the username is the only argument, denoted by '{0}'.
44
Possible examples are: (uid={0}) - this would search for a username match on the uid attribute. Authentication to LDAP will be done 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 will bind to the LDAP server to perform the search. Manager Password - Used only with "search" authentication method. It is the password of the user who will bind 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 settings.xml on your disk is a big security threat, since this password is very sensitive and is used in SSO to other resources on the domain. We strongly recommend, especially with LDAP, to use Artifactory's encrypted passwords in your local settings.
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 had already an account in the internal database with a password Artifactory will fallback to use his database password when his LDAP password failed. To prevent this scenario you can edit the specific user (Admin:Security:Users) and turn on the Disable Internal Password flag.
Using LDAPS (Secure LDAP)

To use LDAPS your LDAP server needs to 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 If, however, you wish to use LDAPS with a non-trusted (self-signed) certificate, please follow these steps (thanks to Marc Schoechlin for providing this information): 1. Download the CA of the ssl secured ldap server openssl s_client -connect the.ldap.server.net:636 -showcerts > server.ca 2. Identify the CA certificate and keep only the ascii-text between BEGIN/END CERTIFIACTE maker 3. Identify the standard cacerts file of your Java installation 4. Create a custom cacerts file by copying the cacerts file to the Artifactory configuration dir, e.g. cp /usr/lib64/jvm/java-1_6_0-ibm-1.6.0/jre/lib/security/cacerts /etc/artifactory 5. Import the CA certificate keytool -import -alias myca -keystore cacerts -trustcacerts -file server.ca => Password: changeit => Aggree for adding the certificate 6. Change permissions for the artifactory user chown 755 /etc/artifactory/cacerts chown artifactory:users /etc/artifactory/cacerts 7. Modify the defaults of the Artifactory JVM to use the custom cacerts file echo "export JAVA_OPTIONS=\"\$JAVA_OPTIONS -Djavax.net.ssl.trustStore=/etc/artifactory/cacerts\"" >> /etc/artifactory/default 8. Restart Artifactory
Centrally Secure Passwords

Overview
Using clear text passwords in your settings.xml file, which is Maven's default, is a security hole. This situation only gets worse 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 doesn't make the situation any better: 1. 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). 2. The master password used for decryption is stored in clear text on the file system. 3. Password encryption is left to the good will of the end-user and there is no way to centrally mandate it.
45
Artifactory provides a unique solution to this problem by generating encrypted passwords for users based on secret keys stored in Artifactory itself. By this, 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, from Admin:Security:General:
Using Your Secure Password

Get into your profile page (click on your login name on the upper-right corner) and type-in your current password. Once you enter a correct password you will see your password in the Encrypted Password field. Copy this value (including the {...} prefix) or use the sample server xml snippet in your settings.xml (you'd have to change the server name to match the id of your repository).
46
IBM JDK Encryption Restrictions Some of the IBM JRE/JDK are shipped with a restrictions on the encryption key size (mostly for countries outside of the US); There's an official way to remove this restriction 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 second radio button to download the file for version 1.4.2+. 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
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 about: logins, artifacts 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 Admin:Advanced:System Logs:
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 back up the whole Artifactory system. The backup process creates a timestamped directory in the target backup dir with identical out content as running full system export with metadata. You can define multiple backups via Admin:Services:Backup. Each backup may have its own schedule and repositories to process or exclude.
47
Backup content is in standard Maven format and can be loaded into any Maven repository, so that Artifactory never locks you up.
Controlling Backup Frequency

Backup works by specifying a valid cron expression. For example, to back up every 12 hours use a value of:
0 0 /12 * * ?
Incremental "In-place" Backups

Artifactory supports backing up incrementally to the same directory (named 'current') in the target backups dir. This type of backup 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.
48
Retention Period for Old Backups

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 non-incremental backups only. For example, to keep backups for up to a week max, use a value of 168 (hours).
Do not store any custom files under the target backup directory, since the backup cleanup processes may wipe them!
Email Notifications
It is possible to select that any problem encountered during backup will be automatically reported to all Artifactory administrators by email.
Backup Directory
Backups are created by default under the $ARTIFACTORY_HOME/backup/<backup_key> directory. If you wish to use another directory for storing backups change the target directory, otherwise leave it empty to use the defaults.
Importing and Exporting

Overview
Artifactory supports import and export of data on two levels: system-level and repository-level. On the system-level, Artifactory can export and import the whole Artifactory server - configuration, security information, stored data and metadata. The format used is identical to the system backup format. This is useful for manually running backups and for migrating and restoring a complete Artifactory instance (this is an alternative for using database level backup restore). On the repository-level, Artifactory can export and import repository stored data and metadata. This is useful for moving store data, including its metadata between repositories and for batch population of a repository.
System Import and Export

System import and export can be access through Admin:Import & Export:System
49
The source/target of the import/export operations are folders (or a zip archives - 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:
50
Import or exporting a big amount of data may take some time to complete. You do not necessarily have to watch the page and wait for the operation to finish - you can instead view the logs to determine when import/export completed ( Admin:Advanced:System Logs).
Repositories Import and Export

System import and export can be access through Admin:Import & Export:Repositories
51
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 even 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 if to import multiple repositories ('All Repositories') or a single one.
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 you select should be similar to:
52
SELECTED_DIR | |--LIB_DIR_1
When importing all repositories, the file structure within the folder you select should be similar to:
SELECTED_DIR | |--REPOSITORY_NAME_DIR_1 | | | |--LIB_DIR_1
When importing all repositories, make sure that the names of the directories that represent the repositories in the archive, match the names of the target repositories in Artifactory.
Mail Server Configuration

Overview
Some features in Artifactory require sending outgoing mail to recipients. These features include, for example: watch notifications, alerts for backup warnings and errors, license violation notifications etc. For mail sending to work a mail server needs to be properly configured in Artifactory.
Setup
The mail server configuration is accessible via Admin:Configuration:Mail. Set up is straightforward and can be verified by sending a test mail message from the UI.
Configuration Files
53
Configuration Files Location

All Artifactory configuration files are located under the $ARTIFACTORY_HOME/etc folder. On Unix $ARTIFACTORY_HOME is usually a soft link to /etc/artifactory.
Specific Configuration Files

The following sections contain detailed information about 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 that is bundled with Artifactory contains a sensible defaults configuration, that can be changed via the Administration UI. Once Artifactory loads the artifactory.config.xml file, it renames the original file to artifactory.config.bootstrap.xml, and from now on, configuration is stored internally in Artifatcory's storage. This is done on purpose, to make sure 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.startup.xml file as a backup.
Direct Use of the Global Configuration Descriptor

The raw global configuration descriptor itself can be retrieved and manipulated through Artifactory's UI, or by using Artifactory's REST API.
Directly editing the global configuration descriptor is an advanced feature that can wipe all your configuration! Please make sure you know what you are doing and keep a backup of the configuration.
Getting or Saving the Global Configuration Descriptor through the UI

Go to Admin:Advanced:Config Descriptor and copy the security configuration from the text area.
54
Getting and Saving the Global Configuration Descriptor through REST API
To retrieve configuration send a GET request to http://<host>:<port>/artifactory/api/system/configuration, e.g.:
curl -u admin:password -X GET -H "Accept: application/xml" http://localhost:8080/artifactory/api/system/configuration
To set configuration send a POST request to http://<host>:<port>/artifactory/api/system/configuration with the 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 need to 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.import.xml file containing the Artifactory configuration descriptor. Once Artifactory sees this file at startup, it will use the information in the file to override its global configuration. This can be useful if you wish to copy configuration 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 UI, or by using Artifactory's REST API.
55
Directly editing the security configuration descriptor is an advanced feature that can wipe all your security configuration! Please make sure you know what you are doing and keep a backup of the configuration.
Getting or Saving the Security Descriptor through the UI

Go to Admin:Advanced:Security Descriptor and copy the security configuration from the text area.
Getting and Saving the Security Descriptor through REST API

To retrieve configuration send a GET request to http://<host>:<port>/artifactory/api/system/security, e.g.:
curl -u admin:password -X GET -H "Accept: application/xml" http://localhost:8080/artifactory/api/system/security
To set configuration send a POST request to http://<host>:<port>/artifactory/api/system/security with the 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/security
Note that you need to 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 $ARTIFACTORY_HOME/etc/security.import.xml file that contains Artifactory-exported security information.
56
Once Artifactory sees this file at startup, it will use the information in the file to override all security settings. This can be useful if you wish to copy security configuration between different Artifactory instances.
System Properties
artifactory.system.properties
Artifactory includes a convenience method for specifying system properties. Instead of having to configure properties in the JVM runtime configuration of the hosting container, you can edit the $ARTIFACTORY_HOME/etc/artifactory.system.properties file and restart Artifactory. Artifactory-specific properties start with the artifactory. prefix, and their meaning is documented in comments in the default artifactory.system.properties file. As these settings affect the whole 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.).
Setting properties in artifactory.system.properties is an advanced feature, and is typically not required. Do not confuse these setting with the ones in the $ARTIFACTORY_HOME/data/artifactory.properties file, which are for internal use.
Exposing Maven Indexes

Overview
Artifactory can exposes Maven indexes for use by Maven integrations of common IDEs (IntelliJ IDEA, NetBeans, Eclipse).
Artifactory's search and indexing facilities are not related to Maven indexes The indexing done by Artifactory is secure, immediately effective and supports a larger variatiy 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 having access to the repository's index, regardless of any effective path permission you have in place. If that's a concern, do not expose an index for that repository.
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 will calculate one locally, based on the remote repository's already cached artifacts.
Usage
To administer Maven indexes go to Admin:Services:Indexer. You can control how often local indexing calculation and remote index fetching will run and what repositories will be included in index calculation.
57
Indexing can be expensive Please note that calculating and index 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 you do not need indexing for in the period index calculation.
The artadmin Command Line Tool

Overview
The artadmin tool is Artifactory's command line interface tool. It enables users to execute different Artifactory administrative tasks and can be run on Windows and Un*x. The artadmin tool is located at: $ARTIFACTORY_HOME/bin/artadmin (Unix), or $ARTIFACTORY_HOME/bin/artadmin.bat (Windows) The log file which artadmin produces can be found under $ARTIFACTORY_HOME/logs/cli.log. The commands that artadmin currently supports are divided into three groups: Commands which make use of artifactory REST API, thus requiring HTTP access to a working instance of Artifactory: 1. configuration - Display the system configuration file currently being used, or update it, providing a new one. 2. export - Export the full system to a destination on the host machine. 3. import - Import a full system from a destination on the host machine. 4. info - Display system information. 5. security - Display the security configuration file currently being used, or update it, providing a new one. Commands that are executed on Artifactory's home folder, thus requiring file system access to said folder, and in some cases, need for Artifactory to be shut down: 1. compress - Compress the database tables in order to free up disk space (supported only when using the Derby database) requires Artifactory to be shut down. 2. dump - Dump the database of an older version of Artifactory and convert it to an export format which is supported by the latest version - requires Artifactory to be shut down. This command was deprecated starting with Artifactory 2.1.
58
Misc commands: 1. help - Displays help information regarding the general and command-specific usage of the artadmin command.
Usage
The basic usage of the artadmin tool is:
artadmin <command> [arg] [options]
where: <command> - The name of the desired operation (info, dump, etc.). [arg] - The value of the mandatory argument (if the command requires one). [options] - Optional flags and parameters values. To print a list of available operations and short usage explanation, simply type on your console - artadmin. A message similar to the following, should appear: No command has been specified. Please specify a command. Artifactory Command Line Interface, version %VERSION% (rev. %REVISION%). 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 a running artifactory instance data into host destination path import: Import full system from host path dump: Dump the database of an older version of an offline artifactory instance to the latest export format compress: Compress the (Derby only) tables in order to free up disk space. security: Display or update the security definitions using a security configuration file. configuration: Print or update the artifactory configuration using a configuration file. Artifactory is a Maven repository. For additional information, see http://artifactory.jfrog.org To print a list of supported flags, parameters and a short usage explanation for a specific operation, use the following command:
artadmin help <command>
While substituting - <command> for a name of an actual command. For example, run the help command on the dump operation:
artadmin help dump
The execution of this command should produce a message similar to: dump: Dump the database of an older version of an offline artifactory instance to the latest export format usage: dump [artifactory home folder] ... Artifactory will try to automatically determine the previous version from $ARTIFACTORY_HOME/webapps/artifactory.war file if present. If this file does not exist, please specify one of the following as a --version 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 1.3.0-beta-6 1.3.0-beta-6.1 1.3.0-rc-1 1.3.0-rc-2 Valid options: --dest [destination folder]: The destination folder for the new export files. Default: dumpExport --version [version name]: The version of the old artifactory if it cannot be automatically determined --verbose: Display maximum execution details. Default: false --repos [repo names separated by ':']: Export only a specified list of repositories. Default: all-non-cached --caches: Include cached repositories in the export (by default caches are not exported). If the repos option is used this
59
option will be ignored. Default: false --security: Only dump a security definitions file, and no repositories. Default: false --noconvert: Do not auto convert local repository names of artifactory v1.2.5 and earlier to Virtual repositories. Default: false
Clustering Artifactory
Artifactory Active/Passive Architecture Overview
Artifactory Active/Passive architecture allows achieving High Availability and fast disaster recovery. Artifactory supports two types of such HA architectures: (1) Deployment on fault-tolerant storage; or (2) Periodical cross-server data sync. We strongly recommend the former option.
Deployment on fault-tolerant storage

Using a fault-tolerant disk that can be 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 other machine can immediately mount the storage, bootstrap Artifactory from it and start accepting requests instead of the failing one. A recommended way to achieve this setup quickly and efficiently is to use the built-in Virtual Machine Failover feature offered by virtualization software providers as part of their HA solution. 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 replicating correctly 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. The simplest way to achieve it is to perform rsync command on $ARTIFACTORY_HOME, excluding the unneeded directories Heres a simple example of such 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 that case the rsync-excludes.txt file will look like:
/work/ /data/tmp*/ /data/cache/ /data/index/ /data/version/ /data/workspaces*/ /logs/
Please note: the rsync should be executed from the passive standby server.
60
Syncing the database

Please note: The database replication needs to run before executing rsync. 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 DB to synchronize the DB and filestore state. In that case 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 standby server is very important to sync timewise between the metadata, stored in the database and the data, stored on the file system. An straightforward way to achieve this, is to make sure the DB is in a state that is prior to the file system (data/filestore) state. So, you can: Make a DB dump before executing filesystem sync, Activate DB replication on demand just before executing rsync. Since the sync operations arent atomic it might be a gap between the data from rsync, and data from DB replication. It is worth mentioning two points in this concern: 1. The time snapshot that Artifactory is set is the database replication time. 2. Items synced to the filesystem which have no representation in the database can be purged by clicking on Prune Unreferenced Data under Admin:Advanced:Maintenance in the Artifactory UI.
The Artifactory Log Files

Overview
Artifactory log files are under the ARTIFACTORY_HOME/logs folder. The following log files are available: artifactory.log - The main Artifactory log file that contains output about the Artifactory server activity. access.log - Security log that contains 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 Apache HTTPd's request log. import-export.log - A log used for tracking the process of long-running import and export commands.
Tomcat/Servlet container-secific log files When running Artifactory iside and existing servlet container, the container typically has its own log files. These files normally contain additional information to the information in artifactory.log or application bootstrapping-time information that is not part of the Artifactory logs. In Tomcat these files are catalina.out and localhost.yyyy-mm-dd.log, respectively.
Configuring Log Verbosity

Artifactory relies on the (great) Logback framework for its logging. Logger configuration can be changed in the Logback file: ARTIFACTORY_HOME/etc/logback.xml.
Viewing Log Files from the UI

Artifactory support monitoring log files from the UI, as well as downloading the current log files from the browser. Log files are viewable from Admin:Advanced:System Logs. You can select which log to tail or download from the drop-down menu.
61
The log tail view is automatically refreshed every couple of seconds.
Do not leave the log view open in your browser unnecessarily, to save on system resources.
System Information
Overview
Admin users can view Artifactory system information under Admin: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.
62
Working with Maven

Overview
There are two aspects to configuring Maven for use with Artifactory (or with any repository, for that matter): 1. Setting up Maven for resolving 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 UI, by going to Home:Maven Settings. Simply generate and save the settings.xml file into your Maven home directory.
The following sections describe in more detail important aspects of the configuration.
Provisioning Dynamic Settings for Users

You can deploy and provision a dynamic settings template for your users. Once downloaded, settings will be generated on the fly according to your own logic and can automatically include user authentication information. Please see the Provisioning Build Tool Settings section under Filtered Resources.
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 will make Artifactory look 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 look like: <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 will be ever sent directly to them.
63
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> <enabled>false</enabled> </releases> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>central</id> <url> http://[host]:[port]/artifactory/plugins-release </url> <snapshots> <enabled>false</enabled> </snapshots> </pluginRepository> <pluginRepository> <id>snapshots</id> <url> http://[host]:[port]/artifactory/plugins-snapshot </url> <releases> <enabled>false</enabled> </releases> </pluginRepository> </pluginRepositories>
Additional "Mirror-any" Setup

You can also use the "mirror any" feature on top of the previous setup, and have Artifactory act as a redirecting proxy for any Maven repository, including ones defined inside POMs of plug-ins and of third party dependencies (which is bad practice, but unfortunately, not uncommon). This will make sure no unexpected requests will be 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
Don't use "mirror any" by itself, 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 will supersede, but not hide, the built-in central and snapshots repositories, 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 turn off the Global Anonymous Access flag (Admin:Security:General) and use secure downloads with Maven. Users will have to
64
have Read access on repositories they wish to resolve artifacts from. You will also have to make sure your settings.xml file contains a server definition with the repository id used for artifacts resolution (downloads) and with valid user name and password. Artifactory offers a unique feature that makes sure you do not have to use clear text passwords in your settings, so it is highly recommended to use this feature.
Synchronizing Authentication Details for Same-URL Repositories When using authenticated downloads Maven will use the user name and password defined in your settings.xml to authenticate 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 the same URL, Maven will take the authentication details (from the matching server definition) of the first repository encountered and will use 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 settings.xml if they are going to be used by same-URL repositories.
Watch the Screencast
Configuring Deployment
Setting Up a Deployment Descriptor
In order to deploy to Artifactory you need to 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 a bit easier by providing you the "Distribution Management" snippet when selecting a local repository in the tree view (Browse:Tree Browser).
65
Remember that Virtual Repositories are, well... virtual. They cannot be deployed to or used inside a deployment descriptor.
Setting Up Security
For deploying, unless anonymous deployments are allowed on the target local repository (which is unlikely), you will also have to make sure your settings.xml file contains a server definition with the repository id used in the distributionManagement and with a valid deployer user name and password. Artifactory offers a unique feature that makes sure 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
In order for Gradle to work with Artifactory, all that is needed is a properly configured build.gradle script file. Instead of dwelling on configuration details we will just mention the main configuration steps and show a sample Gradle script that we believe shows all the required information that's needed to get you started. It also demonstrates the effectiveness and brevity of Gradle For your information, this build script is used for building the 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:

Manual Configuration Steps
66
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 Gradle Artifactory Plugin for publication
1. 2. 3. 4. 5. 6.
Define the Artifactory repository that will 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 will 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 which will be used for POM deployment (typically this would be the same as the one used for Gradle/Ivy artifacts).
Sample Build Script and Properties
67
build.gradle
usePlugin('java') usePlugin('maven') group = 'org.jfrog.buildinfo' version = '1.0' /* (5) */ def def def
Define the Maven attributes that will be used for POM auto-generation artifactId = projectDir.name groupId = group 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 } } }
And the properties file under the same directory:
68
gradle.properties
HOST=localhost REALM=Artifactory Realm USER=admin PASSWORD=password
Running Gradle
The following clause is needed for gradle to recognize Artifactory To build your project and upload the generated artifacts to Artifactory, simply run:
gradle uploadArchives
Please refer to the Gradle documentation for more detailed information on building with Gradle (running sub-tasks etc.).
Getting Debugging Information from Gradle

If you experience problems, it is highly recommended to run Gradle with the -d option. This typically provides useful readable information on what went wrong.
Dependency Declaration Snippets

You can use the Artifactory UI 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
69
Overview
Artifactory offers full integration with Gradle via two alternative ways: 1. Build Server Integration - When running Gradle builds in you continuous integration build server, it is recommended you use one of the Artifactory Plugins for Jenkins, TeamCity or Bamboo to configure resolution and publishing to Artifactory with build-info capturing, via your build server UI. 2. Standalone Integration - Which is the method described on this page, 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: a. Define default dependency resolution from Artifactory b. Define configurations whose artifacts will be published to Artifactory after a full (multi-module) successful build c. Define properties that will be attached to published artifacts in Artifactory metadata d. Capture and publish a build-info object to Artifactory build-info REST API to provide a fully traceable build context
Gradle Compatibility
Plugin Version 2.0.4 2.0.5 2.0.6 2.0.10 2.0.11 2.0.12 Compatible with Gradle gradle-1.0-milestone-3 gradle-1.0-milestone-4 gradle-1.0-milestone-3 gradle-1.0-milestone-6 gradle-1.0-milestone-7 gradle-1.0-milestone-8 and above
Downloading and Installing the Artifactory Plugin

Manual Installation
The latest plugin jar file can be downloaded from here and copy it to your gradle home plugins directory ~/.gradle/plugins. And add the following to your project:
buildscript.dependencies.classpath files(new File(gradle.gradleUserHomeDir, 'plugins/build-info-extractor-gradle-2.0.12-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 { classpath(group: 'org.jfrog.buildinfo', name: 'build-info-extractor-gradle', version: '2.0.12') } }
The above script will automatically download the plugin, and make it available to the buildScript of your projects.
70
Adding the Plugin to Your Project(s)

In order to apply the plugin in your Gradle projects, the following closure needs to be declared in your build.gradle script:
apply plugin: 'artifactory'
In a multi-project build, you'd 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 build.gradle script of your root project. The syntax of the Convention DSL is described below.
Mandatory items within the relevant context are prefixed with '+'. All other items are optional.
71
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 by default) publishIvy = false //Publish generated Ivy descriptor files to Artifactory (false by default) } } resolve { contextUrl = 'http://repo.myorg.com/artifactory' //The base Artifactory URL for 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 = ... } } } }
72
The Properties Closure DSL

The properties closure in artifactory.publish.defaults and artifactpryPublish task accept the following syntax:
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 all to apply the properties to all configurations. 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 'artifactoryPublish' Gradle task for each project the plugin is applied to. The artifactoryPublish is configured by the publish closure of the plugin. You can configure the project-level task directly with the task's artifactoryPublish closure, which uses identical Syntax to that of the plugin's publish closure.
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, will be published to Artifactory you can: 1. Do not apply the 'artifactory' plugin to project should not publish anything. Note: This cannot be done for the root project that contains the convention object, and so needs the plugin applied. 2. Manual activate the corresponding 'artifactoryPublish' Gradle task for each project you wish to. For example in our Gradle project example you can run: ./gradlew clean api:artifactory:publish shared:artifactoryPublish 3. Use the artifactoryPublish.skip flag to deactivate analysis and publication.
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.

To see the Gradle Artifactory Plugin in action you can watch the following screencast below.
Gradle Artifactory Plugin using the snapshot version

Downloading and Installing the snapshot version of the Artifactory Plugin
73
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 { classpath(group: 'org.jfrog.buildinfo', name: 'build-info-extractor-gradle', version: '2.0.x-SNAPSHOT') } configurations.classpath { resolutionStrategy { failOnVersionConflict() cacheDynamicVersionsFor 0, 'seconds' cacheChangingModulesFor 0, 'seconds' } } }
The above script will automatically download the plugin, and make it available to the buildScript of your projects.
Working with Ivy

Setting up Ivy to work with Artifactory
In order to make Ivy work with Artifactory, the following files must be present and configured: 1. The Ivy settings - ivysettings.xml - used to configure artifact resolution and deployment using repositories in Artifactory. 2. The Ivy modules - ivy.xml - where the project's modules and dependencies are declared. 3. The Ant build - build.xml - which is used to execute the ANT tasks that will, in turn, use Ivy for artifact resolution and deployment.
Ivy Settings - ivysettings.xml

The ivysettings.xml file holds a chain of Ivy resolvers which are used for both resolution and publishing (deployment). Resolvers exist for both regular artifacts and Ivy module files. There are a couple of options to set up Ivy to work with Artifactory by configuring resolvers in ivysettings.xml: 1. Automatically using the Artifactory's Ivy settings generator, or 2. By manually defining Ibiblio and URL resolvers.
Automatic Settings with Artifactory's Ivy Settings Generator

As an easy quick start, you can use Artifactory's Ivy settings generator to define credentials and resolver settings. This will generate a URL resolver suitable for both deployment and resolution.
74

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 root URL needs to point at an Artifactory repository. In this case, the pre-configured 'libs-releases' virtual repository. The m2compatible property pre-configures the resolver with an artifact pattern that follows the Maven 2 standard layout.
The URL Resolver

The URL resolver can be used for dependency resolution and/or deployment of both regular artifacts and Ivy module files. 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.:
75
 <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]/[revision]/[artifact]-[revision].[ext] <ivy pattern="http://localhost:8080/artifactory/libs-snapshot-local/[organization]/[module]/[revision]/ivy-[revision].xml" /> </url> </resolvers>
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 fine with remote Artifactory servers.
Using a Chain Resolver

You can mix resolvers under a chain resolver in Ivy which will use sub-resolvers for dependency resolution and publishing. Please refer to the relevant Ivy documentation.
Ivy Modules - ivy.xml

ivy.xml files contain a list of dependency declarations that are needed to be resolved for the build. You can use the Artifactory UI to 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.
76
Ant Build - build.xml

To work with Ivy for dependency resolution you need to use <ivy:configure/> in your build.xml file. This will load the ivysettings.xml. The resolution of artifacts is done using <ivy:retrieve/>. Please consult the Ivy documentation for more detailed information.
Publishing to Artifactory
In order to publish to Artifactory the <ivy:publish> command needs to be used. Ivy will use the configured resolver to deploy your artifact into Artifactory. For example:
<ivy:publish resolver="artifactory-publish" overwrite="true"> <!-Use overwrite="true" if you wish to overwrite existing artifacts and publishivy="false" if you only want to publish artifacts not module descriptors --> <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 publish element:
77
settingsRef="ivy.pub.settings"
Please consult the Ivy documentation for more detailed information.
Searching the Content of Ivy Modules

You can search the content of Ivy modules in Artifactory. From Artifacts:POM/XML Search select the name you use for Ivy modules (typically ivy.xml) and use an XPath query to define your search. For example:
Support for other Ivy file patterns Though ivy.xml is the common name for Ivy modules, Ivy does not mandate a standard name. Out of the box *.ivy is also supported, and you can instruct Artifactory to index other file extenstion by editing the application/x-ivy+xml entry in $ARTIFACTORY_HOME/etc/mimetypes.xml.
Using Artifactory
Overview
This section covers the following usage scenarios: Browsing Artifactory Attaching and Reading Metadata Deploying Via the Web UI Searching Artifacts Manipulating Artifacts Updating Your Profile Artifactory's REST API
Browsing Artifactory
Overview
Artifactory provides two modes for browsing repositories: Tree Browsing and Simple Browsing. Both browsing modes fully enforce the defined security rules to make sure you can do only permitted actions and see just the information you are allowed to see.
78
The default local URL when running Artifactory standalone 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.
Tree Browsing
The Tree Browser (Artifacts:Tree Browser) provides rich information about repository items. For each selected artifact/folder/repository on the tree a tabbed panel offers detailed data views. Part of these data are action that can be performed on the selected item:
Viewing Maven Metadata and POMs

Artifactory provides ad-hoc views for maven metadata (maven-metadata.xml and POM files pom.xml as dedicated tabs when selecting the relevant tree item. POM view
79
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 a lightweight, view-only browsing. A unique features provided by this browsing mode is the ability to browse virtual repositories content in a consolidated way and see from each physical repository/s every folder and artifact is coming from.
80
List Browsing
List Browsing provides the most lightweight, read-only view and it is very similar to simple directory listing provides by HTTP servers. To get to 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 a system administrator to create a virtual host that only exposes Artifactory's List Browsing feature to public users, while keeping all write and advanced, but potentially expensive UI and REST features (such as searches), for internal use.
Remote Browsing
Remote browsing provides the ability to navigate the contents of the remote repository even if the artifacts have not been cached locally yet.
81
To see the contents of a remote repository, make sure that "List Remote Folder Items" is checked in the remote repository configuration, and simply navigate via the the Simple Browser or List Browser the the remote repository. An item (folder or artifact) that has not been cached yet will have a small globe icon to its right in the Simple Browser:.
In the List Browser a non-cached item will have an arrow to its right:
Initial remote browsing may be slow Initial remote browsing may be slow, especially when browsing a virtual repository that contains multiple remote repositories. Remote content is cached according to the "Retrieval Cache Period" defined in the remote repository configuration panel.
WebDAV Browsing
Any local or cache repository may be mounted as a secure WebDAV share, and made browsable from any WebDAV-supporting file manager, simply by referencing the URL of the target repository. For example: http://host:port/artifactory/repo-path.
Attaching and Reading Metadata

Overview
Artifactory lets you attach metadata to any file or folder. You can attach an unlimited amount of metadata, where each metadata is identified by a logical name. Metadata is stored as XML and is fully searchable out-of-the-box using XPath expressions.
The Properties Add-on

You can also use the Properties add-on to dynamically define and add more strongly-typed metadata that can be attached and searched more conveniently through web UI.
Attaching Metadata
Attaching meta data is a matter of sending the XML content of the metadata via a PUT request, to the metadata container (file or folder in a repository).
82
The metadata name is appended with colon (':') to the path of its container:
path/to/container:sample-metadata
A full REST request using curl, would be, for example:
curl -X PUT -H "Content-Type: application/xml" -u user:password --data-binary @sample-metadata-file.xml \ http://localhost:8080/artifactory/libs-release-local/ch/qos/logback/logback-classic/0.9.9/logback-classic-0.9.9.jar:s
To write (or delete) metadata you need to have deploy permissions on the metadata container.
Reading and Deleting Metadata

Via Web UI
You can view and remove metadata via Artifactory's web UI. Simply, go to Artifacts:Tree Browser, select the metadata container and then the 'Metadata' tab:
Via REST
To read metadata with REST, send a GET request to the metadata URL. E.g.:
curl -X GET -H "Accept: application/xml" -u user:password \ http://localhost:8080/artifactory/libs-release-local/ch/qos/logback/logback-classic/0.9.9/logback-classic-0.9.9.jar:s
To read metadata you need to have read permissions on the metadata container.
83
To delete metadata via REST, simply send a DELETE request to the metadata URL. E.g.:
curl -X DELETE -u user:password \ http://localhost:8080/artifactory/libs-release-local/ch/qos/logback/logback-classic/0.9.9/logback-classic-0.9.9.jar:s
Metadata XPath Searching

Please see the POM and XML Search section for how to search metadata with XPath.
Deploying Via the Web UI

Overview
Artifactory offers UI based deployments in two forms: 1. Uploading and deploying a single artifact 2. Uploading and deploying a bundle of artifacts
For deploying/importing whole repositories, you may want to use the Import Repository feature under Admin:Import & Export:Repositories
Deploying a Single Artifact

Single-artifact deployment is done from Deploy:Single Artifact. Deployment is a two-step process: 1. In the first step you simply upload an artifact file to Artifactory. 2. After you've uploaded the file Artifactory will try to 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 META-INF directory, this information will be used.
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 will make will be 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 don't have to follow the Maven repository layout convention, you can turn off the Deploy as Maven Artifact and edit the target deployment path manually. Once you are happy with the deployment details, click the Deploy Artifact button to deploy the artifact into Artifactory.
84
Why was my deployment rejected? Deployment can fail for various reasons, as whole or partially. The most common reasons for 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 done from Deploy:Artifacts Bundle. This is a very convenient feature for deploying multiple artifacts in one go. Artifacts should be packaged in a zip archive and contained in the file structure that they should be deployed with. For example, the structure of the (partial) zip for Hibernate will look like this:
orghibernatehibernate3.3.2GAhibernate-3.3.2.GA.pom hibernate-3.3.2.GA.jar hibernate-entitymanager3.3.2GAhibernate-entitymanager-3.3.2.GA.pom hibernate-entitymanager-3.3.2.GA.jar
Uploading and deploying the zip is a single step which ends with all zipped artifacts deployed into the selected repository.
85
Searching Artifacts
Artifactory offers quick search 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 get further information on it.
Searches in Artifactory are immediate and, unlike some repository managers, always reflect the current state of the repository. This means that whatever you deployed is available in search results right away and whatever you un-deployed will not be displayed. There is no need to rebuild indexes periodically.
Quick Search
Overview
Artifactory allows you to perform simple searches on artifacts.
Searching
The search is available under Artifacts:Simple Search. Or from the simple search field in the upper right-hand. You can enter the name of the artifact, or a part of the name of the artifact which you wish to search. For example, you can use the following search to find all artifacts with "antlr-2.7.2" as a part of its name:
86
Class Search
Overview
Artifactory allows you to perform class searches on aritfacts for specific classes.
Searching
The search is available under Artifacts:Class Search. You need to 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:
POM and XML Search

Overview
Artifactory allows you to perform XPath searches on POMs or on any XML metadata (attached to files and folders).
87
XML Searches and Indexing is Turned-off by Default Starting from Artifactory 2.4.0, XML indexing and the XPath searches are disabled by default for performance reasons. In case of an upgrade to 2.4.0, any XML artifacts deployed post-upgrade will not be searchable (although existing ones will still be). XML indexing can be re-enabled by setting the property artifactory.search.xmlIndexing to true in $ARTIFACTORY_HOME/etc/artifactory.system.properties. In this case artifacts deployed prior to enabling XML indexing will not be index, so you will need to redeploy/reimport them.
Searching
The search is available under Artifacts:POM/XML Search. You can enter the name of the metadata, the XPath to the value in the XML you wish to search and the value itself. For searching POMs, simply uncheck the 'Metadata Search' checkbox. For example, you can use the following search to find all POMs with a version of '1.6':
The 'Smart Searches' add-on allows you to slice and dice multiple items found in multiple search results in one go.
The 'Properties' add-on allows you to perform more powerful searches, using custom properties and simpler interface to define and aggregate search values.
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 Artifacts:Property Search. You need to 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":
88
Property Search is part of the Properties add-on features.
GAVC Search
Overview
Artifactory allows you to perform searches for artifacts by specifying their groupId, artifactId, version, and classifier.
Searching
The search is available under Artifacts: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 groupId:antlr, artifactId:antlr and version:*.7.6 as part of the artifact specification:
89
Checksum Search
Overview
Artifactory allows you to search artifacts by their sha1 or md5 checksum.
Searching
The search is available under Artifacts:Checksum Search. You need to enter the sha1 or md5 checksum value of the artifact you wish to find. For example, you can use the following search to find artifact with checksum value of 'c5c499f1eef9367c657e89bb881c69aa':
Manipulating Artifacts
Overview
Artifactory supports true un-deployment of artifacts, in contrast to naive removal of repository files and folders. This means that the maven-metadata.xml descriptors inside the repository will be immediately updated to reflect the removal of artifacts, ensuring consistent operation with Maven clients. Artifactory does not only provide simple artifact removal, but also a powerful way to clean up complete versions from the repository. This section covers these options: Removing Single Items Cleaning-up Complete Versions Moving Artifacts
Removing Single Items
90
Removing an artifact or a folder of artifact can be done by selecting the item from the UI in the Tree Browser ( Browse:Tree Browser) and selecting the Remove operation, either from the tabbed-panel or from the right-click drop-down menu. Once removed, the respective maven-metadata.xml affected by the removal will be updated accordingly (unless removed from a remote cache) and the removed artifacts will not be returned by search results.
Cleaning-up Complete Versions

Overview
It is common for a repository to accumulate over time 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. Artifactory realizes that and provides an out-of-the-box solution for cleaning up old versions.
Performing Versions Cleanup

Removing a version can be done by selecting a folder in the Tree Browser UI (Browse:Tree Browser) and selecting the Remove Versions operation. Artifactory will perform a deep-scan of the folder and will come back with a list of all the groups and versions available for deletion. Just select the versions you wish to clean up and that's it!
Moving Artifacts
You can move artifacts or folders from the tree browser (Artifacts:Tree Browser), by using the move action button or by right-clicking the item.
91
Before moving, you need to select the target repository to move to. You may also preform a 'Dry Run' to make sure 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 move is complete you are guaranteed that all metadata is consistent and that Maven-specific metadata is recalculated to reflect the move results.
Make Sure You Have Sufficient Permissions Since moving implies deleting the original item from one repository and creating it on another repository, you have to have DELETE permissions and DEPLOY permissions for the moved item's path in the source and target repositories, respectively.
Updating Your Profile

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 corner of the screen. After entering your password a profile edit panel will appear.
You will not be able to change your password if external authentication, such as LDAP, is used by Artifactory.
92
For more information about using secured passwords with your profile, please read this.
Artifactory's REST API

WADL
Artifactory exposes its REST API through an auto-generated WADL file (courtesy of the excellent Jersey REST framework). This provide an extremely 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
Below please find 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 CONTENT
93
BUILDS All Builds Build Runs Build Info Build Promotion Build Move (Deprecated) Build Copy (Deprecated) Delete Builds Build Rename ARTIFACTS & STORAGE Folder Info File Info Item Last Modified Item Metadata Names Single Metadata Item Metadata Info (Deprecated) Delete Single Metadata Set Single Metadata Item Properties Set Item Properties Delete Item Properties Retrieve Artifact Trace Artifact Retrieval Archive Entry Download Create Directory Deploy Artifact Deploy Artifact by Checksum Deploy Artifacts from Archive 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 XPath Search Checksum 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 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
94
Delete Repository Remote Repository Configuration Calculate YUM Repository Metadata Calculate Maven Index SYSTEM & CONFIGURATION System Info System Health Ping General Configuration 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: All builds info Since: 2.2.0 Security: Requires a privileged user (can be anonymous) Usage: GET /api/build Produces: application/vnd.org.jfrog.build.Builds+json 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 Since: 2.2.0 Security: Requires a privileged user (can be anonymous) Usage: GET /api/build/{buildName} Produces: application/vnd.org.jfrog.build.BuildsByName+json Sample output:
95
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 Since: 2.2.0 Security: Requires a privileged user (can be anonymous) Usage: GET /api/build/{buildName}/{buildNumber} Produces: application/vnd.org.jfrog.build.BuildInfo+json Sample output:
GET /api/build/wicket/51 { "uri": "http://localhost:8080/artifactory/api/build/wicket/51" "buildInfo" : { ... } }
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). Since: 2.3.3 Notes: Requires Artifactory Pro Security: Requires a privileged user (can be anonymous) Usage: POST /api/build/promote/{buildName}/{buildNumber} Consumes: application/vnd.org.jfrog.artifactory.build.PromotionRequest+json
96
POST /api/build/promote/wicket/51 { "status": "staged" // new build status ("staged" | "released" | "rolled-back") "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...." },... ] }
Build Move (Deprecated)
Description: Move produced artifacts and dependencies from a certain build to a different repository. Optionally, you can also set properties on the artifacts promoted. All artifacts from all scopes are included by default while dependencies are not. Scopes are additive (or). Since: 2.2.3 Notes: This API is deprecated. Use the Build Promotion API instead. Requires Artifactory Pro Security: Requires a privileged user (can be anonymous) Usage: POST /api/build/move/{buildName}/{buildNumber}?to={targetRepoKey}[&started=ISO8601][&arts=includeArtifacts][&deps=includeDependencies][&scopes=includedSco Produces: application/vnd.org.jfrog.artifactory.build.PromotionResult+json Sample output:
POST /api/build/move/wicket/51?to=libs-release-local&arts=1&deps=1&scopes=compile,runtime&properties=components=c1,c3,c14| : [ { "level": "error", "message": "The repository has denied...." },... ] }
97
Build Copy (Deprecated)
Description: Copy produced artifacts and dependencies from a certain build to a different repository. Optionally, you can also set properties on the artifacts promoted. All artifacts from all scopes are included by default while dependencies are not. Since: 2.2.3 Notes: This API is deprecated. Use the Build Promotion API instead. Requires Artifactory Pro Security: Requires a privileged user (can be anonymous) Usage: POST /api/build/copy/{buildName}/{buildNumber}?to={targetRepoKey}[&started=ISO8601][&arts=includeArtifacts][&deps=includeDependencies][&scopes=includedSco Produces: application/vnd.org.jfrog.artifactory.build.CopyOrMoveResult+json Sample output:
POST /api/build/copy/wicket/51?to=libs-release-local&arts=1&deps=1&scopes=compile,runtime&properties=components=c1,c3,c14| : [ { "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 artifacts parameter is evaluated as 1 (0/false by default), build artifacts will be removed too. If no buildNumbers parameter is specified removes the whole build! Since: 2.3.0; artifact removal since 2.3.3; Notes: Requires Artifactory Pro Security: Requires an admin user Usage: DELETE /api/build/{buildName}[?buildNumbers=n1[,n2]][&artifacts=0/1] Produces: application/text 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. Since: 2.2.5 Notes: Requires Artifactory Pro Security: Requires a valid user with deploy permissions Usage: POST /api/build/rename/{buildName}?to=newBuildName Produces: application/text Sample usage:
POST /api/build/rename/myJobName?to=myNewJobName Build renaming of 'myJobName' to 'myNewJobName' was successfully started.
98
ARTIFACTS & STORAGE Folder Info

Description: Folder Info For virtual use the virtual repository will return the unified children Since: 2.2.0 Security: Requires a privileged user (can be anonymous) Usage: GET /api/storage/{repoKey}/{folder-path} Produces: application/vnd.org.jfrog.artifactory.storage.FolderInfo+json Sample output:
GET /api/storage/libs-release-local/org/acme { "uri": "http://localhost:8080/artifactory/api/storage/libs-release-local/org/acme", "metadataUri": "http://localhost:8080/artifactory/api/storage/libs-release-local/org/acme?mdns", "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 will return the resolved file Since: 2.2.0 Security: Requires a privileged user (can be anonymous) Usage: GET /api/storage/{repoKey}/{filePath} Produces: application/vnd.org.jfrog.artifactory.storage.FileInfo+json Sample output:
99
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", "metadataUri": "http://localhost:8080/artifactory/api/storage/libs-release-local/org/acme/lib/ver/lib-ver.pom?mdns","repo": "libs-release-local", "path": "/org/acme/lib/ver/lib-ver.pom", "remoteUrl": "http://some-remote-repo/mvn/org/acme/lib/ver/lib-ver.pom", "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), "size": "1024", //bytes "mimeType": "application/pom+xml", "checksums": { "md5" : string, "sha1" : string }, "originalChecksums":{ "md5" : string, "sha1" : string } }
Item Last Modified

Description: Get the last modified item at the given path. If the given path is a folder, the latest last modified item will be searched for recursively. Since: 2.2.5 Notes: Requires Artifactory Pro Security: Requires a valid user with deploy permissions Usage: GET /api/storage/{repoKey}/{item-path}?lastModified Produces: application/vnd.org.jfrog.artifactory.storage.ItemLastModified+json 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-SNAPSHOT/foo-1.0-SNAPSHOT.pom","la ISO8601 }
Item Metadata Names

Description: Item Metadata Names Return the names of metadata entries attached to an item (file or folder). Since: 2.2.0 Security: Requires a privileged user (can be anonymous) Usage: GET /api/storage/{repoKey}/{itemPath}?mdns Produces: application/vnd.org.jfrog.artifactory.storage.ItemMetadataNames+json Sample output:
100
GET /api/storage/libs-release-local/org/acme.jar?mdns { "uri": "http://localhost:8080/artifactory/api/storage/libs-release-local/org/acme.jar", "metadata":{ "md1": { "uri": "http://localhost:8080/artifactory/libs-release-local/org/acme.jar:md1" }, "md2": { "uri": "http://localhost:8080/artifactory/libs-release-local/org/acme.jar:md2" } }
Single Metadata
Description: Retrieve the XML metadata from an item (file or folder). Since: 2.1.0 Security: Requires a privileged user (can be anonymous) Usage: GET /{repoKey}/{itemPath}:{metadata-name} Produces: application/xml Sample output:
GET [http://localhost:8080/artifactory/libs-release-local/ch/qos/logback/logback-classic/0.9.9/logback-classic-0.9.9.jar:
Item Metadata Info (Deprecated)

Description: Item Metadata Optionally return only the metadata keys requested. Notes: This API is deprecated. Use the Retrieve Single Metadata API instead. Since: 2.2.0 Security: Requires a privileged user (can be anonymous) Usage: GET /api/storage/{repoKey}/{itemPath}?md[=md1[,md2]] Produces: application/vnd.org.jfrog.artifactory.storage.ItemMetadata+json Sample output:
GET /api/storage/libs-release-local/org/acme?md\[=md1[,md2]\] { "uri": "http://localhost:8080/artifactory/api/storage/libs-release-local/org/acme", metadata:{ "md1" : { json object containing the streamed xml of md1 }, "md2" : { json object containing the streamed xml of md2 } } }
Delete Single Metadata

Description: Single Metadata - Delete Remove the XML metadata from an item (file or folder). Since: 2.1.0 Security: Requires a privileged user (can be anonymous) Usage: DELETE /{repoKey}/{itemPath}:{metadata-name} Sample usage:
DELETE http://localhost:8080/artifactory/libs-release-local/ch/qos/logback/logback-classic/0.9.9/logback-classic-0.9.9.jar:s
101
Set Single Metadata

Description: Attach an XML metadata to an item (file or folder). Since: 2.1.0 Security: Requires a privileged user (can be anonymous) Usage: PUT /{repoKey}{itemPath}:{metadata-name} Consumes: application/xml Sample usage:
PUT http://localhost:8080/artifactory/libs-release-local/ch/qos/logback/logback-classic/0.9.9/logback-classic-0.9.9.jar:s
Item Properties
Description: Item Properties. Optionally return only the properties requested. Since: 2.2.1 Security: Requires a privileged user (can be anonymous) Usage: GET /api/storage/{repoKey}/{itemPath}?properties[=x[,y]] Produces: application/vnd.org.jfrog.artifactory.storage.ItemProperties+json 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. Notes: Requires Artifactory Pro Since: 2.3.0 Security: Requires a privileged user (can be anonymous) Usage: PUT /api/storage/{repoKey}{itemPath}?properties=p1=v1[,v2][|p2=v3][&recursive=1] 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. Notes: Requires Artifactory Pro Since: 2.3.2 Security: Requires a privileged user (can be anonymous) Usage: DELETE /api/storage/{repoKey}{itemPath}?properties=p1[,p2][&recursive=1] Sample usage:
DELETE /api/storage/libs-release-local/ch/qos/logback/logback-classic/0.9.9?properties=os,qa&recursive=1
102
Retrieve Artifact
Description: Retrieves an artifact from the specified destination. Notes: You can also use property-based resolution as part of retrieving artifacts. Security: Requires a user with 'read' permission (can be anonymous) Usage: GET /repo-key/path/to/artifact.ext Sample output:
GET http://localhost:8080/artifactory/libs-release-local/ch/qos/logback/logback-classic/0.9.9/logback-classic-0.9.9.jar
Trace Artifact Retrieval

Description: Simulates an artifact retrieval request from the specified location and returns verbose output about the resolution process. This API is useful for debugging artifact retrieval issues. Security: As applied to standard artifact retrieval by the requesting user. Since: 2.6.0 Usage: GET /repo-key/path/to/artifact.ext?trace Produces: text/plain 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. Security: Requires a user with 'read' permission (can be anonymous) Usage: GET /repo-key/path/to/artifact.jar*!*/path/to/archived/resource (note the '!' between the archive file name and the archive entry path) Sample output:
GET http://localhost:8080/artifactory/repo1-cache/commons-lang/commons-lang/2.6/commons-lang-2.6.jar!/META-INF/LICENSE.tx
Create Directory
Description: Create new directory at the specified destination. Notes: You can also attach properties as part of creating directories. Security: Requires a user with 'deploy' permissions (can be anonymous) Usage: PUT /repo-key/path/to/directory/ Produces: application/vnd.org.jfrog.artifactory.storage.ItemCreated+json Sample usage:
103
PUT /libs-release-local/path/to/directory/ { "uri": "http://localhost:8080/artifactory/libs-release-local/path/to/directory", "repo": "libs-release-local", "path": "/path/to/directory", "created": ISO8601 (yyyy-MM-dd'T'HH:mm:ss.SSSZ), "createdBy": "userY", "children" : [ ] }
Deploy Artifact
Description: Deploy an artifact to the specified destination. Notes: You can also attach properties as part of deploying artifacts. Security: Requires a user with 'deploy' permissions (can be anonymous) Usage: PUT /repo-key/path/to/artifact.ext Produces: application/vnd.org.jfrog.artifactory.storage.ItemCreated+json 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", "repo": "libs-release-local", "path": "/my/jar/1.0/jar-1.0.jar", "created": ISO8601 (yyyy-MM-dd'T'HH:mm:ss.SSSZ), "createdBy": "userY", "size": "1024", //bytes "mimeType": "application/java-archive", "checksums": { "md5" : string, "sha1" : string }, "originalChecksums":{ "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 will be copied over to the new location and return a response without requiring content transfer. Otherwise, a 404 will be returned to indicate that content upload is expected in order to deploy the artifact. Notes: You can also attach properties as part of deploying artifacts. Security: Requires a user with 'deploy' permissions (can be anonymous) Usage: PUT /repo-key/path/to/artifact.ext Headers: X-Checksum-Deploy: true, X-Checksum-Sha1: sha1Value Produces: application/vnd.org.jfrog.artifactory.storage.ItemCreated+json Since: 2.5.1 Sample output:
104
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", "repo": "libs-release-local", "path": "/my/jar/1.0/jar-1.0.jar", "created": ISO8601 (yyyy-MM-dd'T'HH:mm:ss.SSSZ), "createdBy": "userY", "size": "1024", //bytes "mimeType": "application/java-archive", "checksums": { "md5" : string, "sha1" : string }, "originalChecksums":{ "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 done in a single HTTP request and only the exploded content will be deployed, not the archive file itself. Supported archive types are: zip; tar; tar.gz; and tgz. Please note that deployment of compressed archives (unlike tar) may incur considerable CPU overhead. Notes: Requires Artifactory Pro Security: Requires a user with 'deploy' permissions (can be anonymous) Usage: PUT /repo-key/path/to/archive.zip Headers: X-Explode-Archive: true Produces: text/plain Since: 2.6.3 Sample usage:
PUT /libs-release-local/archive.zip
Delete Item
Description: Deletes a file or a folder from the specified destination. Security: Requires a user with 'delete' permission (can be anonymous) Usage: DELETE /repo-key/path/to/file-or-folder Sample usage:
DELETE http://localhost:8080/artifactory/libs-release-local/ch/qos/logback/logback-classic/0.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 dry run. Copy item behaves similarly to a standard file system and supports renames. If the target path doesn't 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. Notes: Requires Artifactory Pro Security: Requires a privileged user (can be anonymous) Usage: POST /api/copy/{srcRepoKey}/{srcFilePath}?to=/{targetRepoKey}/{targetFilePath}[&dry=dryRun][&suppressLayouts=0/1][&failFast=0/1]
105
Produces: application/vnd.org.jfrog.artifactory.storage.CopyOrMoveResult+json Since: 2.2.2 Sample output:
POST /api/copy/libs-release-local/org/acme?to=/ext-releases-local/org/acme-new&dry=1 { "messages" : [ { "level": "error", "message": "The repository has denied...." },... ] }
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 doesn't 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. Notes: Requires Artifactory Pro Security: Requires a privileged user (can be anonymous) Usage: POST /api/move/{srcRepoKey}/{srcFilePath}?to=/{targetRepoKey}/{targetFilePath}[&dry=dryRun][&suppressLayouts=0/1][&failFast=0/1] Produces: application/vnd.org.jfrog.artifactory.storage.CopyOrMoveResult+json Since: 2.2.2 Sample output:
POST /api/move/libs-release-local/org/acme?to=/ext-releases-local/org/acme-new&dry=1 { "messages" : [ { "level": "error", "message": "The repository has denied...." },... ] }
Scheduled Replication Status

Description: Returns the status of scheduled cron-based replication jobs define via the Artifactory UI on repositories. Notes: Requires Artifactory Pro Security: Requires a user with 'read' permission (can be anonymous) Usage: GET /api/replication/{repoKey} Produces: application/vnd.org.jfrog.artifactory.replication.ReplicationStatus+json Since: 2.4.2 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 include metadata properties 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.
106
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. Notes: Requires Artifactory Pro Security: Requires a privileged user (can be anonymous) For non-admin users will replicate at max the number of files as defined by the artifactory.search.userQueryLimit system property. Usage: POST /api/replication/{srcRepoKey}/{srcPath} Consumes: application/vnd.org.jfrog.artifactory.replication.ReplicationRequest+json Since: 2.4.0 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", // 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 will be printed (by default every 1024 bytes). This is extremely useful if you wish to trigger downloads on a remote Artifactory server, for example to force eager cache population of large artifacts, but wish to avoid the bandwidth consumption involved in transferring the artifacts to the triggering client. If no content parameter is specified the file content will be downloaded to the client. Notes: This API is deprecated. Requires Artifactory Pro Security: Requires a privileged user (can be anonymous) Usage: GET /api/download/{repoKey}/{filePath}[?content=none/progress][&mark=numOfBytesToPrintANewProgressMark] Produces: application/octet-stream, text/plain (depending on content type) Since: 2.2.2 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). Notes: This API is deprecated. Requires Artifactory Pro Security: Requires a privileged user (can be anonymous) For non-admin users will replicate at max the number of files as defined by the artifactory.search.userQueryLimit system property. Usage: GET /api/sync/{remoteRepositoryKey}/{folderPath}[?progress=showProgress][&mark=numOfBytesToPrintANewProgressMark][&delete=deleteExistingFiles][&overwri Produces: text/plain Since: 2.2.4 Sample output:
107
GET /api/sync/my-remote/org/acme/1.0?progress=1&delete=1 ..................................................... ..................................................... ..................................................... .......................................... Completed: 970/1702 bytes ..................................................... .................. Completed: 1702/1702 bytes 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 (since 2.3.3). Optionally include a map of metadata timestamp values as part of the result (since 2.3.3). folder inclusion since 2.3.2; checksum inclusion since: 2.3.3; include folder root path since: 2.5.2. Since: 2.2.4 Notes: Requires Artifactory Pro Security: Requires a non-anonymous privileged user. Usage: GET /api/storage/{repoKey}/{folder-path}?list[&deep=0/1][&depth=n][&listFolders=0/1][&mdTimestamps=0/1][&includeRootPath=0/1] Produces: application/vnd.org.jfrog.artifactory.storage.FileList+json 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 "lastModified": ISO8601, "folder": "false", "sha1": sha1Checksum, "mdTimestamps": { "properties" : lastModified (ISO8601) } }, { "uri": "/archived/doc1.txt", "size": "253100", //bytes "lastModified": ISO8601, "folder": "false", "sha1": sha1Checksum, "mdTimestamps": { "properties" : lastModified (ISO8601) } },... ] }
SEARCHES
All searches return limited results (same limits as in the user interface) for anonymous users.
108
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). Since: 2.2.0 Security: Requires a privileged user (can be anonymous) Usage: GET /api/search/artifact?name=name[&repos=x[,y]] Produces: application/vnd.org.jfrog.artifactory.search.ArtifactSearchResult+json Sample output:
GET /api/search/artifact?name=lib&repos=libs-release-local { "results": [ { "uri": "http://localhost:8080/artifactory/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/ver2/lib-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). Since: 2.2.0 Security: Requires a privileged user (can be anonymous) Usage: GET /api/search/archive?name=[archiveEntryName][&repos=x[,y]] Produces: application/vnd.org.jfrog.artifactory.search.ArchiveEntrySearchResult+json Sample output:
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/jackrabbit/ jackrabbit-core/1.2.3/jackrabbit-core-1.2.3.jar", "http://localhost:8080/artifactory/api/storage/third-party-releases-local/org/apache/jackrabbit/ 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). Since: 2.2.0 Security: Requires a privileged user (can be anonymous)
109
Usage: GET /api/search/gavc?[g=groupId][&a=artifactId][&v=version][&c=classifier][&repos=x[,y]] Produces: application/vnd.org.jfrog.artifactory.search.GavcSearchResult+json 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). Since: 2.2.0 Security: Requires a privileged user (can be anonymous) Usage: GET /api/search/prop?[p1=v1,v2][&p2=v3][&repos=x[,y]] Produces: application/vnd.org.jfrog.artifactory.search.MetadataSearchResult+json Sample output:
GET /api/search/prop?p1=v1,v2&p2=v3&repos=libs-release-local { "results" : [ { "uri": "http://localhost:8080/artifactory/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/ver2/lib-ver2.pom" } ] }
XPath Search
Description: Search by xpath in indexed XML documents (including POMs and Ivy modules) or attached XML metadta If no value is specified - assume '*'. Can limit search to specific repositories (local or caches). Since: 2.2.0 Security: Requires a privileged user (can be anonymous) Usage: GET /api/search/xpath?name={artifactName}&metadata={0 for file XML, 1 for metadata XML}&xpath={xpath}&val={value}[&repos=x[,y]] Produces: application/vnd.org.jfrog.artifactory.search.XpathSearchResult+json Sample output:
110
GET /api/search/xpath?name=*.pom&metadata=0&xpath=//groupId&val=org/acme/cool-project&repos=libs-release-local{"results" : [ { "uri": "http://localhost:8080/artifactory/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/ver2/lib-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). Notes: Requires Artifactory Pro Since: 2.3.0 Security: Requires a privileged user (can be anonymous) Usage: GET /api/search/checksum?md5=md5sum|?sha1=sha1sum[&repos=x[,y]] Produces: application/vnd.org.jfrog.artifactory.search.ChecksumSearchResult+json 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 } ] }
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). Notes: Requires Artifactory Pro Since: 2.3.4 Security: Requires a privileged user (can be anonymous) Usage: GET /api/search/badChecksum?type=md5|sha1[&repos=x[,y]] Produces: application/vnd.org.jfrog.artifactory.search.BadChecksumSearchResult+json 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 "serverMd5": "4040c7c184620af0a0a8a3682a75eb7" "clientMd5": "4040c7c184620af0a0a8a3682a75e44" //On missing checksum this element will be an empty string } ] }
111
Artifacts Not Downloaded Since

Description: Get all artifacts not downloaded since the specified Java epoch in msec. Optionally include only artifacts created before the specified createdBefore date, otherwise only artifacts created before notUsedSince are returned. Can limit search to specific repositories (local or caches). Since: 2.2.4 Security: Requires a privileged non-anonymous user. Usage: GET /api/search/usage?notUsedSince=javaEpochMillis[&createdBefore=javaEpochMillis][&repos=x[,y]] Produces: application/vnd.org.jfrog.artifactory.search.ArtifactUsageResult+json Sample output:
GET /api/search/usage?notUsedSince=long&createdBefore=long&repos=libs-release-local { "results" : [ { "uri": "http://localhost:8080/artifactory/api/storage/libs-release-local/org/acme/lib/ver/lib-ver.jar", "lastDownloaded": ISO8601 },{ "uri": "http://localhost:8080/artifactory/api/storage/libs-release-local/org/acme/lib/ver2/lib-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). Since: 2.2.0 Security: Requires a privileged non-anonymous user. Usage: GET /api/search/creation?from=javaEpochMillis[&to=javaEpochMillis][&repos=x[,y]] Produces: application/vnd.org.jfrog.artifactory.search.ArtifactCreationResult+json Sample output:
GET /api/search/creation?from=long&to=long&repos=libs-release-local { "results" : [ { "uri": "http://localhost:8080/artifactory/api/storage/libs-release-local/org/acme/lib/ver/lib-ver.jar", "created": ISO8601 },{ "uri": "http://localhost:8080/artifactory/api/storage/libs-release-local/org/acme/lib/ver2/lib-ver2.jar", "created": ISO8601 } ] }
Pattern Search
Description: Get all artifacts matching the given Ant path pattern Since: 2.2.4 Notes: Requires Artifactory Pro. Pattern "**" is not supported to avoid overloading search results. Security: Requires a privileged non-anonymous user. Usage: GET /api/search/pattern?pattern=repo-key:this/is/a//pattern/.war Produces: application/vnd.org.jfrog.artifactory.search.PatternResultFileSet+json Sample output:
112
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) Notes: Requires Artifactory Pro Since: 2.3.4 Security: Requires a privileged user (can be anonymous) Usage: GET /api/search/dependency?sha1=sha1Checksum Produces: application/vnd.org.jfrog.artifactory.search.DependencyBuilds+json Sample output:
GET /api/search/dependency?sha1=451a3c5f8cfa44c5d805379e760b5c512c7d250b { "results" : [ { "uri": "http://localhost:8080/artifactory/api/build/wicket/50" },{ "uri": "http://localhost:8080/artifactory/api/build/wicket/51" } ] }
License Search
Description: Search for artifacts with a 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 autofind parameter is specified Artifactory will try to automatically find new license information and return it as part of the result in the found field. Please note that this can affect the speed of the search quite dramatically. Can limit search to specific repositories (local or caches). Since: 2.3.0 Notes: Requires Artifactory Pro Security: Requires an admin user Usage: GET /api/search/license[?unapproved=1][&unknown=1][&notfound=0][&neutral=0][&approved=0][&autofind=0][&repos=x[,y]] Produces: application/vnd.org.jfrog.artifactory.search.LicenseResult+json Sample output:
113
GET /api/search/license?approved=1&unknown=1&autofind=1&repos=libs-release-local,staging { "results" : [ { "uri": "http://localhost:8080/artifactory/api/storage/libs-release-local/org/acme/lib/ver/lib-ver.jar", "license": "lgplv2", "found": "lgplv2", "status": "approved" },{ "uri": "http://localhost:8080/artifactory/api/storage/libs-release-local/org/acme/lib/ver/lib-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 artifactId in local, remote or virtual repositories. Search can be limited to specific repositories (local, remote and virtual) by settings the repos parameter. Release/integration versions: Unless the version parameter is specified, both release and integration versions are returned. When version is specified, e.g. 1.0-SNAPSHOT, result will include only for integration versions. Integration versions are determined by the repository layout of the repositories searched. For integration search to work the repository layout requires an 'Artifact Path Pattern' that contains the baseRev token and then the fileItegRev token with only literals between them. Remote searches: By default only local and cache repositories will be used. When specifying remote=1, Artifactory will search for versions on remote repositories. Note that this can dramatically slow down the search. For maven repositories the remote maven-metadata.xml will be consulted. For non-maven layouts, remote file listing will run for all remote repositories that have the 'List Remote Folder Items' checkbox enabled. Since: 2.6.0 Notes: Requires Artifactory Pro Security: Requires a privileged user (can be anonymous) Usage: GET /api/search/versions?[g=groupId][&a=artifactId][&v=version][&remote=0/1][&repos=x[,y]] Produces: application/vnd.org.jfrog.artifactory.search.ArtifactVersionsResult+json 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
114
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 repos parameter. Latest release vs. latest integration: Unless the version parameter is specified, the search will return the latest artifact release version. When version is specified, e.g. 1.0-SNAPSHOT, the result will be the latest integration version. Integration versions are determined by the repository layout of the repositories searched. For integration search to work the repository layout requires an 'Artifact Path Pattern' that contains the baseRev token and then the fileItegRev token with only literals between them. Remote searches: By default only local and cache repositories will be used. When specifying remote=1, Artifactory will search for versions on remote repositories. Note that this can dramatically slow down the search. For maven repositories the remote maven-metadata.xml will be consulted. For non-maven layouts, remote file listing will run for all remote repositories that have the 'List Remote Folder Items' checkbox enabled. Since: 2.6.0 Notes: Requires Artifactory Pro Security: Requires a privileged user (can be anonymous) Usage: GET /api/search/latestVersion?[g=groupId][&a=artifactId][&v=version][&remote=1][&repos=x[,y]] Produces: text/plain Sample output:
GET /api/search/latestVersion?g=org.acme&a=artifact&v=1.0-SNAPSHOT&repos=libs-release-local 1.0-201203131455-2
SECURITY Get Users

Description: Get the users list Since: 2.4.0 Notes: Requires Artifactory Pro Security: Requires an admin user Usage: GET /api/security/users Produces: application/vnd.org.jfrog.artifactory.security.Users+json 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 Since: 2.4.0 Notes: Requires Artifactory Pro Security: Requires an admin user Usage: GET /api/security/users/{userName} Produces: application/vnd.org.jfrog.artifactory.security.User+json Sample output:
GET /api/security/users/davids { user.json }
115
Create or Replace User

Description: Creates a new user in Artifactory or replaces an existing user Since: 2.4.0 Notes: Requires Artifactory Pro Missing values will be set to the default values as defined by the consumed type. Security: Requires an admin user Usage: PUT /api/security/users/{userName} 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. Since: 2.4.0 Notes: Requires Artifactory Pro Security: Requires an admin user Usage: POST /api/security/users/{userName} 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. Since: 2.4.0 Notes: Requires Artifactory Pro Security: Requires an admin user Usage: DELETE /api/security/users/{userName} Produces: application/text Sample usage:
DELETE /api/security/users/davids User 'davids' has been removed successfully.
Get Groups
Description: Get the groups list Since: 2.4.0 Notes: Requires Artifactory Pro Security: Requires an admin user Usage: GET /api/security/groups Produces: application/vnd.org.jfrog.artifactory.security.Groups+json Sample output:
116
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 Since: 2.4.0 Notes: Requires Artifactory Pro Security: Requires an admin user Usage: GET /api/security/groups/{groupName} 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 Since: 2.4.0 Notes: Requires Artifactory Pro Missing values will be set to the default values as defined by the consumed type. Security: Requires an admin user Usage: PUT /api/security/groups/{groupName} 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. Since: 2.4.0 Notes: Requires Artifactory Pro Security: Requires an admin user Usage: POST /api/security/groups/{groupName} Consumes: application/vnd.org.jfrog.artifactory.security.Group+json Sample usage:
117
POST /api/security/groups/dev-leads { group.json }
Delete Group
Description: Removes an Artifactory group. Since: 2.4.0 Notes: Requires Artifactory Pro Security: Requires an admin user Usage: DELETE /api/security/groups/{groupName} Produces: application/text Sample usage:
DELETE /api/security/groups/dev-leads Group 'dev-leads' has been removed successfully.
Get Permission Targets

Description: Get the permission targets list Since: 2.4.0 Notes: Requires Artifactory Pro Security: Requires an admin user Usage: GET /api/security/permissions 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 Since: 2.4.0 Notes: Requires Artifactory Pro Security: Requires an admin user Usage: GET /api/security/permissions/{permissionTargetName} Produces: application/vnd.org.jfrog.artifactory.security.PermissionTarget+json Sample output:
GET /api/security/permissions/populateCaches { permission-target.json }
118
Create or Replace Permission Target

Description: Creates a new permission target in Artifactory or replaces an existing permission target Since: 2.4.0 Notes: Requires Artifactory Pro Missing values will be set to the default values as defined by the consumed type. Security: Requires an admin user Usage: PUT /api/security/permissions/{permissionTargetName} Consumes: application/vnd.org.jfrog.artifactory.security.PermissionTarget+json Sample usage:
PUT /api/security/permissions/populateCaches { permission-target.json }
Delete Permission Target

Description: Removes an Artifactory permission target. Since: 2.4.0 Notes: Requires Artifactory Pro Security: Requires an admin user Usage: DELETE /api/security/permissions/{permissionTargetName} Produces: application/text 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. Permissions are returned according to the following conventions: m=admin; d=delete; w=deploy; n=annotate; r=read Notes: Requires Artifactory Pro Since: 2.3.4 Security: Requires a valid admin or local admin user. Usage: GET /api/storage/{repoKey}/{itemPath}?permissions Produces: application/vnd.org.jfrog.artifactory.storage.ItemPermissions+json 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
119
Description: Retrieve the security configuration (security.xml). Since: 2.2.0 Notes: This is an advanced feature - make sure the new configuration is really what you wanted before saving. Security: Requires a valid admin user Usage: GET /api/system/security Produces: application/xml Sample output:
GET /api/system/security <security.xml/>
Save Security Configuration (Deprecated)

Description: Save the security configuration (security.xml). Since: 2.2.0 Notes: This API is deprecated. Security: Requires a valid admin user Usage: POST /api/system/security Consumes: application/xml 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. Since: 2.2.0 Security: Requires a privileged user (can be anonymous) Usage: GET /api/repositories[?type=repositoryType (local|remote|virtual)] Produces: application/vnd.org.jfrog.artifactory.repositories.RepositoryDetailsList+json 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" } ]
Repository Configuration
Description: Gets the current configuration of a repository. Since: 2.3.0 Notes: Requires Artifactory Pro
120
Security: Requires a valid user for a shared remote repository and admin user for anything else. Shared remote repository data will be sanitized for security when non-admin user is used. Usage: GET /api/repositories/{repoKey} 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 pos parameter. If the map size is shorter than pos the repository will be the last one (the default behavior). Since: 2.3.0 Notes: Requires Artifactory Pro An existing repository with the same key will be removed from the configuration and its content will be removed! Missing values will be set to the default values as defined by the consumed type spec. Security: Requires an admin user Usage: PUT /api/repositories/{repoKey}[?pos=position] Consumes: application/vnd.org.jfrog.artifactory.repositories.LocalRepositoryConfiguration+json, application/vnd.org.jfrog.artifactory.repositories.RemoteRepositoryConfiguration+json, application/vnd.org.jfrog.artifactory.repositories.VirtualRepositoryConfiguration+json, application/json Sample usage:
PUT /api/repositories/libs-release-local?pos=2 { repository-config.json }
Update Repository Configuration

Description: Updates an exiting repository configuration in Artifactory with the provided configuration elements. Since: 2.3.0 Notes: Requires Artifactory Pro The class of a repository (the rclass attribute cannot be updated. Security: Requires an admin user Usage: POST /api/repositories/{repoKey} Consumes: application/vnd.org.jfrog.artifactory.repositories.LocalRepositoryConfiguration+json, application/vnd.org.jfrog.artifactory.repositories.RemoteRepositoryConfiguration+json, application/vnd.org.jfrog.artifactory.repositories.VirtualRepositoryConfiguration+json, application/json Sample usage:
POST /api/repositories/libs-release-local { repository-config.json }
Delete Repository
Description: Removes a repository configuration together with the whole repository content. Since: 2.3.0 Notes: Requires Artifactory Pro Security: Requires an admin user Usage: DELETE /api/repositories/{repoKey} Produces: application/text Sample usage:
121
DELETE /api/repositories/libs-release-local Repository 'libs-release-local' and all its content have been removed successfully.
Remote Repository Configuration

Description: Repository Configuration (Deprecated) Gets the shared configuration of a remote repository. Since: 2.2.0 Notes: This API is deprecated. Use the Get Repository Configuration API instead. Security: Requires a valid user for a shared remote repository and admin user for anything else. Shared remote repository data will be sanitized for security when non-admin user is used. Usage: GET /api/repositories/{remoteRepoName}/configuration Produces: application/vnd.org.jfrog.artifactory.repositories.SharedRemoteRepositoryConfiguration+json Sample output:
GET /api/repositories/remote-repo/configuration { repository-config.json }
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 YUM integration documentation for more details. Notes: Requires Artifactory Pro. Immediate calculation requests cannot be called on repositories with automatic asynchronous calculations enabled. Security: Requires a valid admin user Usage: POST /api/yum/{repoKey}[?async=0/1] Produces: application/text Since: 2.3.5 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 wish 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 Exposing Maven Indexes documentation for more details. Notes: Requires Artifactory Pro. Security: Requires a valid admin user Usage: POST /api/maven[?repos=x[,y]][&force=0/1] Produces: application/text Since: 2.5.0 Sample output:
122
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.
SYSTEM & CONFIGURATION System Info

Description: System Info Get general system information. Since: 2.2.0 Security: Requires a valid admin user Usage: GET /api/system Produces: text/plain 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. Since: 2.3.0 Security: Requires a valid user (can be anonymous) Usage: GET /api/system/ping Produces: text/plain Sample output:
GET /api/system/ping OK
Description: Get the general configuration (artifactory.config.xml). Since: 2.2.0 Security: Requires a valid admin user Usage: GET /api/system/configuration Produces: application/xml (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). Since: 2.2.0 Notes: This is an advanced feature - make sure the new configuration is really what you wanted before saving. Security: Requires a valid admin user
123
Usage: POST /api/system/configuration Consumes: application/xml (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: Get information about the current Artifactory version, revision, and currently installed add-ons Since: 2.2.2 Security: Requires a valid user (can be anonymous) Usage: GET /api/system/version 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 executions section of a user plugin. Execution can take parameters and be synchronous (the default) or asynchronous. Since: 2.3.1 Notes: Requires Artifactory Pro Security: Requires an admin user Usage: POST /api/plugins/execute/{executionName}?[params=p1=v1[,v2][|p2=v3][&async=1]] Produces: text/plain 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 user plugin information (subject to the permissions of the provided credentials). Since: 2.5.2 Notes: Requires Artifactory Pro Security: Requires an authenticated user. Usage: GET /api/plugins Produces: application/json Sample output:
124
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 user plugin information (subject to the permissions of the provided credentials) of the specified type. Since: 2.5.2 Notes: Requires Artifactory Pro Security: Requires an authenticated user. Usage: GET /api/plugins/{pluginType} Produces: application/json 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 strategy defined by a user plugin. Since: 2.5.2 Notes: Requires Artifactory Pro Security: Requires an authenticated user. Usage: GET /api/plugins/build/staging/{strategyName}?buildName={buildName}&[params=p1=v1[,v2][|p2=v3]] Produces: application/vnd.org.jfrog.plugins.BuildStagingStrategy Sample output:
125
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 promotions section of a user plugin. Since: 2.5.2 Notes: Requires Artifactory Pro Security: Requires an authenticated user. Usage: POST /api/plugins/build/promote/{promotionName}/{buildName}/{buildNumber}?[params=p1=v1[,v2][|p2=v3]] Produces: text/plain 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. Since: 2.2.2 Security: Requires a valid admin user Usage: POST: /api/import/repositories 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 Produces: text/plain Sample output:
POST: /api/import/repositories?path=pathToRepos&verbose=1
Import System Settings Example
126
Description: Returned default Import Settings JSON. Since: 2.4.0 Security: Requires a valid admin user Usage: GET: /api/import/system 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. Since: 2.4.0 Security: Requires a valid admin user Usage: POST: /api/import/system Consumes : application/vnd.org.jfrog.artifactory.system.ImportSettings+json, application/json Produces: text/plain Sample usage:
POST /api/import/system { import-settings.json }
Export System Settings Example

Description: Returned default Export Settings JSON. Since: 2.4.0 Security: Requires a valid admin user Usage: GET: /api/export/system 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. Since: 2.4.0 Security: Requires a valid admin user
127
Usage: POST: /api/system/export Consumes : application/vnd.org.jfrog.artifactory.system.ExportSettings+json, application/json Produces: text/plain Sample usage:
POST /api/export/system { export-settings.json }
Repository Configuration JSON

Legend + Mandatory element in create/replace queries Optional element in create/replace queries The default value when in create/replace queries when unspecified
(default)
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
128
{ - "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", - "notes": "Some internal notes", - "includesPattern": "**/*" (default), - "excludesPattern": "" (default), - "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", - "notes": "Some internal notes", - "includesPattern": "**/*" (default), - "excludesPattern": "" (default), - "artifactoryRequestsCanRetrieveRemoteArtifacts": false, - "keyPair": "keypair1", - "pomRepositoryReferencesCleanupPolicy": "discard_active_reference" (default) | "discard_any_reference" | "nothing" }
Security Configuration JSON

Legend + Mandatory element in create/replace queries Optional element in create/replace queries Read-only element
129
(default)
The default value when in create/replace queries when unspecified
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), "excludesPattern": "" (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

Legend + Mandatory element Optional element The default value when unspecified
(default)
130
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 on top of the open-source Artifactory version. Artifactory Pro is available commercially or with selected support contracts. You can find out more about Artifactory Pro.
Contrasting Artifactory OSS, Pro and Artifactory Online Please see the Artifactory Version Comparison Matrix in order to compare the features and services offered with each Artifactory version. If you have any questions, please contact support@jfrog.com for further information.
The add-ons included in the Power Pack are: Build Integration License Control LDAP Groups Repository Replication Advanced REST (APIs stating "Requires Pro")
131
Properties User Plugins YUM Repositories P2 Repositories NuGet Repositories NuGet Repositories Repository Layouts Smart Searches Single Sign-on and Atlassian Crowd Integration Filtered Resources Watches WebStart and Jar Signing
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: first, you need to install the Artifactory Pro Power Pack or upgrade an exiting Artifactory to include the Pro Power Pack. Then, you have to activate the Pro Power-Pack by entering your Artifactory Pro License.
1. Downloading
Purchase or request an evaluation of the Artifactory Pro Power Pack from JFrog's web site. You will receive back by email a download link that you can use to download the Artifactory Pro Power Pack as well as 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 installation instructions. Installing Artifactory with the Pro 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.
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 artifactory.war file and configuring a valid license key. After that, you will have a fully functional Pro version with the same settings and content as the OSS version you upgraded from.
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 need to enter this license key in Artifactoy's license configuration page. This can only be done by an Artifactory administrator by going to Admin:Register
132
Pro and filling-in the License field.
Once you have configured a valid License key, Artifactory Pro Power Pack will be fully active and the Pro Power Pack add-ons should show up as 'Activated' on Artifactory's home page screen. Enjoy your use of the Artifactory Pro!
Artifactory Version Comparison
133
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
134
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 Authentication
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 really straight forward - you simply treat The CI server as a regular build client and, as such, the CI server will resolve dependencies from Artifactory and deploy artifacts into a dedicated repository inside Artifactory. The Build Integration feature of Artifactory takes this integration one big step forward, by making Artifactory and your CI server closely integrated to provide fully-reproducible builds and full visibility of deployed artifacts, used dependencies and information about build environment. By using the Build Integration add-on you will: Be able to see all the builds that published their build results to Artifactory. Explore each build's modules, including published artifacts and dependencies with their scope. Get the 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.). Get bidirectional links between build and artifact information inside the build server and Artifactory pages.
Jenkins/Hudson, Team City and Bamboo Integrations
135
The Build Integration currently supports Jenkins/Hudson, TeamCity and Bamboo. Similar integration with other build technologies stacks, are currently being worked-on - stay tuned. The build technologies supported are: Maven 3 and 2, Gradle, Ivy/Ant, .Net and Generic builds (look under each CI server to see the technologies supported by the plugin for this server). To learn more about installation and usage instructions specific to your CI server, please follow these links:
The Jenkins/Hudson Artifactory Plug-in The TeamCity Artifactory Plug-in The Bamboo Artifactory Plug-in
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 BuildInfo View and the ability to traverse and 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.
Inspecting and Managing Builds

Builds and Per-Build History
After 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 'Builds' menu item lists all known CI server projects that published their build results:
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 into and get 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'. You can of course also navigate back to Artifactory from the CI server UI.
To view build information users need to have a 'deployer' permission on some repository path (at minimum).
136
Build-level Information
Drilling-down into the single build level, each build contains tree parts of information: 1. Visual general build information about the build and its environment. 2. Visual views for modules with their artifacts and dependencies. 3. Generic view of the build information in JSON format.
General Build Information

This section contains general information about the build. It is also from here, that you can save the build's artifacts and/or dependencies as a Smart Search Result, for further manipulation, as we will see later.
Build Modules
Each build publishes module(s) into Artifactory, which are seen on this view, together with the number of artifacts and dependencies which they contain:
Module Artifacts and Dependencies
137
If we drill even further down, we will be able to inspect each module's published artifacts and dependencies. Note that deployed artifacts are collected with their types, and dependencies contain the scope(s) that the dependencies were 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 we want to replay the build in a later point in time (e.g. JDK used, system architecture etc.).
138
Licenses
In the Licenses tab, you receive a centralized view of all the artifacts and dependencies that were involved and their license analysis.
See the License Control documentation to learn more about this cool feature.
Release History
The Release History tabs displays a timeline of the selected build's release landmarks.
139
Generic BuildInfo View

The generic BuildInfo view displays an JSON representation of the data that is used to form the visual build information in Artifactory. This can be used by REST or for debugging and is also exposed in the basic OSS version of Artifactory. See towards the end of this chapter for more information about the BuildInfo object.
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.
140
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 Builds tab (when selecting the artifact in the tree view). Moreover, you will also receive warnings when trying to remove from the UI, an artifact that is associated with one or more builds and which without, build reproducibility will be affected. You can navigate directly from the Builds view to the build information in Artifactory or to the build page in your CI Server:
Artifacts association with builds is kept no matter 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.
Behind the Scenes
141
Behind the scenes the Artifactory plug-in for your CI server performs two major tasks: 1. It deploys all the artifacts in one go to Artifactory. This is done in an optimized fast way and only at the end of the build, which guarantees a more coherent deployment when building multi-module projects (Maven and Ivy's way deploys at the end of each sub-module cycle, which can result in partial deployments if the build fails in a late module). 2. It sends a BuildInfo data object to Artifactory via REST at the end of deployment. BuildInfo is a structured JSON object that contains all the data about the build environment, artifacts and dependencies, in a standard and open way. You can find latest BuildInfo Java-bindings artifacts here and the source here.
Jenkins (Hudson) Artifactory Plug-in

Before You Begin
Please make sure to read the general information about Artifactory's Build Integration before going into the Jenkins-specific documentation.
Setting-up Jenkins/Hudson
The Jenkins/Hudson Plug-in
To integrate with Jenkins you will need to 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 that transfers to Artifactory additional important build information. UI integration allowing going from a Jenkins build directly to Artifactory. Release Management with Staging and Promotion.
Supported Build Technologies:

The plug-in currently support: Maven 3, Maven 2, Gradle, and Ivy/Ant builds.
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: 1. Setting up Jenkins to know your Artifactory server. 2. Pointing a Jenkins build at a target local repository in Artifactory to which it should deploy the build artifacts - Jenkins will query Artifactory's available target repositories using Artifactory's REST API and allow 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 done the regular way a build is configured, typically by changing the settings.xml or the ivysettings.xml.xml of the user running Jenkins.
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:
142
For each build item in the history you can drill down into and get more fine 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 seen below:
TeamCity Artifactory Plug-in

Before You Begin
Please make sure to read the general information about Artifactory's Build Integration before going into the TeamCity-specific documentation.
Release Management with the TeamCity Artifactory Plugin Version 2.1.0 of the plugin introduces powerful Release Management and Promotion capabilities.
Overview
The TeamCity Artifactory plugin brings CI Build Integration to TeamCity users. This lets you capture information about deployed artifacts, resolved dependencies and environment data associated with TeamCity build runs and have 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.
Support for multiple Build Runner types The TeamCity Artifactory plugin supports almost all build runner types, including: Maven2/3, Ivy/Ant (with Ivy modules support), Gradle , NAnt, MSBuild, FxCop and Ipr.
Installing the Plugin

Requirements
Some features of the plugin will only run on the recent versions of Artifactory and TeamCity. To be able to make the most of the plugin the recommended requirements are:
143
Artifactory 2.2.5 or later. JetBrains TeamCity 5.1.3 or later.
Installation
Download the version of the plugin accordding to the compatibility matrix below: For TeamCity 7.0.x teamcity-artifactory-plugin-2.1.3.zip. 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 simply placing the packaged plugin into the $TEAMCITY_USER_HOME/.BuildServer/plugins folder and restarting TeamCity (if you have an older version of the plugin, make sure to remove it).
Compatibility Matrix
Artifactory plugin version 1.0 1.0.1 1.1.1 - 1.1.2 1.1.3 2.0.0 2.0.1 2.1.0 2.1.1 2.1.2 2.1.3
TeamCity version 5.1 5.1.1 5.1.3 5.1.5 6.0+ 6.0+ 6.5+ 6.5+ 6.5.5+ 6.5.5+
Artifactory version 2.2.4 2.2.5+ 2.3.0+ 2.3.0+ 2.3.0+ 2.3.0+ 2.3.4+ 2.3.4+ 2.3.4+ 2.6.0
Configuration
To use the TeamCity Artifactory plugin you will first need to configure your Artifactory server(s) in TeamCity's server configuration. Then you can 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->Server Configuration->Artifactory. Click on "Create new Artifactory server configuration" and fill in the URL of the Artifactory server. 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 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).
144
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. Upon selecting an Artifactory server URL, the server will be queried for a list of configured repositories (using the credentials in the server configuration, if configured). This will populate the "Target Repository" combobox with a list of target repositories to deploy too. If the repository list remains empty, make sure the specified Artifactory server URL, credentials and proxy information (if provided) are valid. Any information about communication errors which might occur can be found in the TeamCity server logs.
145
The 'Deploy maven artifacts' option will only be avialable when using a 'Maven2' build runner.
Running License Checks
You use the Artifactory Pro Licene Control feature to discover and handle third party dependency licensing issues as part of the build. Check the 'Run license checks' option if wish that Artifactory will scan and check the licenses of all dependencies used by this build. If you wish to inform selected users about any license violations detected while scanning, you may enter a white-spaced list of e-mail addresses to the notification recipients text box.
Advanced Options
In addition, you have more advanced options: The 'Published artifacts' area lets you specify which artifact files produced by the build will be published to Artifactory. At the end of the build the plugin will locate artifacts in the build's checkout directory according to the specified artifact patterns and will publish 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 'Downloaded artifacts' area lets you specify dependency patterns for published artifacts that should be downloaded from Artifactory before the build is run. You can have fine control over which artifacts will be 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. Read more about
146
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 Variables, it is possible to define parameters that will be attached to the build-info and produced artifacts. 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 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 plugin to a properties file containing the aforementioned properties. To point to such a file, define a property by the name buildInfoConfig.propertiesFile and set its value to the absolute path of the properties file.
Please note that the given path and file should be present in the machine that is running the build agent, not the server.
147
Viewing Project-specific Configuration

Existing project configuration can be viewed from Projects->$PROJECT_NAME->$BUILD_NAME->Settings->Runner settings:
148
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 will kick in at the end of the build and will: 1. For all build runner types - publish the specified Published Artifacts to the selected target repository and apply proper path mappings. 2. For Maven or Ivy/Ant build runner - Deploy 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). 3. Deploy the Artifactory BuildInfo to artifactory, which provides full traceability of the build in Artifactory, with links back to the build in TeamCity.
149
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 will periodically poll 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 will be 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:
150
Select the server, repository and paths in the repository for which you would like to automatically trigger a build upon change in the item content. Fill-in a username and a password of a valid deployer (note that the user has to have deploy rights on any local repository).
Narrow down the scope for scanning When scanning a remote folder for changes, Artifactory has to traverse the folder content and figure out if any content has changed. For deep folders this traversal can become quite expensive. Therefore it is recommended to keep the scanning scope to the minimum possible.
Proxy Configuration
Currently, TeamCity does not provide a global point of proxy configuration; so in a case where the target Artifactory server needs to be accessed via a proxy, proxy configuration can be achieved by setting the following properties inside the $TEAMCITY_USER_HOME/.BuildServer/config/internal.properties file.
151
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.3 (30 May 2012)
1. 2. 3. 4. Compatible with TeamCity7. Support 'Perforce' in release management. 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)

1. Compatible with Gradle 1.0-milestone-6.
2.1.1 (09 Aug 2011)

1. Support for Gradle milestone-4 2. Better support for releasing nested Maven projects 3. Fixed minor Maven deployments discrepancies
2.1.0 (14 Jul 2011)

1. Release management capabilities 2. Bug fixes
2.0.1 (9 Jan 2011)

1. 2. 3. 4. Auto Snapshot/Release target repository selection Add ivy/artifact deploy patterns Improved Gradle support Bug fixes
2.0.0 (5 Dec 2010)

1. 2. 3. 4. Support for Gradle builds Support for maven3 builds Default deployer add resolver credentials Support for muti steps builds
1.1.3 (21 Nov 2010)

1. Include/exclude pattern for artifacts deployment
1.1.2 (7 Nov 2010)

1. Control for including published artifacts when running license checks 2. Limiting license checks to scopes 3. Control for turning off license discovery when running license checks
TeamCity Artifactory Plugin - Release Management
152
General
The Artifactory plugin includes release management capabilities for Maven and Gradle runners that use Subversion, Git or Perforce for VCS. The plugin lets you 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 on 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 recorded and displayed for full traceability.
Maven Release Management

Release management with Maven is done entirely by the plugin and executes the Maven build only once. These are the basic steps that the plugin performs: 1. 2. 3. 4. 5. 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 will do 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 will appear on the top end of the build page.
Clicking on the tab reveals configuration options for the release build:
153
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 filled 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 create VCS tag is checked (default), the plugin will commit/push 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 lets you change the target repository (the default is the release repository configured in Artifactory publisher) and to add a staging comment which will be 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 finished 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 will be available for the consumers. To activate the action browse to the build's result page and click the Artifactory Release Promotion link. Note that Artifactory Pro is required for promotion.
154
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 gradle.properties file. You add all the relevant properties to the release management configuration, and the plugin will read and modify those properties in the gradle.properties file. These are the basic steps that the plugin performs: 1. 2. 3. 4. 5. Change the gradle.properties with release values (before the build starts) Trigger the Gradle build (with optionally different tasks and options) Commit/push changes to the tag (Subversion) or the release branch (Git) Change the gradle.properties with next integration values Commit/push 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 check the "Enable Artifactory release management" checkbox.
155
Staging a Gradle Release Build

Once the release management is enabled, the Artifactory Release Management tab will appear on the top end of the build page.
Clicking on the tab reveals configuration options for the release build:
156
The release staging tab displays the release and next development properties configured for the runner. The values are read from the gradle.properties file and calculation of the release and next integration version is attempted and displayed in the text fields. If create VCS tag is checked (default), the plugin will commit/push 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 will be done on the branch instead of the currently checkout branch. The last section lets you change the target repository (the default is the release repository configured in Artifactory publisher) and optional staging comment which will be included in the build info deployed to Artifactory. Click on the "Build and Release to Artifactory" button to trigger the release build.

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 will perform the following: 1. Commit the release version directly to the tag (if create tag is checked). The release version is not committed to the to the working branch. 2. Commit 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 will modify the checkout configuration for the duration of the build and revert the change when the build is done. The remote URL should allow Read+Write access. During the release the plugin will perform the following: 1. If create branch is checked, create and switch to the release branch 2. Commit the release version to the current branch 3. Copyright 2012 JFrog Ltd. 157
3. 4. 5. 6.
Create a release tag Push the changes Switch to the checkout branch and commit the next development version Push the next development version to the working branch
Note that changes will only be committed if changes were made to the files (pom files or gradle.properties).
Bamboo Artifactory Plug-in

Before You Begin
Please make sure to read the general information about Artifactory's Build Integration before going into the Bamboo-specific documentation.
Overview
The Bamboo Artifactory plug-in brings CI Build Integration to Bamboo users. This lets you capture information about deployed artifacts, resolved dependencies and environment data associated with Bamboo build runs and have full traceability for your builds. In addition, the plug-in also takes care of deploying your artifacts to Artifactory efficiently.
Supported build technologies The Bamboo Artifactory plug-in currently provides full support for Maven 3, Gradle and Ivy builds. Generic Deployment tasks are available for all builder types.
Release Management Version 1.4.0 introduces Release Management capabilities.
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. Artifactory Pro is required for advanced features, such as License Control and enhanced 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.2.x: bamboo-artifactory-plugin-1.4.2.jar. For Bamboo 3.3.x: bamboo-artifactory-plugin-1.5.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.4.jar Put the packaged plug-in archive inside the $BAMBOO_HOME/webapp/WEB-INF/lib folder and restart Bamboo. If you have an older version of the plug-in, make sure to remove it first. (The plug-in uses the Bamboo Plug-in version 1 installation method).
Configuration
To use the Bamboo Artifactory plug-in you will need to configure your Artifactory server(s) in Bamboo's server configuration. Then you can set up a project builder to deploy artifacts and build-info to a repository on one of the configured Artifactory servers.
158
Configuring Maven 3, Gradle and Ivy Builders

Before we begin with any Artifactory-specific setup, we need to make sure that Maven 3, Gradle and/or Ivy builders are available to project configurations. For this, they must be defined as standard build capabilities under Administration->Build Resources->Server Capabilities: Select "Executable" as the Capability Type, then select "Artifactory Maven 3", "Artifactory Gradle" or "Artifactory Ivy" as the type from the "Types" list. Make sure "Path" points to an installation directory of the selected builder type.
Configuring System-wide Artifactory Server(s)

In order to make Artifactory servers available to project configurations, they must be defined under Administration->Plugins->Artifactory Plugin. Fill in the Artifactory server URL in the "Add New Server Configuration" form. 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 Tasks step of your jobs's configuration. When adding a task type, select the Artifactory Maven 3, Gradle or Ivy builder. The builder configuration fields will appear and will include Artifactory and build-info configuration options. Selecting an Artifactory Server URL. The 'Target Repository' list will be populated with a list of available target repositories as returned by the server (queried with the credentials in the server configuration, if provided). If the repository list remains empty, make sure the specified Artifactory server URL and credentials (if provided) are valid. Select the target repository you wish Bamboo to deploy artifacts and build-info to.
159
Running License Checks
Use the Artifactory Pro Licene Control feature to discover and handle third party dependency licensing issues as part of the build. Check the 'Run license checks' option if wish that Artifactory will scan and check the licenses of all dependencies used by this build. If you wish to inform selected users about any license violations detected while scanning, you may enter a white-spaced 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 minimalistic Build Info support for all types, the task collects all the info which is available from Bamboo regarding the build and provides a deployment mechanism for produced artifacts. Adding the Generic Deploy task will automatically deploy Build Info including artifacts collected from the Published Artifacts declaration. The 'Published Artifacts' declaration lets you specify which artifact files produced by the build will be published to Artifactory. At the end of the build the plugin will locate artifacts in the build's checkout directory according to the specified artifact patterns and will publish them to Artifactory, optionally applying mapping for the target path of each deployed artifact.
160
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 Administration->Build Resources->Global Variables, it is possible to define parameters that will be attached to the build-info and produced artifacts. To define a parameter fill in 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 named buildInfoConfig.propertiesFile and set its value to the absolute path of the properties file.
161
Please note that the given path and file should be present on the machine that is running the build agent, not the server.
Running a Build with the Artifactory Plug-in

Once you have completed setting up a project builder you can run it. The Artifactory plug-in will kick in at the end of the build and will: 1. Deploy 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). 2. Deploy the Artifactory build-info to the selected server, which provides full traceability of the build in Artifactory, with links back to the 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.5.4 (25 Jun)
1. Support Bamboo 4.1. 2. Bug fixes. (JIRA)
1.5.3 (02 Apr)

1. Support Bamboo 4.0.
1.5.2 (02 Apr)

1. Support Perforce for release management. (BAP-133) 2. Copyright 2012 JFrog Ltd. 162
2. Bug fixes. (JIRA)
1.5.1 (05 Jan)

1. 2. 3. 4. 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)

1. Compatible with bamboo version 3.3.x. 2. Compatible with Gradle 1.0-milestone-6.
1.4.2 (19 Sep)

1. Bug fix (BAP-91)
1.4.1 (01 Aug)

1. Support for Bamboo 3.2.x 2. Bug fix (BAP-90)
1.4.0 (14 Jul)

1. Introducing Release Management capabilities. 2. Generic Build Info support for all job types. 3. Bug fixes.
1.3.2 (14 Jun)

1. Bug fix (BAP-65)
1.3.1 (13 Jun)

1. Bug fix (BAP-64)
1.3.0 (30 May 2011)

1. Support for Bamboo 3.1.x
1.2.0 (2 Mar 2011)

1. Support for Bamboo 3.x
1.1.0 (2 Jan 2011)

1. Gradle Support - Gradle builds are now fully supported with the new Gradle builder 2. Ivy builds now support custom Ivy patterns for artifacts and descriptors 3. Support for Bamboo 2.7.x
1.0.3 (21 Nov 2010)

1. Add Include/exclude pattern for artifacts deployment 2. Bug fix (BAP-26)
1.0.2 (7 Nov 2010)

1. Control for including published artifacts when running license checks 2. Limiting license checks to scopes 3. Control for turning off license discovery when running license checks
Bamboo Artifactory Plugin - Release Management
General
163
The Artifactory plugin includes release management capabilities for Maven and Gradle jobs that use Subversion, Git or Perforce for VCS. The plugin lets you 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 on 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 recorded and displayed for full traceability.
Maven Release Management

Release management with Maven is done entirely by the plugin and executes the Maven build only once. These are the basic steps that the plugin performs: 1. 2. 3. 4. 5. 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 will do its best to rollback the changes (local and committed).
Configuring Maven Jobs

To enable release management in Maven jobs, edit the job configuration and check the "Enable Artifactory release management" checkbox.
Staging a Maven Release Build

Once the release management is enabled, Artifactory release staging link will appear in the on the top header bar in the job page.
Clicking on the release staging link will open a new page with configuration options for the release build:
164
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 filled 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 create VCS tag is checked (default), the plugin will commit/push 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 lets you change the target repository (the default is the release repository configured in Artifactory publisher) and to add a staging comment which will be included in the build info deployed to Artifactory. Click on the "Build and Release to Artifactory" button to trigger the release build.

After a release build finish 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 will be available for the consumers.
165
Artifactory Compatibility Artifactory Pro is required for promotion
To activate the action click on the 'Artifactory' tab link in the build result page.
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 gradle.properties file. You add all the relevant properties to the release management configuration, and the plugin will read and modify those properties in the gradle.properties file. These are the basic steps that the plugin performs: 1. 2. 3. 4. 5. Change the gradle.properties with release values (before the build starts) Trigger the Gradle build step (with optionally different tasks and options) Commit/push changes to the tag (Subversion) or the release branch (Git) Change the gradle.properties with next integration values Commit/push changes to the trunk
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 check "Enabled Release Management" checkbox.
166
Staging a Gradle Release Build

Once the release management is enabled, Artifactory release staging link will appear in the on the top header bar in the job page. Clicking on the release staging link will open a new page with configuration options for the release build:
167
The release staging page displays the release and next development properties configured for the job. The values are read from the gradle.properties file and calculation of the release and next integration version is attempted and displayed in the text fields. If create VCS tag is checked (default), the plugin will commit/push 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 will be done on the branch instead of the currently checkout branch. The last section lets you change the target repository (the default is the release repository configured in Artifactory publisher) and optional staging comment which will be included in the build info deployed to Artifactory. Click on the "Build and Release to Artifactory" button to trigger the release build.

Promotion is same RTD:as in Maven.
168
Working with Subversion

The release management supports Subversion SCM when using one checkout directory. During the release the plugin will perform the following: 1. Commit the release version directly to the tag (if create tag is checked). The release version is not committed to the to the working branch. 2. Commit the next development version to the working branch
Working with Git

To work with Git, the Git plugin has to be configured to build one branch AND to checkout to the same local branch. The remote URL should allow Read+Write access. The plugin uses the git client installed on the machine and uses its credentials to push back to the remote Git repository.
During the release the plugin will perform the following: 1. 2. 3. 4. 5. 6. If create branch is checked, create and switch to the release branch Commit the release version to the current branch Create a release tag Push the changes Switch to the checkout branch and commit the next development version Push the next development version to the working branch
169
Shallow Clones Bamboo's Git plugin allows for the use of shallow clones. However, This will cause 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
Working with Perforce

The release management supports Perforce SCM when using one checkout directory. During the release the plugin will perform the following: 1. Commit the release version to the working branch and create a label pointing to the changed files (if create VCS tag is checked). 2. Commit the next development version to the working branch
Note that changes will only be 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 Artifactory Build Integration add-on to let you gain full control over the licenses of the dependencies use 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, Artifactory will analyze the used dependencies and will try to match them against a set of license management rules. Notifications can be sent to a selected list of recipients about dependencies that have 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 license analysis.
How does license analysis work? Automatic analysis is done upon deployment by examining information found in artifact module files. Currently Maven POM and Ivy Descriptor files are supported. Users can always override the automatic results and assign license information manually to dependencies. They 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 will be reused by the automatic license analysis on subsequent builds.
Central License Management

Licenses are managed via the Admin:Configuration:Licenses menu.
170
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.
If you leave the regexp field blank Artifactory will attempt an exact match against the license key.
Artifactory comes pre-configured with all the common OSI licenses and JFrog has already tuned these licenses against common project builds.
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:
171
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 happen. This way whenever a dependency with an unknown or unapproved license is added to the build recipients will receive an immediate email notification and will be able to tend to any potential license violation.
Sending of license violation notifications is done through Artifactory and requires a valid mail server to be configured.
Not failing the build Currently Artifactory will not fail the build in the case of license violations. This is an informed decision in the spirit of allowing technical development to go through, while alerting about the advent of unauthorized dependencies in near real-time, so they can be address early on by the appropriate parties.
Examining Build Licenses

Once the build has finished on the build server and Build Info has deployed to Artifactory, license checks will run. The build license information is available under Artifacts:Builds - simply drill down to the specific build and select the Licenses tab. The licenses tabs contains information about all the dependencies used in the build (with selectable scopes) and the license they are associated with. 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: Unapproved Unknown Not Found The license found is not an approved one. License information was found but cannot be related to any license managed in Artifactory. No license information could be found for the artifact.
172
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 one.
Inline License Editing
If you are an admin then you can also change the license information directly from the decency in the table, using the Edit License pop-up action:
Running Manual License Discovery

You may wish to manually run the license discovery rules after a build has already run. There are several reasons for why you may want to do this: 1. License rules (configured licenses and regular expressions) have changed and you would like to compare the existing build licenses with the results of the new rules, or use them to fill-in missing license information. 2. You would like to test the current rules against the dependencies and tweak the rules if necessary. 3. You would like to check which license information can come from rules and which license information needs to be manually set. To trigger license discovery select the Auto-find Licenses button. Any license conflicts will be displayed to the right of the table, with the option to override the existing license information with the discovered one (you need to have Annotate permissions on artifacts on which you wish to override licenses).
Setting License Information Manually

You can, of course, set license information for artifacts manually. To do that, navigate to the artifact from the tree browser or from the Show in Tree pop-up action on a dependency in the the build's licenses table. Once you have the artifact selected in the tree browser choose the General panel and under the License label choose Add or Edit to change the artifact's licenses. Please note that an artifact can be associated with multiple licenses.
173
License Information as Properties
Internally license information is stored as regular properties, using the built-in artifactory.licenses property name. This means that 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. Please refer to the REST API documentation for usage information.

To see the License Control add-on in action you can watch the short demo screencast below.
LDAP Groups
Overview
The LDAP Groups add-on lets you 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 uses 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. When a user is logged-in he is automatically associated with his LDAP groups and inherits group-based permission managed in Artifactory.
Usage
LDAP Groups settings are available under Admin:Security:LDAP Settings. To use LDAP groups you first need to set up an LDAP server for authentication from the LDAP Settings screen. Next, you need to tell 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:
174
Static: Group objects are aware of their members, however, the users are not aware what groups they belong to. Each group object such as groupOfNames or groupOfUniqueNames holds its respective member attributes, typically member or uniqueMember, which is a user DN. 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 group, that holds the group DNs or group names of which the user is a member. 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 ou's or custom attributes that make up the group association. For example, uid=user1,ou=developers,ou=uk,dc=jfrog,dc=org indicates that user1 belongs to two groups: uk and developers.
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 Refresh button on the Synchronize LDAP Groups sub-panel. You should get a list of available LDAP groups, according to your settings. You are ready to synchronize/import groups into Artifactory. The groups tables lets you select which groups to import and displays the sync-state for each group: A group can either be completely new or already exist in Artifactory. If a group already exists in Artifactory it can become outdated (for example, if the group DN has changed) - this will be 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.
175
Once you have imported LDAP groups, you can manage permissions on them as you do with regular Artifactory groups. Users association to these groups is external and controlled strictly by LDAP.
Make sure the LDAP group settings is enabled (in the LDAP Groups Settings panel) in order for your settings to become effective.
Repository Replication
Overview
The Replication add-on provide a way to synchronize content+properties from one repository to another repository in a remote Artifactory instance. Synchronization uses a checksum-based algorithm to make sure only the needed deltas are ever transferred over the wire. Two types of replication are supported: Push Replication and Pull Replication.
176
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/or continuously based on storage events.
Evented Push Replication
In addition to scheduled replication, push replication also supports continuos "event-based replication". When enabled, storage events (deploy, delete, move and copy) are almost immediately applied to the remote instance, making sure the remote content is 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 actively pull 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 where waiting for new artifacts to arrive on demand (when first requested) is not desirable due to netwrok latency. Pull replication runs as a scheduled task.
It is highly recommended to perform the replication between servers with same Artifactory versions.
Replication Scheduling and Configuration

Replication is configured via the UI 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 ( Admin->Configuration->Repositories) and select the Replication tab. Pull replication is also exposed via the Artifactory REST API, with support for REST-enabled push replication coming soon. 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).
Cron Expression - Defines the replication task schedule using the cron syntax Sync Deletes - Check if items that were deleted remotely should be deleted locally too (also applies to properties metadata) Sync Properties - Check if the task should synchronize the properties of synched items Socket Timeout - The network timeout in milliseconds to use for remote operations Path Prefix (optional) - A subpath to replicate within the repository
Push Replication Local Repository Configuration

URL - The target local repository URL Enable Event Replication - Check to enable continuous replication to the remote instance based on storage events. Username - The username to authenticate with Password (optional) - The password to authenticate with Proxy (optional) - A proxy configuration to use when communicating with the remote instance
177
Pull Replication Remote Repository Configuration
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).

To see the Replication in action you can watch the short demo screencast below.
178
Properties
Introduction
Artifactory allows you to put properties on both artifacts and folder. 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 searchable, and can be combined with Smart Searches to search for items based on their properties and then manipulate all the items in the search result in one go. You to define in the UI collections of properties called 'Property Sets'. In each property-set you can define properties and for each property specify whether the property is open, single-value or multi-value. This affects the UI a user gets when setting a property value and when searching for property values. Using searchable properties in artifact management are a very powerful feature. Watch this short screencast to learn more about the power of properties.
Properties are 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, in order 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 helping, non-restrictive feature.
Attaching and Reading Properties via REST API

Properties are a special form of metadata and they are stored on items just like any metadata - in XML form. In fact, you can view properties not only from the Artifacts:Properties tab, but also from the Artifacts:Metadata tab, in which you can examine properties as they are stored in XML form. The properties XML is using the properties root tag and has a very simple format. You can set, get and remove properties from repository items via REST API, as you would do with any other XML-based metadata. Please follow the attaching and reading metadata chapter for instructions on how this can be achieved.
Using Properties in Deployment and Resolution

Introducing Matrix Parameters
Matrix parameters key-value pairs parameters separated by semicolon (;) that you can put anywhere on a URI. This is a standard way for specifying parameters in HTTP (in addition to query parameters and path parameters). For example:
http://repo.jfrog.org/artifactory/libs-releases-local/org/libs-releases-local/org/jfrog/build-info-api/1.3.1/build-inf ;status=DEV;rating=5 Artifactory makes use of matrix parameters for: 1. Adding properties to artifacts as part of deployment 2. Controlling artifact resolution using matrix parameters
Dynamically Adding Properties to Artifacts on Deployment

We can add key-value matrix parameters to deploy (PUT) requests and those will be automatically transformed to properties on the deployed artifact. Since matrix params can be added on any part of the URL, not just at the end, we can add them to the target deployment base URL. At deployment time the artifact path will be added after the matrix parameters and the final deployed artifact will be assigned the defined properties. We can even use dynamic properties, depending on our deployment framework. When using Maven, for instance, we can add two parameters to the deployment URL: buildNumer and revision, which Maven will replace at deployment time with dynamic values from the project properties (e.g. by using the Maven build-number plugin).
So, if we define the distribution URL as:
179
http://myserver:8081/artifactory/qa-releases;buildNumber=${buildNumber};revision=${revision}
And deploy to the qa-releases repository a jar with the following path:
/org/jfrog/build-info-api/1.3.1/build-info-api-1.3.1.jar
Upon deployment the URL will be transformed to:
http://myserver:8081/artifactory/qa-releases;buildNumber=249;revision=1052/org/jfrog/build-info-api/1.3.1/build-info-
And the deployed build-info-api-1.3.1.jar will have two new properties:
buildNumber=249 revision=1052
Permissions to attach properties You need to have the 'Annotate' permission in order to add properties to deployed artifacts.
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 properly with the key specified and the exact value specified (i.e. the artifact will be resolved if it has a property with a non-conflicting value. Non-mandatory properties are identified by a simple key=value parameter. For example: Current Artifact Property color=black None or height=50 color=red Matrix Parameter color=black color=black color=black Resolution Result OK (200) OK (200) 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
180
color=black None or height=50 color=red
color+=black color+=black color+=black
OK (200) NOT_FOUND (404) NOT_FOUND (404)
Multiple properties in queries Multiple key-value matrix parameters are additive, forming an AND query between each key-value subsection.
Multi-valued Properties Support

All matrix parameters can support multiple values by separating values with a comma (,). For example:
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 about running user's code in Artifactory. Plugins allow you to do things like: Adding scheduled tasks Extend Artifactory with your own security realms Change resolution rules Manipulate downloaded content Respond to any storage events 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 development 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
Simple place your plugin files under ${ARTIFACTORY_HOME}/etc/plugins. Any file name ending with .groovy will be loaded on startup. You can have multiple plugin files which will be loaded in alphabetical order. Callbacks defined in plugins will be called by the order plugins were loaded.
Auto Reload
By default plugins are not reloaded after Artifactory has started up. You can tell 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 ${ARTIFACTORY_HOME}/etc/artifactory.system.properties , or by specifying the property with -D to the JVM running Artifactory:
artifactory.plugin.scripts.refreshIntervalSecs=0
181
Production use Do not leave the plugins auto-reload feature active in a production environment.
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. A 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 the artifactory-papi.jar. The artifactory-papi.jar can be found under WEB-INF/lib folder inside the artifactory.war. Please see the plugin code template and sample plugin below for more details. Artifactory Public API, defined in
IDE code completion All major IDEs have good Groovy editing and debugging capabilities. In order to make your developing experience complete we provide support for our own DSL for IntelliJ IDEA. IntelliJ IDEA's Groovy DSL script for Artifactory User Plugins can be found in our GitHub repo.
Globally Bound Variables

Variable Name log Variable Type org.slf4j.Logger Comments Writes to Artifactory log logger name is the name of the script file Allows queries and operations on repositories and artifacts Provides information about current security context, (e.g. current user and her permissions) API for searching for artifacts and builds Since 2.3.4 Allows CRUD operations on builds Since 2.6
repositories
org.artifactory.repo.Repositories
security
org.artifactory.security.Security
searches
org.artifactory.search.Searches
builds
org.artifactory.build.Builds
Plugins Repository Enhancing Artifactory with user plugins is community-driven effort. If you are looking for going beyond Artifactory's out-of-the-box functionality take a look at already contributed plugins on GitHub, maybe you'll find what you are thinking about. If not, your contribution is very welcome!
Plugin Execution Points

The following table summarizes the available execution points. For more details about specific plugin look follow the section links.
Plugin Type
Code block name
When executed
Description
182
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). Provides an alternative download path under the same remote repository, by setting a new value to the path variable.
altRemotePath
When reaching out to remote repositories After fetching content from remote repositories After failing during content fetching from remote repositories Before fetching content from remote repositories After fetching content from remote repositories On any download
altRemoteContent
Provide an alternative download content, by setting new values for the inputStream and size context variables.
afterDownloadError
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). Handle before remote download events.
Event Callback (without return value)
beforeRemoteDownload
afterRemoteDownload
Handle after remote download events.
beforeDownload Storage Event Callback (without return value) Jobs Scheduled execution any valid Groovy (Java) literal as execution name before/after Create, Delete, Move, Copy
Handle before download events.
Before / After selected storage operation
Handle events before and after Create, Delete, Move and Copy operations
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 Realms Event Callback (without return 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. any valid Groovy (Java) literal as execution name By REST call External executions are invoked via REST POST requests.
Build Event Callback (without return value) beforeSave Before the build info is saved in Artifactory After the build info is saved in Artifactory Handle before build info save events
afterSave
Handle after build info save events
Promotions
183
User or build server driven execution Staging Strategy build server driven execution
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.
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.
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
A section for handling and manipulating download events
download { /**
184
* 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. * * Context variables: * path (java.lang.String) - the new path value. Defaults to the originalRepoPath's path. * * Closure parameters: * 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. * * Context variables: * 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: * repoPath (org.artifactory.repo.RepoPath) - a read-only parameter of the original 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.
185
404 - not found, or 409 - conflict). * * Context variables: * 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). * 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. */ afterDownloadError { Request request -> } /** * Handle before remote download events. * * Closure parameters: * request (org.artifactory.request.Request) - a read-only parameter of the request. [since: 2.3.4] * repoPath (org.artifactory.repo.RepoPath) - a read-only parameter of the original request RepoPath. */ beforeRemoteDownload { request, repoPath -> } /** * Handle after remote download events. * * Closure parameters: * request (org.artifactory.request.Request) - a read-only parameter of the request. [since: 2.3.4] * repoPath (org.artifactory.repo.RepoPath) - a read-only parameter of the original request RepoPath. */ afterRemoteDownload { request, repoPath -> } /** * Handle before local download events. * * 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). */
186
beforeDownload { request, responseRepoPath -> } }
Storage
A section for handling and manipulating storage events
If you wish 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. * * Closure parameters: * item (org.artifactory.fs.ItemInfo) - the original item being created. */ beforeCreate { item -> } /** * Handle after create events. * * Closure parameters: * item (org.artifactory.fs.ItemInfo) - the original item being created. */ afterCreate { item -> } /** * Handle before delete events. * * Closure parameters: * item (org.artifactory.fs.ItemInfo) - the original item being being deleted. */ beforeDelete { item -> } /** * Handle after delete events. * * Closure parameters: * item (org.artifactory.fs.ItemInfo) - the original item deleted. */ afterDelete { item -> } /** * Handle before move events. * * Closure parameters: * 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 -> } /**
187
* Handle after move events. * * Closure parameters: * item (org.artifactory.fs.ItemInfo) - the source item 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. */ afterMove { item, targetRepoPath, properties -> } /** * Handle before copy events. * * Closure parameters: * item (org.artifactory.fs.ItemInfo) - the source item being copied. * targetRepoPath (org.artifactory.repo.RepoPath) - the target repoPath for the copy. * properties (org.artifactory.md.Properties) - user specified properties to add to the item being moved. */ beforeCopy { item, targetRepoPath, properties -> } /** * Handle after copy events. * * Closure parameters: * item (org.artifactory.fs.ItemInfo) - the source item copied. * targetRepoPath (org.artifactory.repo.RepoPath) - the target repoPath for the copy. * properties (org.artifactory.md.Properties) - user specified properties to add to the item being moved. */
188
afterCopy { item, targetRepoPath, properties -> } }
Jobs
A section for 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
A section for 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/multiply?params=msg=And+the+result+is:|no1=10|no2=15&async=0"
189
executions { /** * An execution definition. * The first value is a unique name for the execution. * * Context variables: * status (int) - a response status code. Defaults to -1 (unset). Not applicable for an async execution. * message (java.lang.String) - a text message to return in the response body, 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 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 for information or invoke it. * * Closure parameters: * 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, description, users, groups, params) { params -> } }
Realms
A section for 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.
190
realms { /** * An security realm definition. * The first value is a unique name for the realm. * * Parameters: * 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 reult of the authentication. * Closure parameters: * 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. * Closure parameters: * username (java.lang.String) - The username */ userExists { username -> } } }
Build
A section for handling build info events
Since 2.6
191
build { /** * Handle before build info save events * * Closure parameters: * buildRun (org.artifactory.build.DetailedBuildRun) - Build Info model to be saved. Partially mutable. */ beforeSave { buildRun -> } /** * Handle after build info save events * * Closure parameters: * buildRun (org.artifactory.build.DetailedBuildRun) - Build Info that was saved. Partially mutable. */ afterSave { buildRun -> } }
Promotions
A section for defining REST executable build promotion operations
Since 2.6
promotions { /** * A REST executable build promotion definition. * * 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. * * 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 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 for information or invoke it. * * Closure parameters: * 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
192
A section for defining REST retrievable build staging strategy construction

Since 2.6.1
/** * 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. * * 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 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 for information or invoke it. * * Closure parameters: * 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
/* * Artifactory is a binaries repository manager. * Copyright (C) 2012 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/>. */ package plugin import org.artifactory.build.promotion.PromotionConfig import org.artifactory.build.staging.ModuleVersion import org.artifactory.build.staging.VcsConfig import org.artifactory.exception.CancelException
193
import org.artifactory.repo.RepoPathFactory import org.artifactory.request.Request import org.artifactory.util.StringInputStream /** * Globally available variables: * * log (org.slf4j.Logger) * repositories (org.artifactory.repo.Repositories repositories) * security (org.artifactory.security.Security security) * * context (org.artifactory.spring.InternalArtifactoryContext) - NOT A PUBLIC API - FOR INTERNAL USE ONLY! * * @author Yoav Landman */ /** * A section for handling and manipulating download events. */ download { /** * 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). * 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. * * Closure parameters: * repoPath (org.artifactory.repo.RepoPath) - a read-only parameter of the original request RepoPath. */ altResponse { request, responseRepoPath -> def path = responseRepoPath.path echo "Original PPP=${ path}" if (path.contains("replaceMe")) { def stringToReplace = repositories.getStringContent(repositories.getFileInfo(responseRepoPath)) def properties = request.getProperties() def replaced = stringToReplace.replace("{firstName}", properties.get("firstName").iterator().next()). replace("{lastName}", properties.get("lastName").iterator().next()) inputStream = new StringInputStream(replaced) size = inputStream.available() } else if (!path.contains('reject') && path.indexOf('.jar') > 0) { status = 202 //Do not change the message for properties request if (!request.uri.endsWith('properties')) { message = "Download accepted from ${request.getClientAddress()}" } def count = repositories.getProperty(responseRepoPath, 'count') count++ repositories.setProperty responseRepoPath, 'count', count++ } } /** * Provides an alternative download path under the same remote repository, by setting a new value to the path * variable. * * Context variables: * path (java.lang.String) - the new path value. Defaults to the originalRepoPath's path. * * Closure parameters: * repoPath (org.artifactory.repo.RepoPath) - a read-only parameter of the original request RepoPath. */
194
altRemotePath { repoPath -> echo "Original RepoPath=${ repoPath}" def origPath = repoPath.path def handleRequest = origPath.indexOf(':') < 0 && origPath.indexOf('.sha1') < 0 && origPath.indexOf('.jar') < 0 && origPath.indexOf('.xml') < 0 if (handleRequest) path += ".txt" echo "New Path=${path}" } /** * Provide an alternative download content, by setting new values for the inputStream and size variables. * context variable. * * Context variables: * 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: * repoPath (org.artifactory.repo.RepoPath) - a read-only parameter of the original request RepoPath. */ altRemoteContent { repoPath -> def repoUrl = getRemoteUrl(repoPath) def fullUrl = "${repoUrl}/${repoPath.path}" def origContent = fullUrl.toURL().text def newContent = origContent + " world" inputStream = new StringInputStream(newContent) size = inputStream.available() echo "returning $newContent as a stream with size $size" } /** * 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). * * Context variables: * 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). * 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: * repoPath (org.artifactory.repo.RepoPath) - a read-only parameter of the original request RepoPath. */ afterDownloadError { Request request -> switch (request.repoPath.path) { case 'keepError': //just keeping the error as it was break case 'return200': //return 200 instead of error, without body status = 200 message = 'All green' break case 'return501': //changing the error to be another one status = 501 message = 'Server error' break case 'replaceWithContent': //changing to 200 and attaching content status = 200 File content = new File(getClass().classLoader.getResource('build/dependency/bob/aaa.zip').toURI()) size = content.size() inputStream = content.newInputStream() }
195
} /** * Handle before remote download events. * * Closure parameters: * request (org.artifactory.request.Request) - a read-only parameter of the request. * repoPath (org.artifactory.repo.RepoPath) - a read-only parameter of the original request RepoPath. */ beforeRemoteDownload { request, repoPath -> def remoteAddress = request ? request.clientAddress : 'Someone' def remoteUrl = getRemoteUrl(repoPath) echo "${remoteAddress} is remote downloading '$repoPath' from '$remoteUrl'." } /** * Handle after remote download events. * * Closure parameters: * repoPath (org.artifactory.repo.RepoPath) - a read-only parameter of the original request RepoPath. */ afterRemoteDownload { repoPath -> def remoteUrl = getRemoteUrl(repoPath) echo "Downloaded '$repoPath' from '$remoteUrl'." } } /** * A section for handling and manipulating storage events. * * If you wish 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. * * Closure parameters: * item (org.artifactory.fs.ItemInfo) - the original item being created. */ beforeCreate { item -> def ff = item.isFolder() ? 'folder' : 'file' def username = security.currentUsername() echo "Before creating $ff $item.repoPath by ${username}" def path = item.repoPath.path //Reject if needed if (path.contains('reject')) { throw new CancelException("Artifact $path has been rejected!", 403) } if (path.indexOf('.jar') > 0) { //Deploy a dummy file with the name of the user def userFileRepoPath = RepoPathFactory.create(item.repoPath.repoKey, "test/$username") repositories.deploy userFileRepoPath, new ByteArrayInputStream() } } /** * Handle after create events. * * Closure parameters: * item (org.artifactory.fs.ItemInfo) - the original item being created. */ afterCreate { item -> if (item.repoPath.path.indexOf('.jar') > 0) { repositories.setProperty item.repoPath, 'count', '1' //Deploy a new text file with the list of artifacts under /test def tmpFile = File.createTempFile("rlist", "tmp"); def dirRepoPath = RepoPathFactory.create(item.repoPath.repoKey, "test") def children = repositories.getChildren(dirRepoPath) children.each { tmpFile << "${it.name}\n" } def listFileRepoPath = RepoPathFactory.create(item.repoPath.repoKey, "test/list.txt") tmpFile.withInputStream { is ->
196
repositories.deploy listFileRepoPath, is } tmpFile.delete() } } /** * Handle before create events. * * Closure parameters: * item (org.artifactory.fs.ItemInfo) - the original item being being deleted. */ beforeDelete { item -> } /** * Handle after create events. * * Closure parameters: * item (org.artifactory.fs.ItemInfo) - the original item deleted. */ afterDelete { item -> } /** * Handle before move events. * * Closure parameters: * item (org.artifactory.fs.ItemInfo) - the source item being moved. * targetRepoPath (org.artifactory.repo.RepoPath) - the target repoPath for the */ beforeMove { item, targetRepoPath -> } /** * Handle after move events. * * Closure parameters: * item (org.artifactory.fs.ItemInfo) - the source item moved. * targetRepoPath (org.artifactory.repo.RepoPath) - the target repoPath for the */ afterMove { item, targetRepoPath -> } /** * Handle before copy events. * * Closure parameters: * item (org.artifactory.fs.ItemInfo) - the source item being copied. * targetRepoPath (org.artifactory.repo.RepoPath) - the target repoPath for the */ beforeCopy { item, targetRepoPath -> } /** * Handle after copy events. * * Closure parameters: * item (org.artifactory.fs.ItemInfo) - the source item copied. * targetRepoPath (org.artifactory.repo.RepoPath) - the target repoPath for the */ afterCopy { item, targetRepoPath -> }
move.
move.
copy.
copy.
} /** * A section for defining 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. * * Parameters: * delay (long) - An initial delay in milliseconds before the job starts running (not
197
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) { def rp = RepoPathFactory.create("localhost-repo-cache", "test/test.txt") def exists = repositories.exists(rp) if (exists) { repositories.setProperty rp, "prop", "val" echo "Item at $rp exists." } else { echo "Item at $rp does not exist." } } mySecondJob(cron: "0/1 * * * * ?") { echo "Cron job running..." } } /** * A section for defining external executions. * External executions are invoked via REST POST requests. */ executions { /** * An execution definition. * The first value is a unique name for the execution. * * Context variables: * status (int) - a response status code. Defaults to -1 (unset). Not applicable for an async execution. * message (java.lang.String) - a text message to return in the response body, replacing the response content. * Defaults to null. Not applicable for an async execution. * * Closure parameters: * 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. */ multiply() { params -> def username = security.currentUsername() echo "Executing by ${username} with ${params}" //And the result is no1*no2 def res = params['no1'][0].toInteger() * params['no2'][0].toInteger() echo params['msg'][0] + res if (res > 100) { message = "Error - result must be less than 100!" status = 403 } } arny(version: "arny's version", description: "arny's description") { params -> echo "DOO EET! DOO EET NAUU!" } needsAuth(users: "nondeployer", groups: ["deployers"]) { params -> echo "I need authentication!" } responseChanger() { params -> message = params['message'][0] status = params['status'][0].toInteger() } } realms { successOnlyRealm(autoCreateUsers: true) { authenticate { username, credentials -> echo "Authenticating '${username}/${credentials}'..." true } userExists { username -> echo "Checking if user '${username}' exist..."
198
true } } } build { beforeSave { buildRun -> throw new CancelException('Cancelled, man...', 402) } afterSave { buildRun -> } } staging { strategy1(version: '1.0', description: 'desc', params: [key1: 'val1']) { buildName, params -> defaultModuleVersion = new ModuleVersion() moduleVersionsMap = [myModule: new ModuleVersion()] vcsConfig = new VcsConfig() promotionConfig = new PromotionConfig() } } promotions { promo1(version: '1.0', description: 'desc', params: [key1: 'val1']) { buildName, buildNumber, params -> message = 'promotionMessage' status = 402 } } def getRemoteUrl(repoPath) { def repoUrl = repositories.getRepositoryConfiguration(repoPath.repoKey).url return repoUrl }
199
def echo(str) { log.warn "##### " + str; }
YUM Repositories
Overview
Artifactory can act as a full-fledged YUM repository (since Artifactory 2.4.0). As such, it provides: 1. RPM metadata calculation for RPMs hosted in Artifactory local repositories. 2. Provisioning RPMs directly from Artifactory to YUM clients. 3. Detailed RPM metadata views from Artifactory's web UI.
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 repodata is created in the configured location within a local repository with the following files within it: repodata.xml.gz - Contains an XML file that describes the primary metadata of each RPM archive. filelists.xml.gz - Contains an XML file that describes all the files contained within each RPM archive. other.xml.gz - Contains an XML file that describes miscellaneous information regarding each RPM archive. repomd.xml - Contains information regarding all the other metadata files.
YUM Support is Platform Independent! Artifactory employes a pure Java-based RPM metadata calculation. Therefore, it does not rely on the existence of the createrepo binary or on running external processes on the host on which Artifactory is running.
Triggering RPM Metadata Updates

When enabled, the calculation is run in a number of ways: 1. 2. 3. 4. 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.
Metadata calculation will clean up pre-existing YUM metadata (existing as a result of manual deployment or import), including RPM metdata stored as SQLite DB files.
Configuration
To enable RPM metadata calculation on a local repository, browse within Artifactory's UI to the local repository configuration and select the YUM tab.
200
The Depth field tells Artifactory under which level of directory to search for RPMs and save the repodata directory. 0 is the default and refers to the repository's root folder; the calculator will search the entire repository for RPMs and save the repodata directory at $REPO-KEY/repodata. Using a different depth is useful in cases such as generating metadata for a repository that separates it's artifacts by name, version and architecture; for example, if the repository layout is similar to:
REPO_ROOT/$ARTIFACT_NAME/$ARTIFACT_VERSION/$ARCHITECTURE/FILE_NAME - or libs-release-local/foo/1.0/x64/foo-1.0-x64.rpm
And if you wish to generate RPM metadata for every artifact divided by name, you'd set the Depth to 1 and the repodata directory will be saved at REPO_ROOT/ARTIFACT_NAME/repodata
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 will normally occur 1-2 minutes after an RPM-related action has been completed.
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 Info tab:
201
P2 Repositories
Overview
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, Tycho and any other P2 clients. This virtual repository will aggregate P2 metadata and P2 artifacts from underlying standard local and remote repositories in Artifactory. This gives you full visibility of the P2 artifact sources, and allows powerful management of caching and security aspects for P2 content.
Configuring Artifactory
Virtual Repository Configuration
To enable P2 metadata aggregation on a virtual repository, create a virtual repository from Artifactory's UI and select the 'P2' tab.
202
On this tab, you will need to enable P2 support, and then add either a local repositories that host your P2 metdata and content or remote P2 repository URLs you wish to aggregate.
P2 Local Repository
Local repositories don't have any P2 dedicated configuration, simply choose the desired local repository from the repositories combo box and add a sub path which points to the P2 metadata files (content.jar, artifacts.jar, compositeContent.xml, etc.). When the sub path field is left empty, P2 metadata files are assumed to reside directly under 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 you added, you can (and should) include the repository in the list of (local and remote) repositories aggregated by this virtual repository. The following options are proposed for a remote repository in the repositories list table: 1. Include: Add the local repository to the list of repositories aggregated by this virtual repository. 2. Included: Shows the repository is already included in the virtual repository.
P2 Remote Repository
Select a P2 repository URL to add to Artifactory. The URL entered here should point at the path where P2 metadata files are found (
203
content.jar, artifacts.jar, compositeContent.xml, etc.). For example: 1. The main Juno repository: http://download.eclipse.org/releases/juno 2. The Google plugins repository for Indigo (GWT, GAE, etc.): http://dl.google.com/eclipse/plugin/3.7
In case where P2 metadata files reside inside an archived file, simply add '!' to the end of the URL, for example: http://eclipse.org/equinox-sdk.zip!/
Artifactory will analyze the added URL and, based on the remote P2 metadata, will identify which remote repositories are needed to be created in Artifactory (remote P2 repositories may aggregate information from different hosts). For each identified remote repository you can (and should) create and include the repository in the list of (local and remote) repositories aggregated by this virtual repository. The following options are proposed for a remote repository in the repositories list table: 1. 2. 3. 4. 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 repositories aggregated by this virtual repository. Included: Shows the repository is already included in the virtual repository.
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 manually controlled by browsing to a remote repository's configuration panel and selecting the 'Packages' tab.
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 optional sub path in them where Tycho builds artifacts reside.
P2 Client Configuration
Using Artifactory P2 Virtual Repository in Eclipse
Once the virtual repository is correctly configured, you will need to 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 http://yourserver/artifactory/p2 to the list of 'Available Software Sites':
204
NuGet Repositories
Overview
As of version 2.5, Artifactory provides complete support for NuGet repositories enhanced by Artifactory's existing support for advanced artifact management. The NuGet support in Artifactory provides: 1. 2. 3. 4. 5. 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.
Metadata updates NuGet metadata is calculated automatically upon adding and removing NuGet packages (including package moving and copying).
Configuration
Local and Remote Repositories
To enable NuGet package metadata calculation on repositories, browse the Artifactory UI to the desired repository configuration. When configuring local and remote repositories select the Packages tab:
205
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 it's feed resource at https://nuget.org/api/v2/Packages and its download resource at https://nuget.org/api/v2/package So the gallery's repository URL will point to https://nuget.org, its feed context path to api/v2 and its download context path to api/v2/package. On the other hand, the NuGet.Server module exposes its feed resource at http://myhost:myport/nuget/Packages and its download resource at http://myhost:myport/api/v2/package So the server's repository URL will point to http://myhost:myport, its feed context path to nuget and its download context path to api/v2/package.
NuGet metadata calculation is asynchronous and is throttled per repository and package ID; Artifactory invokes the actual calculation only after a certain "quiet period" following an action involving update or removal of an NuGet package. For this reason, the creation of the metadata will normally occur 30-60 seconds after an package-related action has been completed.
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.
206
When configuring virtual repositories select the NuGet tab:
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 API key. The API key you should use is in the form of username:password, where the password can be either clear-text or encrypted.
Viewing Individual NuGet Package Information
207
It is also possible to view all the metadata that annotates a NuGet package by choosing the NuPkg file in Artifactory's tree browser and selecting the NuPkg Info tab:
Repository Layouts
Background
Along with the growing number of choices for build-tools and frameworks also come 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're using Ivy or Gradle, there's 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 just 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 number of default predefined layouts that require no extra configuration: Maven 2/3 Ivy (default layout) Gradle (Wharf cache default layout) Maven 1
208
Support for repository layouts in Artifactory OSS Layout configuration is available only to Artifactory Powerpack users. Users of the OSS version can only configure their repositories to use the default repository layouts that are bundled with Artifactory.
Modules and Path Pattens used by Repository Layouts

Module Fields
To support smart module management, Artifactory needs to construct module information for stored files. Artifactory construct this information based on path pattern information defined as part of Repository Layout configuration (more on this 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 the minimum, there are 3 mandatory fields which are required for module identification, which are: Organization, Module and Base Revision. Field Organization Description a sequence of literals that identifies the artifact's organization a sequence of literals that identifies the artifact's module Example "org.slf4j" Mandatory
Module
"slf4j-api"
Base Revision
a sequence of literals that identifies the base revision part of the artifact version, excluding any integration information a sequence of literals that identifies the integration revision part used in folder names in the artifact's path, excluding the base revision a sequence of literals that identifies the integration revision part in the artifact's file name, excluding the base revision a sequence of literals that identifies the artifact's classifier a sequence of literals that identifies the artifact's extension 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
"1.5.10", or in case of an integration revision " 1.2-SNAPSHOT" the base revision is "1.2"
Folder Integration Revision File Integration Revision Classifier
in case of an integration revision "1.2-SNAPSHOT" the folder integration revision is "SNAPSHOT"
in case of an integration revision " 1.2-20110202.144533-3" the file integration revision is "20110202.144533-3" "sources"
Extension
"zip"
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 cool 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 in the previous paragraph. 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 .pom or an ivy.xml file).
209
The following tokens are available: Token [org] Description represents the Organization field where the levels are separated by dots ('.'), a-la Ivy. For example: "org.slf4j" represents the Organization field where the levels are separated by path separators ('/'), a la Maven. For example: "org/slf4j" represents the Base Revision field represents the Module field represents the Folder Integration Revision field represents the File Integration Revision field represents the Classifier field represents the Extension field represents the Type field A custom token. Can be used to create a new type of token when the provided defaults don't suffice. For example, [myIntegRev<ITEG-(?:[0-9]+)>] will create a new custom token named myIntegRev that matches the word ITEG followed by a dash and a minimum of one digit.
[orgPath]
[baseRev]
[module]
[folderItegRev]
[fileItegRev]
[classifier]
[ext]
[type]
[customTokenName<customTokenRegex>]
Multiple Custom Tokens Artifactory supports any number of custom tokens, but when provided with multiple custom tokens of the same key, Artifactory will only take 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]+>]
Will translate 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 "[module](-[classifier])" will match both " bobs-tools-sources" and "bobs-tools", and the pattern "[baseRev](-[fileItegRev])" will match both " 1.2-SNAPSHOT" and "1.2".
Artifact Path Patterns
An artifact path pattern represents the typical structure that all module artifacts are expected to be stored in.
210
For example To represent a normal Maven artifact path: " org/eclipse/jetty/jetty-ajp/7.0.2.v20100331/jetty-ajp-7.0.2.v20100331.jar" Use the artifact path pattern:
[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.v20100331.jar" Use the artifact path pattern:
[org]/[module]/[baseRev](-[folderItegRev])/[type]s/[module]-[baseRev](-[fileItegRev])(-[classifier]).[ext]
Descriptor Path Patterns
A descriptor path pattern is used as a way to recognize descriptor files (like .pom or ivy.xml files). Using a specific descriptor path pattern is optional. When not used, Artifactory will construct module information for descriptor file using the artifact path pattern. Even though descriptor paths patterns are optional, usage of them is highly recommended in cases of distinctive descriptors, such as Ivy ivy_-1.0.xml and Maven 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.v20100331.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 by browsing in the Artifactory UI to Admin->Configuration->Repository Layouts.
211
Additional layouts can be created from scratch by clicking the "New" button or by duplicating an existing layout by clicking the "Copy" button on a selected layout.
Path Patterns
Define the artifact path pattern and the descriptor path pattern (optional), as explained above.
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 ([org] or [orgPath], [module] and [baseRev]) within the directory structure itself. For example, Gradle's artifact path pattern:
[org]/[module]/[baseRev](-[folderItegRev])/[module]-[baseRev](-[fileItegRev])(-[classifier]).[ext]
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.
Avoid using capturing group syntax in regexp Regular expressions entered in these fields are wrapped and treated as a single capturing group. Please refrain from introducing any capturing groups within the expressions. Failure to do so may result in unexpected behavior and hurt the accuracy of the matcher.
Folder integration revision regular expression examples:
212
Maven's folder integration revision is simply the constant -SNAPSHOTappended to the base revision ("1.2-SNAPSHOT"), so the regular expression will be just
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 -SNAPSHOTconstant ("1.2-SNAPSHOT") or a timestamp, where the date and time are 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're done configuring your layout, you can test it out via the UI on an artifact or a descriptor path, and see how Artifactory would build module information from the path, using the layout definitions.
213
Repository Configuration
Local Repository Configuration
Layouts are mandatory for local repositories, since they define the structure of the artifact storage. Note: Repositories configured prior to the introduction of custom repository layouts will be auto-configured with the default Maven 2 layout.
214
Remote Repository Configuration
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 will be 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 will handle Maven 2 requests and artifact storage, and configure the remote target to use Maven 1's layout so that outgoing requests will be translated to Maven 1's convention. Note: Caches of remote repositories configured prior to the introduction of the repository layouts will be auto-configured with the default Maven 2 layout.
215
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 will attempt 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 will not be made and requests will 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
216
Smart Searches
Introduction
Smart searches allow you to manage your artifacts by searching and performing bulk operations on search results. This allow for natural and easy support for things like artifact promotion, procurement flows and so on. 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 that were deployed by a certain build (by build number), remove from this search results all the sources (by making another search) and promote it to a public repository. Or, 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 lets you delegate authentication requests to Atlassian Crowd and use authenticated Crowd users, and have Artifactory participate in a transparent SSO environment managed by Crowd.
Usage
To enable Crowd integration, you must first define Artifactory as a custom application client inside Crowd. Crowd integration can then be configured under Admin:Security:Crowd SSO.
217
Fill in the Crowd server URL, and the application credentials you've defined in the previous step. The session validation interval defines the principal token validity time in minutes. If left at the default of 0, the token will expire 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 Configuration check-box. It is possible instruct Artifactory to treat externally authenticated users as temporary users, so that Artifactory doesn't automatically create them in its security store. In this case, permissions for such users will be based on the permissions given to auto-join groups.
System properties Crowd configuration properties may be added to the Runtime system properties or to the $ARTIFACTORY_HOME/etc/artifactory.system.properties file. Please note that setting a configuration through properties will override configurations that were set through the UI.
Finally, you may test the configured connection and save it.
Crowd Groups
To use Crowd groups you first need to set up a Crowd server for authentication as detailed above. Once you have configured your Crowd server, you can verify your setup by clicking the Refresh button on the Synchronize Crowd Groups sub-panel. You should get a list of available Crowd groups, according to your settings. The groups table lets you 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.
218
You can manage permissions on the synced Crowd groups as you do with regular Artifactory groups. Users association to these groups is external and controlled strictly by Crowd.
Make sure the Crowd group settings is enabled in order for your settings to become effective.
Single Sign-on
Overview
The Single Sign-on (SSO) add-on lets you 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 Admin:Security:HTTP SSO. To enable SSO you need to let Artifactory know that it is running behind a secure HTTP server that forwards trusted requests to it. Next, you need to 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.
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.
Finally, you can instruct Artifactory to treat externally authenticated users as temporary users, so that Artifactory doesn't create them in its security database. In this case, permissions for such users will be base on the permissions given to auto-join groups.
219
Integrating Apache and Tomcat

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 configuration. If using mod_proxy (requires mod_proxy_http, mod_headers and mod_rewrite - There are two known working methods that forward the header:
RequestHeader set REMOTE_USER %{REMOTE_USER}e
or
RewriteEngine On RewriteCond %{REMOTE_USER} (.+) RewriteRule . - [E=RU:%1] RequestHeader set REMOTE_USER %{RU}e
Filtered Resources
Overview
The Filtered Resources add-on (introduced in Artifactory version 2.3.3) allows for treating any textual file as a filtered resource by processing it as a FreeMarker template. Each file artifact can be marked as 'filtered' and upon a download request, the content of the artifact will be 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), letting you 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.
220
Marking an Artifact as a Filtered Resource

Each artifact can become filtered by selecting it in the artifacts Tree Browser and checking the checkbox labeled 'Filtered' located in the 'General' info tab. This requires the user to have 'annotate' permissions on the artifact.
Filtering Context
Artifactory provides the following environment variables for the FreeMarker template: "properties" (org.artifactory.md.Properties) - Contains the properties of the requested artifact and any matrix params included in the request; when a clash of properties with identical keys occurs, the former takes precedence. "request" (org.artifactory.request.Request) - The current request that was sent for the artifact. "security" (org.artifactory.security.Security) - Artifactory's current security object.
Provisioning Build Tool Settings

When logged-in as an admin user, you can provision for your users generated settings for the various build tools (Maven, Gradle and Ivy) using the on the Filtered Resources features. To do this, follow these steps: 1. 2. 3. 4. 5. 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 Press deploy.
221
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 'vcs.rootUrl' property on the 'vcsProj.conf.xml' artifact is 'http://vcs.company.com' and the file is downloaded by a developer belonging to the 'dev-product2' group, then the returned content will be:
<servers> <vcs> http://vcs.company.com/product2 </vcs> </servers>
Watches
Overview
Watches let you monitor selected artifacts, folders, or repositories for storage events (create/delete/modify) and receive focused email notifications on repository changes that are interesting to you.
222
You can add and remove watches from the 'General' tab in the tree browser. Watches or folders will intercept changes on all children. An admin can view and manage watches via the 'Watches' tab in the tree browser. Watch notifications are aggregated around 1 minute intervals and sent in a single email message. All notifications respect the watcher's read permissions on the watched item(s).
WebStart and Jar Signing

Watch the Screencast 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 for free (no question asked) for 30 days, this add-on with the 2 main repositories needed (jfrog plugins, jfrog libs), using Artifactory Online.
How to build FishSim

If you are not using Artifactory like in the screencast, you can activate the profile "jfrog" to access the repo.jfrog.org needed resources. So, to build running "mvn -Pjfrog install" should work.
Troubleshooting
The Artifactory Mailing Lists
The best way to get help is to use our Artifactory Users mailing list: Archive using Nabble Subscribe using mailman
Misc Troubleshooting Tips

The following section contains various troubleshooting tips for commonly encountered use-cases: Dealing with Broken Index
Dealing with Broken Index

Overview
In rare cases it may happen that the underlying Jackrabbit index used by Artifactory would become broken. This can occur if the Artifactory VM is abruptly killed when write operations are done on the index, therefore it is recommended to always shutdown Artifactory gracefully. Another reason this might happen is lack of disk space or disk problems. Typically, when the index is broken, you'd see warnings in the logs similar to this:
223
2009-08-13 11:11:37,704 [WARN ] (o.a.j.c.q.l.QueryResultImpl:494) - Exception retrieving Node with UUID: javax.jcr.ItemNotFoundException: 2009-08-13 11:11:37,705 [WARN ] (o.a.j.c.q.l.QueryResultImpl:494) - Exception retrieving Node with UUID: javax.jcr.ItemNotFoundException: 2009-08-13 11:11:37,860 [WARN ] (o.a.j.c.q.l.QueryResultImpl:494) - Exception retrieving Node with UUID: javax.jcr.ItemNotFoundException:
or:
java.io.EOFException at java.io.DataInputStream.readInt(DataInputStream.java:358) [na:1.5.0_17] at org.apache.jackrabbit.core.query.lucene.IndexInfos.read(IndexInfos.java:101) [jackrabbit-core-1.5.3.jar:na] at org.apache.jackrabbit.core.query.lucene.MultiIndex.<init>(MultiIndex.java:246) [jackrabbit-core-1.5.3.jar:na] at org.apache.jackrabbit.core.query.lucene.SearchIndex.doInit(SearchIndex.java:456) [jackrabbit-core-1.5.3.jar:na] at org.apache.jackrabbit.core.query.AbstractQueryHandler.init(AbstractQueryHandler.java:59) [jackrabbit-core-1.5.3.jar:na] at org.apache.jackrabbit.core.SearchManager.initializeQueryHandler(SearchManager.java:553) [jackrabbit-core-1.5.3.jar:na]
Resolution
Should this happen, it is easy to fix the broken index by rebuilding a new healthy index. Follow these steps: 1. After Artifactory is shut-down, move the $ARTIFACTORY_HOME/data/index folder aside. 2. Restart Artifactory. 3. Allow some time for re-indexing to complete - it may take more than a couple of minutes on a large repository and will delay the startup process until finished.
Consistency Fix
If you are still experiencing errors you may need to start Artifactory with consistency fix checks on For Artifactory 2.4.x and above
Remove the following file and restart Artifactory:
$ARTIFACTORY_HOME/data/.deleteForConsistencyFix
Make sure to let the Artifactory startup process finish with no interruption. This may take considerably longer when consistency fix is active. There is no other operation required after startup has finished.
For Artifactory 2.3.x and below
Start Artifactory once with the VM parameter -Dartifactory.jcr.fixConsistency=true
You can do this by commenting-out/changing the artifactory.jcr.fixConsistency property in artifactory.system.properties, just don't leave this on permanently, as it will slow-down the startup process dramatically on each Artifactory restart.
224

Artifactory User Guide.

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Artifactory User Guide.

Transféré par

Droits d'auteur :

Formats disponibles

Artifactory User Guide

Artifactory User Guide

Welcome to the Artifactory User Guide!

Copyright 2012 JFrog Ltd.

After successfully installing Artifactory, it should be available locally at: http://localhost:8081/artifactory.

Installing Artifactory as Linux Service

etc config etc default

Copyright 2012 JFrog Ltd.

Logs folder Backup folder

Data folder chkconfig calls

service artifactory start

You can then check the Artifactory log with:

Running Artifactory Manually on Unix

Installing Artifactory as a Windows Service Overview

Copyright 2012 JFrog Ltd.

Running Artifactory Manually on Windows

Managed Files And Folders

MySQL Additional Configuration

Copyright 2012 JFrog Ltd.

To install Artifactory use:

rpm -ivh artifactory-rpm-<version>.rpm

Deployment on Other Servlet Containers

GlassFish requires Artifactory 2.0.1 and above.

Deploying the WAR File

The $ARTIFACTORY_HOME Folder

Copyright 2012 JFrog Ltd.

Dedicated Tomcat Instance

Automatic Installation on a Dedicated Tomcat Instance

Copyright 2012 JFrog Ltd.

export JAVA_OPTS="$JAVA_OPTS -Djboss.platform.mbeanserver"

Deploying on IBM Websphere

Running Behind Apache HTTPd

Copyright 2012 JFrog Ltd.

Client ----------> HTTPD ----------> Artifactory HTTP HTTP/AJP

Configuring Apache with mod_ajp Installed

Configuring Apache with changing the artifactory path

Copyright 2012 JFrog Ltd.

<Connector port="8009" protocol="AJP/1.3" maxThreads="500" minSpareThreads="20" maxSpareThreads="150" enableLookups="false" disableUploadTimeout="true" backlog="100"/>

See here for more configuration options.

Using HTTP Proxy

<Connector port="8081" protocol="HTTP/1.1" maxThreads="500" minSpareThreads="20" maxSpareThreads="150" enableLookups="false" disableUploadTimeout="true" backlog="100"/>

See here for more configuration options.

Proxying Apache HTTPs to Artifactory running HTTP

Copyright 2012 JFrog Ltd.

Client ----------> HTTPD ----------> Artifactory HTTPs HTTP/AJP

Using HTTP Proxy

Changing the Default Storage

Once-and-Only-Once Identical Content Storage

Changing the Storage Type Used

Copyright 2012 JFrog Ltd.

When Artifactory is Deployed as a WAR

The Bundled Storage Configurations

Database Storage Types

File System Storage Types

Copyright 2012 JFrog Ltd.

Accessing a Remote Database

Running Artifactory on MySQL

Create the Artifactory MySQL Database

Increasing MySQL's Default Packet Size

Copyright 2012 JFrog Ltd.

Configure Artifactory to Use the MySQL Database

When Running the Artifactory WAR in a Servlet Container

Copyright 2012 JFrog Ltd.

When Running Standalone Artifactory

Includes Pattern: org/apache/,com/acme/ Excludes Pattern: com/acme/exp-project/**