Repository Management With Nexus

Ed. 3.0.
Repository Management with Nexus

i
Ed. 3.0.2
Ed. 3.0.2

ii
Copyright 2011 Sonatype, Inc.
Ed. 3.0.2

iii
Contents
Introducing Sonatype Nexus 1.1 1.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nexus Open Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 1.2.2 1.3 Nexus Open Source Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nexus Open Source License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 1 1 1 2 2 3 4 4 4 5 5 6 7 7 7 7 8 8 8 9 9
Nexus Professional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.1 1.3.2 Nexus Professional Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nexus Professional License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4
Choosing a Nexus Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.1 1.4.2 1.4.3 Use Nexus Open Source. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use Nexus Professional. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Comparing Nexus Open Source and Nexus Professional Features . . . . . . . . . . . . . . . . . . . . .
1.5 2
History of Nexus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Repository Management 2.1 Repository Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 2.1.2 2.1.3 2.1.4 2.2 Proxying Public Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing Releases and Snapshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Getting Control of Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A Nexus for Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
What is a Repository? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 2.2.2 2.2.3 2.2.4 Release and Snapshot Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Repository Coordinates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Addressing Resources in a Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 The Maven Central Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3
What is a Repository Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.1 2.3.2 Core Capabilities of a Repository Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Additional Features of a Repository Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4
Reasons to Use a Repository Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.4.1 Speed Up Your Builds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Ed. 3.0.2

iv
2.4.2 2.4.3 2.4.4 2.4.5 2.4.6 2.4.7 2.4.8 2.5
Save Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Ease the Burden on Central . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Gain Predictability and Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Control and Audit Dependencies and Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Deploy 3rd Party Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Collaborate with Internal Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Distribute with Public Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Adopting a Repository Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5.1 2.5.2 2.5.3 2.5.4 2.5.5 Stage Zero: Before Using a Repository Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Stage One: Proxying Remote Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Stage Two: Hosting a Repository Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Stage Three: Continuous Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Stage Four: Lifecycle Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 18
Installing and Running Nexus 3.1
Downloading Nexus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.1.1 3.1.2 Downloading Nexus Open Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Downloading Nexus Professional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2
Installing Nexus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2.1 3.2.2 3.2.3 Nexus Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Installing Nexus Open Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Installing Nexus Professional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 3.4 3.5 3.6
Upgrading Nexus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Running Nexus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Post-Install Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Conguring Nexus as a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.6.1 Startup Scripts for GNU/Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.6.1.1 3.6.1.2 Add Nexus as a Service on Redhat, Fedora, and CentOS . . . . . . . . . . . . . . . . . . . . . 25 Add Nexus as a Service on Ubuntu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.7 3.8
Running Nexus Behind a Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Installing the Nexus WAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.8.1 Running the Nexus WAR in Glasssh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.9
Installing a Nexus Professional License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.9.1 Evaluation Expiration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.10 Sonatype Nexus Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.10.1 Sonatype Nexus Work Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.10.2 Nexus Conguration Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Ed. 3.0.2

v
Conguring Maven to Use Nexus 4.1 4.2 4.3 4.4 4.5
34
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Conguring Maven to Use a Single Nexus Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Adding Custom Repositories for Missing Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Adding a New Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Adding a Repository to a Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 38
Using Nexus 5.1 5.2
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Browsing Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.2.1 5.2.2 5.2.3 View Artifact Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Viewing Artifact Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Editing Artifact Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3 5.4
Browsing Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Searching for Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.4.1 5.4.2 Nexus OpenSearch Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Searching Artifact Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.5 5.6 5.7 5.8 5.9 6
Uploading Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Browsing System Feeds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Log Files and Conguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Changing Your Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Filing a Problem Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 55
Conguring Nexus 6.1 6.2 6.3 6.4 6.5
Conguring Nexus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Customizing Server Conguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Conguring Automated Error Reporting Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 New Version Notication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Managing Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 6.5.1 6.5.2 6.5.3 6.5.4 Selecting Mirrors for Proxy Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Adding a Mirror Entry for a Hosted Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Viewing Repository Summary Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Auto Block/Unblock of Remote Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.6 6.7 6.8
Managing Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Managing Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Managing Scheduled Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 6.8.1 Managing Conguration Backups with a Scheduled Task . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.9
Managing Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.10 Managing Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Ed. 3.0.2

vi
6.11 Managing Repository Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 6.12 Managing Security Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 6.13 Managing Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 6.14 Network Conguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 6.15 Nexus Logging Conguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 6.16 Managing Nexus Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 7 Nexus LDAP Integration 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 91
Enabling the LDAP Authentication Realm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Conguring Nexus LDAP Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Connection and Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 User and Group Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Mapping Users and Groups with Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Mapping Users and Groups with posixAccount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Mapping Roles to LDAP Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Mapping Nexus Roles for External Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Mapping External Roles to Nexus Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
7.10 Enterprise LDAP Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 7.10.1 Support for Multiple Servers and LDAP Schemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 7.10.2 Enterprise LDAP Performance Caching and Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 7.10.3 User and Group Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 7.10.4 Testing a User Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 8 Nexus Procurement Suite 8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9 110
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 The Stages of Procurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Two Approaches to Procurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Procured Development Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Installing the Procurement Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Setting up a Procured Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Enable Remote Index Downloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Create a Hosted Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Conguring Procurement for Hosted Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
8.10 Procured Repository Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 8.11 Viewing the Procurement Management Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 8.12 Conguring a Procurement Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 8.13 Managing Procurement Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 8.14 Stopping Procurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Ed. 3.0.2

vii
Build Promotion with the Nexus Staging Suite 9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9
125
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Releasing Software with a Staging Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 How the Staging Suite Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Multi-level Staging and Build Promotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Using the Nexus Staging Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Conguring Staging Proles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Conguring a Repository Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Conguring Staging Proles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Conguring Build Promotion Proles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
9.10 Adding the Staging Deployer Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 9.11 Performing a Staged Deployment with Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 9.12 Creating a New Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 9.13 Update the POM: Deployment Conguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 9.14 Update settings.xml with Deployment Credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 9.15 Deploying to a Staged Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 9.16 Uploading a Staged Deployment in Nexus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 9.17 Managing Rulesets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 9.18 Managing Staging Rulesets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 9.19 Dening Rulesets for Promotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 9.20 Managing Staging Repositories in Nexus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 9.21 Closing an Open Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 9.22 Using the Staging Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 9.23 Releasing a Staging Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 9.24 Promoting a Staging Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 9.25 Releasing, Promoting, and Dropping Build Promotion Proles . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 9.26 Managing Staging Repositories with the Nexus Maven Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 9.27 Running the Nexus Maven Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 9.28 Conguring Nexus Maven Plugin for Staging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 9.28.1 Listing Your Open Staging Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 9.28.2 Closing a Staging Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 9.28.3 Dropping a Closed Staging Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
9.28.4 Promoting a Closed Staging Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 10 Managing Maven Settings 154
10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 10.2 Manage Maven Settings Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 10.3 Downloading Maven Settings with the Nexus Maven Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 10.3.1 Running the Nexus Maven Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 10.3.2 Conguring Nexus Maven Plugin for Settings Management . . . . . . . . . . . . . . . . . . . . . . . . 156 10.3.3 Downloading Maven Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Ed. 3.0.2

viii
11 OSGi Bundle Repositories
158
11.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 11.2 Managing OSGi Bundle Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 11.3 Proxy OSGi Bundle Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 11.4 Hosted OSGi Bundle Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 11.5 Virtual OSGi Bundle Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 11.6 Grouping OSGi Bundle Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 12 P2 Repositories 163
12.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 12.1.1 Managing P2 Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 12.1.1.1 Proxy P2 Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 12.1.2 Grouping P2 Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 13 Deploying Sites to Nexus 166
13.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 13.1.1 Creating a New Maven Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 13.1.2 Conguring Maven for Site Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 13.1.3 Adding Credentials to Your Maven Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 13.1.4 Creating a Maven Site Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 13.1.5 Add the Site Deployment Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 13.1.6 Publishing a Maven Site to Nexus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 14 User Account Plugin 172
14.1 Installing the User Account Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 14.2 Conguring the User Account Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 14.3 Signing Up for an Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 14.4 Manual Activation of New Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 14.5 Modifying Default User Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 15 Nexus Atlassian Crowd Plugin 178
15.1 Installing the Crowd Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 15.2 Conguring the Crowd Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 15.3 Crowd Access Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 15.3.1 Crowd HTTP Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 15.3.2 Crowd HTTP Proxy Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 15.3.3 Miscellaneous Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 15.4 Adding the Crowd Authentication Realm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 15.5 Conguring a Nexus Application in Crowd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 15.6 Mapping Crowd Groups to Nexus Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 15.7 Adding a Crowd Role to a Nexus User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Ed. 3.0.2

ix
16 Artifact Bundles
188
16.1 Creating an Artifact Bundle from a Maven Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 16.2 Uploading an Artifact Bundle to Nexus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 17 Nexus Best Practices 194
17.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 17.2 Repositories per Project/Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 17.3 Partition Shared Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 17.3.1 Selecting an Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 18 Developing Nexus Plugins 196
18.1 Nexus Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 18.1.1 Nexus Plugin API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 18.2 Nexus Extension Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 18.3 Nexus Plugin Extension Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 18.4 Nexus Plugin Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 18.5 Nexus Index HTML Customizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 18.6 Static Plugin Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 18.7 Plugin Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 18.8 Event Inspectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 18.9 Content Generators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 18.10Content Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 18.11Storage Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 18.12Repository Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 18.13Item and File Inspectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 18.14Nexus Feeds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 18.15Nexus Tasks and Task Conguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 18.16Application Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 18.17Request Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 18.18Using the Nexus Plugin Archetype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 18.19Set the Target Nexus Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 18.20Building a Nexus Plugin Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 18.21Creating a Complex Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 18.22Nexus Plugin Descriptor Maven Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 18.23The Nexus Plugin Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 18.24Dening Custom Repository Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Ed. 3.0.2

x
A Migrating to Nexus from Artifactory
208
A.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 A.2 Creating an Artifactory Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 A.3 Installation of the Migration Plugin and Artifactory Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 A.4 Importing an Artifactory System Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 A.5 Conguring the Artifactory Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 A.6 Conguring Artifactory Group Imports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 A.7 Conguring Artifactory Repository Imports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 A.8 Conguring Users and Privileges in the Artifactory Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 A.9 Performing the Artifactory Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 A.10 Conguring Artifactory Clients to Use Nexus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 B Migrating to Nexus from Archiva 219
B.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 B.2 Migrating Archiva Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 B.3 Migrating an Archiva Managed Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 B.4 Migrating an Archiva Proxy Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 C Conguring Nexus for SSL 228
C.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 C.2 Importing a SSL Client Certicate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 C.2.1 C.2.2 C.2.3 C.2.4 C.2.5 C.3.1 C.3.2 C.3.3 Downloading the SSL Import Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 Importing a Client Certicate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 Import the Server SSL Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Import the Client SSL Key/Certicate Pair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Conguring Nexus Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Congure the Java Keystore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Congure Nexus/Jetty to Use the New Keystore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Modify the application-port for SSL connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
C.3 Conguring Nexus to Serve SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
C.4 Redirecting Non-SSL Connections to SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 D Contributing to the Nexus Book 234
D.1 Contributor License Agreement (CLA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 D.2 Contributors, Authors, and Editors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 D.3 Tools Used to Build and Write this Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 D.4 How to Build the Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 D.5 Subscribing to the Book Developers List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 E Copyright F Creative Commons License F.1 F.2 237 238
Creative Commons BY-NC-ND 3.0 US License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Creative Commons Notice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Abstract
Nexus manages software artifacts required for development, deployment, and provisioning. If you develop software, Nexus can help you share those artifacts with other developers and end-users. Mavens central repository has always served as a great convenience for users of Maven, but it has always been recommended to maintain your own repositories to ensure stability within your organization. Nexus greatly simplies the maintenance of your own internal repositories and access to external repositories. With Nexus you can completely control access to, and deployment of, every artifact in your organization from a single location.
Ed. 3.0.2

1 / 241
Chapter 1
Introducing Sonatype Nexus

1.1 Introduction
Nexus manages software "artifacts" required for development, deployment, and provisioning. If you develop software, Nexus can help you share those artifacts with other developers and end-users. Mavens central repository has always served as a great convenience for users of Maven, but it has always been recommended to maintain your own repositories to ensure stability within your organization. Nexus greatly simplies the maintenance of your own internal repositories and access to external repositories. With Nexus you can completely control access to, and deployment of, every artifact in your organization from a single location.
1.2
Nexus Open Source
Nexus Open Source provides you with an essential level of control over the external Maven repositories you use and the internal repositories you create. It provides infrastructure and services for organizations that use repository managers to obtain and deliver software. If you create software libraries or applications for your end-users, you can use Nexus Open Source to distribute your software. If your software depends upon open source software components, you can cache software artifacts from remote repositories.
1.2.1
Nexus Open Source Features
Hosting Repositories When you host a Maven repository with Nexus Open Source, you can upload artifacts using the Nexus interface, or you can deploy artifacts to hosted repositories using Maven. Nexus will also create the standard Nexus Index for all of your hosted repositories which will allow tools like m2eclipse to rapidly locate software artifacts for your developers. Proxy Remote Repositories When you proxy a remote repository with Nexus Open source you can control all aspects of the connection to a remote repository including security parameters, HTTP proxy settings. You can congure which mirrors Nexus will download artifacts from, and you can control how long Nexus will store artifacts and how it will expire artifacts which are no longer referenced by your build. Repository Groups Grouping repositories allows you to consolidate multiple repositories into a single URL. This makes conguring your development environment very easy. All of your developers can point to a single repository group URL, and if anyone ever needs a custom remote repository added to the group, you can do this in a central location without having to modify every developers workstation. Fine-grained Security Model Nexus Open Source ships with a very capable and customizable security model. Every operation in Nexus is associated
Ed. 3.0.2

2 / 241
with a privilege, and privileges can be combined into standard Nexus roles. Users can then be assigned both individual privileges and roles that can be applied globally or at a ne grained level. You can create custom administrative roles that limit certain repository actions such as deployment to specic groups of developers and you can use these security roles to model the structure of your organization. Flexible LDAP Integration If your organization uses an LDAP server, Nexus Professional can integrate with an external authentication and access control system. Nexus Professional is smart enough to be able to automatically map LDAP groups to the appropriate Nexus roles, and it also provides a very exible facility for mapping existing users and existing roles to Nexus roles. Artifact Search Nexus Open Source provides an intuitive search feature which allows you to search for software artifacts by identiers such as groupId, artifactId, version, classier, and packaging, names of classes contained in Java archives, keywords, and artifact checksums. Nexus search makes use of the industry standard for repository indexes, the Nexus Index format, and Nexus will automatically download a Nexus index from all remote repositories which create a Nexus index. Nexus will also automatically expose a Nexus index for any hosted repositories you create. Scheduled Tasks Nexus Open Source has the concept of scheduled tasks: periodic jobs which take care of various repository management tasks such as deleting old snapshots, evicting unused items, and publishing repository indexes. REST Services Nexus Open Source is based on a series of REST services, and when you are using the Nexus web front-end UI, you are really just interacting with a set of REST service. Because of this open architecture, you can leverage the REST service to create custom interactions or to automate repository management with your own scripts. Nexus Plugins Nexus Open Source provides a rich API for extension in the form of Nexus Plugins. When you write a Nexus Plugin, you can customize REST services, the Nexus UI, repository formats, or write components that can intercept requests and add new capabilities to the platform. The plugin API which you have access to in Nexus Open Source is the same plugin API that is used to implement value-added features available in Nexus Professional. Integration with m2eclipse When you use Nexus as a repository manager it creates indexes that support some of the next-generation tools available in m2eclipse - Sonatypes Maven plugin for the Eclipse IDE. If you publish new artifacts and archetypes to Nexus, they are immediately available to m2eclipse project creation wizards and are included in m2eclipse search results.
1.2.2
Nexus Open Source License
Nexus Open Source is available under the GNU Affero General Public License version 3 (AGPLv3). The text of this license is available from the Open Source Initiative (OSI) here: http://opensource.org/licenses/agpl-v3.html The Nexus Indexer is made available under the Eclipse Public License version 1.0. The text of this license is available from the Open Source Initiative (OSI) here: http://www.opensource.org/licenses/eclipse-1.0.php
1.3
Nexus Professional
Nexus Professional was designed to meet the needs of the enterprise. It is a central point of access to external repositories which provides the necessary controls to make sure that only approved artifacts enter into your software development environment. It is also a central distribution point with the intelligence required to support the decision that go into making quality software. The extensibility provided by the custom metadata plugin coupled with REST services only available in Nexus Professional also lay the foundation for highly complex interactions within the enterprise. Once you start to use the workow and decision support features of Nexus Professional, you will start to see it as the "assembly line" - the central collaboration point for your software development efforts.
Ed. 3.0.2

3 / 241
1.3.1
Nexus Professional Features
Nexus Procurement Suite Consider the default behavior of a proxy repository. Any developer can reference any artifact stored in a remote repository and cause Nexus to retrieve the artifact from the remote repository and serve back to a developer. Very often a company might want to control the set of artifacts which can be referenced in a proxy repository. Maybe the company has unique security requirements which require every third-party library to be subjected to a rigorous security audit before they can used. Or, maybe another company has a legal team which needs to verify that every artifact referenced by your software adheres to an inexible set of license guidelines. The Nexus Procurement Suite was design to give organization this level of control over the artifacts that can be served from Nexus. Nexus Staging Suite When was the last time you did a software release to a production system? Did it involve a QA team that had to sign-off on a particular build? What was the process you used to re-deploy a new build if QA found a problem with the system at the last minute? Because few organizations use a mature process to manage binary software artifacts, there is little in the way of infrastructure designed to keep track of the output of a build. The Nexus Staging Suite changes this by provide workow support for binary software artifacts. If you need to create a release artifact and deploy it to a hosted repository, you can use the Staging Suite to post a collection of related, staged artifacts which can be tested, promoted, or discarded as a unit. Nexus keeps track of the individuals that are involved in a staged, managed release and can be used to support the decisions that go into producing quality software. Hosting Project Web Sites Nexus Professional is a publishing destination for project web sites. While you very easily generate a project web site with Maven, without Nexus, you will need to set up a WebDAV server and congure both your web server and build with the appropriate security credentials. With Nexus, you can deploy your projects web site to the same infrastructure that hosts the projects build output. This single destination for binaries and documentation helps to minimize the number of moving parts in your development environment. You dont have to worry about conguring another web server or conguring your builds to distribute the project site using a different protocol, you simple point your project at Nexus and deploy the project site. Support for OSGi Repositories Instead of just supporting Maven repositories, Nexus Professional supports OSGi Bundle repositories and P2 repositories for those developers who are targeting OSGi or the Eclipse platform. Just like you can proxy, host, and group Maven repositories, Nexus Professional allows you to do the same with OSGi repositories. Enterprise LDAP Support Nexus Professional offers LDAP support features for enterprise LDAP deployments including detailed conguration of cache parameters, support for multiple LDAP servers and backup mirrors, the ability to test user logins, support for common user/group mapping templates, and the ability to support more than one schema across multiple servers. Support for Atlassian Crowd If your organization uses Atlassian Crowd, Nexus Professional can delegate authentication and access control to a Crowd server and map Crowd groups to the appropriate Nexus roles. The User Account Plugin When you are running a large, public instance of Nexus, it is often very useful to allow users to sign up for an account without the assistance of an administrator. Nexus Professionals User Account plugin allows for just this. With this plugin activate, a new user simply has to ll out a simple form and type in letters from a CAPTCHA. Once a user has signed up for Nexus, Nexus will then send an email with a validation link. If you are working in an environment with hundreds or thousand of users the user account plugin will allow you to support the tool without having to create logins for each individual user. Maven Settings Management Nexus Professional along with the Nexus Maven Plugin allow you to manage Maven Settings. Once you have developed a Maven Settings template, developers can then connect to Nexus Professional using the Nexus Maven plugin which will take responsibility for downloading a Maven Settings le from Nexus and replacing the existing Maven Settings on a local workstation.
Ed. 3.0.2

4 / 241
Support for Artifact Bundles When software is deployed to the Maven Central repository, it is deployed as a signed artifact bundle. Nexus Professionals Staging Suite allows you to upload artifact bundles to a staged repository. Artifact Validation and Verication The software artifacts you download from a remote repository are often signed with PGP signatures. Nexus Professional will make sure that these PGP signature are valid and the procurement plugin denes a few other rules that can be applied to artifacts which are downloaded from remote repositories. Nexus Professional also denes an API which allows you to create your own custom verication rules. Custom Repository Metadata Nexus Professional provides a facility for user-dened, custom metadata. If you need to keep track of custom attributes to support approval workow or to associate custom identiers with software artifacts, you can use Nexus to dene and manipulate custom attributes which can be associated with artifacts in a Nexus repository.
1.3.2
Nexus Professional License
Nexus Professional is made available under a commercial license for businesses. Is available for free for use in qualifying Open Source projects, and is available at a discount for select Non-prots.
1.4
Choosing a Nexus Edition
If you are wondering which edition is appropriate for your organization. The following sections outline some reasons for choosing either Nexus Open Source of Nexus Professional.
1.4.1
Use Nexus Open Source. . .
. . . if you are new to Repository Management If you are new to repository management, you should pick up a copy of Nexus Open Source, and experiment with Hosted and Proxy repositories. You should get a sense of how Maven Settings are congured to retrieve artifacts from a single Repository Group, and you should download a copy of the free Nexus book - Repository Management with Nexus. Once youve familiarized yourself with Nexus Open Source, you can easily upgrade to Nexus Professional by downloading and installing Nexus Professional. Nexus stores all of your repository data and conguration in a directory named sonatypework which is separate from the Nexus application directory. . . . if you are looking for more stability and control If you depend directly on public repositories such as the Maven Central repository or the various repositories maintained by organizations like Codehaus or the Apache Software Foundation, you rely on these servers to be available to your developers 100% of the time. If a public repository goes down for maintenance, so does your development process. With a local proxy of Maven artifacts, you buy yourself a stable, isolated build. Even if a public repositories becomes unavailable, you will still be able to build your software against artifacts cached in your own Nexus installation. . . . if you need to manage internal software distribution If your organization needs to support collaboration between internal teams, you can use Nexus to support the distribution of internal software. With Nexus, sharing components between internal groups is as easy as adding a dependency from Maven Central. Just publish a JAR to Nexus, congure the appropriate repositories groups and inform others in our organization of the Maven coordinates. Using a repository management doesnt just make it easier to proxy external software artifacts, it makes it easier to share internal artifacts. . . . if you need an intelligent local proxy Many developers run Nexus on a local workstation as a way to gain more control over the repositories used by Nexus. This is also a great way to start evaluating Nexus. Download and install Nexus on your local workstation and point your Maven settings at http://localhost:8081/nexus. When you need to add a new repository, all you need to do is change the conguration of your local Nexus installation.
Ed. 3.0.2

5 / 241
. . . if you need to integrate with an LDAP server If you need to integrate Nexus with an an LDAP server, download Nexus Open Source. Nexus provides documented integration with popular LDAP servers such as OpenLDAP, Microsofts Active Directory Server, and any other directory product which implements the LDAP standard.
1.4.2
Use Nexus Professional. . .
. . . if you are looking for Professional Support When you purchase Nexus Professional, you are purchasing one year of support from the team that created the industrystandard in repository management. With Nexus Professional, you not only get a capable repository manager, you get the peace of mind that help is just a phone call away. Sonatype also offers an array of implementation and migration services for organizations looking for an extra level of assistance. Contact Sonatype Sales for more information, call +1 (888) 866-2836. . . . if you need a repository manager that can support release and quality assurance decisions:: Nexus Professionals Staging Suite can track the status of a software release and make sure that different decision makers are notied and supported during a software release. If you are looking for a repository manager that can automate and support software releases, download Nexus Professional and start learning about Staged repositories and Staging Rule-sets. When you start using Nexus Professional, your operations, quality assurance, and development teams can use the repository manager as a central point of collaboration. . . . if you need more control over external artifacts If you need more control over which external artifacts can be referenced and used in internal projects, you will need to use the Nexus Procurement Suite which is a part of Nexus Professional. While repositories like Maven Central are a great convenience, allowing your developers carte blanche access to any external library is often unacceptable in todays legal and regulatory environment. Nexus Professionals Procurement Suite allows you to enforce standards for external libraries. If you want to ensure that every dependency is evaluated for security or license compliance, download Nexus Professional. . . . if you develop software for an Open Source project Are you developing an open source project? If so, most open source projects qualify for a free Nexus Professional license. Open source projects can qualify for a free Professional license, or they can take advantage of free Nexus Professional hosting on http://oss.sonatype.org. Sonatype is very committed to supporting the development of quality open source and this is our way of giving back to the community. . . . if you are developing and deploying to OSGi platforms If you are developing OSGi components using OBR repositories, or if you are developing OSGi components using the P2 repository format, you will need to use the OSGi support available in the Nexus Professional distribution. Nexus Professional supports a wider array of repository formats than Nexus Open Source. As the industry moves toward OSGi as a standard, you should be using a product which supports these emerging standards as well as the existing repository formats used by millions of developers. . . . if you need to integrate with Enterprise-level Security (LDAP and Crowd):: If you need to integrate Nexus with an Atlassian Crowd server or an enterprise LDAP deployment involving multiple servers or multiple LDAP schemas, download Nexus Professional. While Nexus Open Source provides extension points for writing custom security realms, Nexus Professional provides solid LDAP and Crowd support for the large, mission-critical LDAP deployments. If you need to support LDAP fail-over and federation, use Nexus Professional.
1.4.3
Comparing Nexus Open Source and Nexus Professional Features
The following table summarizes the differences between Nexus Open Source and Nexus Professional:
Ed. 3.0.2

6 / 241
1.5
History of Nexus
Proximity in December 2005 as he was trying to nd a way to isolate his own systems from an incredibly slow ADSL connection provided by a Hungarian ISP. Proximity started as a simple web application to proxy artifacts for a small organization with connectivity issues. Creating a local on-demand cache for Maven artifacts from the Maven Central repository gave an organization access to the artifacts on the Maven Central Repository, but it also made sure that these artifacts werent downloaded over a very slow ADSL connection used by a number of developers. In 2007, Sonatype asked Tamas to help create a similar product named Nexus. Nexus is currently considered the logical next step to Proximity. Nexus currently has an active development team, and portions of the indexing code from Nexus are also being used in m2eclipse.
Ed. 3.0.2

7 / 241
Chapter 2
Repository Management
2.1 Repository Management
Repository managers serve two purposes: they act as highly congurable proxies between your organization and the public Maven repositories and they also provide an organization with a deployment destination for its own generated artifacts. Just as Source Code Management (SCM) tools are designed to manage source artifacts, Repository Managers have been designed to manage and track external dependencies and artifacts generated by your build. They are an essential part of any enterprise or open-source software development effort, and they enable greater collaboration between developers and wider distribution of software.
2.1.1
Proxying Public Repositories
Proxying and caching a remote public repository can speed up your builds by reducing redundant downloads over the public Internet. If a developer in your organization needs to download version 2.5 of the Spring Framework and you are using Nexus, the dependencies (and the dependencys dependencies) only need to be downloaded from the remote repository once. With a high-speed connection to the Internet this might seem like a minor concern, but if you are constantly asking your developers to download hundreds of megabytes of third-party dependencies, the real cost savings are going to be the time it takes Maven to check for new versions of dependencies and to download dependencies over the public Internet. Proxying and serving Maven dependencies from a local repository cache can save you hundreds of HTTP requests over the public Internet, and, in very large multi-module projects, this can shave minutes from a build.
2.1.2
Managing Releases and Snapshots
If your project is relying on a number of SNAPSHOT dependencies, Maven will need to regularly check for updated versions of these snapshots. Depending on the conguration of your remote repositories, Maven will check for SNAPSHOT updates periodically, or it might be checking for SNAPSHOT updates on every build. When Maven checks for a snapshot update it needs to interrogate the remote repository for the latest version of the SNAPSHOT dependency. Depending on your connection to the public Internet and the load on the Maven Central repository, a SNAPSHOT update can add seconds to your projects build for each SNAPSHOT dependency you rely upon. When you host a local repository proxy with Nexus, you reduce the amount of time it takes for Maven to check for a newer version as your build interacts with a local repository cache. If you develop software with SNAPSHOT dependencies, using a local repository manager will save you a considerable amount of time, your 5-10 second SNAPSHOT update checks against the public central repository are going to execute in hundreds of milliseconds (or less) when they are executed against a local resource.
Ed. 3.0.2

8 / 241
2.1.3
Getting Control of Dependencies
In addition to the simple savings in time and bandwidth, a repository manager provides an organization with control over what is downloaded by Maven. You can include or exclude specic artifacts from the public repository, and having this level of control over what is downloaded from the Maven Central repository is a prerequisite for many organizations which have a need for strict standards for the quality and security of the dependencies used in an enterprise system. If you want to standardize on a specic version of a dependency like Hibernate or Spring you can enforce this standardization by only providing access to a specic version of an artifact in Nexus. You might be concerned with making sure that every external dependency has a license compatible with your legal standards for adopting and integrating open source libraries. If you are producing an application which is distributed, you might want to make sure that no one inadvertently adds a dependency on a third-party library covered under a copy-left license like the GPL. All of this is possible with Nexus. Repository managers are a central point of access to external binary software artifacts and dependencies your system relies upon. Nexus provides a level of control that is essential when you are trying to track and manage the libraries and frameworks your software depends upon.
2.1.4
A Nexus for Collaboration
Aside from the benets of mediating access to remote repositories, a repository manager also provides an important platform for collaborative software development. Unless you expect every member of your organization to download and build every single internal project from source, you will want to provide a mechanism for developers and departments to share binary artifacts (both SNAPSHOTs and releases) for internal software projects. Internal groups often consume the APIs and systems which are generated by other internal groups, when you adopt Nexus as a deployment platform for internal artifacts, you can easily share components and libraries between groups of developers. Nexus provides you with a deployment target for your software components. Once you install Nexus, you can start using Maven to deploy snapshots and releases to internal repositories which can then be combined with other repositories in repository groups. Over time, this central deployment point for internal projects becomes the fabric for collaboration between different development teams and operations. Nexus is the secret ingredient that allows an organization to scale its development effort without sacricing agility.
2.2
What is a Repository?
Maven developers are familiar with the concept of a repository: a collection of binary software artifacts and metadata stored in a dened directory structure which is used by clients such as Apache Ivy to retrieve binaries during a build process. In the case of the Maven repository, the primary type of binary artifact is a JAR le containing Java bytecode, but there is no limit to what type of artifact can be stored in a Maven repository. For example, one could just as easily deploy documentation archives, source archives, Flash libraries and applications, or Ruby libraries to a Maven repository. A Maven repository provides a platform for the storage, retrieval, and management of binary software artifacts and metadata. In Maven, every software artifact is described by an XML document called a Project Object Model (POM). This POM contains information that describes a project and lists a projects dependencies - the binary software artifacts which a given component depends upon for successful compilation or execution. When Maven downloads a dependency from a repository, it also downloads that dependencys POM. Given a dependencys POM, Maven can then download any other libraries which are required by that dependency. The ability to automatically calculate a projects dependencies and transitive dependencies is made possible by the standard and structure set by the Maven repository. Maven and other tools such as Ivy which interact with a repository to search for binary software artifacts, model the projects they manage, and retrieve software artifacts on-demand from a repository. When you download and install Maven without any customization, Maven will retrieve artifacts from a Maven Central repository which serves millions of Maven users every single day. While you can congure Maven to retrieve binary software artifacts from a collection of mirrors, the best-practice is to install Nexus and use it to proxy and cache the contents of Central on your own network. In addition to Central, there are a number of major organizations such as Redhat, Sun Microsystems, and Codehaus which maintain separate repositories.
Ed. 3.0.2

9 / 241
While this might seem like a simple, obvious mechanism for distributing artifacts, the Java platform existed for several years before the Maven project created a formal attempt at the rst repository for Java artifacts. Until the advent of the Maven repository in 2002, a projects dependencies were gathered in a manual, ad-hoc process and were often distributed with a projects source code. As applications grew more and more complex, and as software teams developed a need for more complex dependency management capabilities for larger enterprise applications, Mavens ability to automatically retrieve dependencies and model dependencies between components became an essential part of software development.
2.2.1
Release and Snapshot Repositories
A repository stores two types of artifacts: releases and snapshots. Release repositories are for stable, static release artifacts and snapshot repositories are frequently updated repositories that store binary software artifacts from projects under constant development. While it is possible to create a repository which serves both release and snapshot artifacts, repositories are usually segmented into release or snapshot repositories serving different consumers and maintaining different standards and procedures for deploying artifacts. Much like the difference between a production network and a staging network, a release repository is considered a production network and a snapshot repository is more like a development or a testing network. While there is a higher level of procedure and ceremony associated with deploying to a release repository, snapshot artifacts can be deployed and changed frequently without regard for stability and repeatability concerns. The two types of artifacts managed by a repository manager are: Release A release artifact is an artifact which was created by a specic, versioned release. For example, consider the 1.2.0 release of the commons-lang library stored in the Maven Central repository. This release artifact, commons-lang-1.2.0.jar, and the associated POM, commons-lang-1.2.0.pom, are static objects which will never change in the Maven Central repository. Released artifacts are considered to be solid, stable, and perpetual in order to guarantee that builds which depend upon them are repeatable over time. The released JAR artifact is associated with a PGP signature, an MD5 and SHA checksum which can be used to verify both the authenticity and integrity of the binary software artifact. Snapshot Snapshot artifacts are artifacts generated during the development of a software project. A Snapshot artifact has both a version number such as "1.3.0" or "1.3" and a timestamp in its name. For example, a snapshot artifact for commonslang 1.3.0 might have the name commons-lang-1.3.0-20090314.182342-1.jar the associated POM, MD5 and SHA hashes would also have a similar name. To facilitate collaboration during the development of software components, Maven and other clients which know how to consume snapshot artifacts from a repository also know how to interrogate the metadata associated with a Snapshot artifact to retrieve the latest version of a Snapshot dependency from a repository. A project under active development produces SNAPSHOT artifacts that change over time. A release is comprised of artifacts which will remain unchanged over time.
2.2.2
Repository Coordinates
Repositories and tools like Maven know about a set of coordinates including the following components: groupId, artifactId, version, and packaging. This set of coordinates is often referred to as a GAV coordinate which is short for "Group, Artifact, Version coordinate". The GAV coordinate standard is the foundation for Mavens ability to manage dependencies. Four elements of this coordinate system are described below: groupId A group identier groups a set of artifacts into a logical group. Groups are often designed to reect the organization under which a particular software component is being produced. For example, software components being produced by the Maven project at the Apache Software Foundation are available under the groupId org.apache.maven. artifactId An artifact is an identier for a software component. An artifact can represent an application or a library; for example, if you were creating a simple web application your project might have the artifactId "simple-webapp", and if you were creating a simple library, your artifact might be "simple-library". The combination of groupId and artifactId must be unique for a project.
Ed. 3.0.2

10 / 241
version The version of a project follows the established convention of Major, Minor, and Point release versions. For example, if your simple-library artifact has a Major release version of 1, a minor release version of 2, and point release version of 3, your version would be 1.2.3. Versions can also have alphanumeric qualiers which are often used to denote release status. An example of such a qualier would be a version like "1.2.3-BETA" where BETA signals a stage of testing meaningful to consumers of a software component. packaging Maven was initially created to handle JAR les, but a Maven repository is completely agnostic about the type of artifact it is managing. Packaging can be anything that describes any binary software format including ZIP, SWC, SWF, NAR, WAR, EAR, SAR.
2.2.3
Addressing Resources in a Repository
Tools designed to interact Maven repositories translate artifact coordinates into a URL which corresponds to a location in a Maven repository. If a tool such as Maven is looking for version 1.2.0 of the commons-lang JAR in the group org.apache.commons, this request is translated into:
<repoURL>/org/apache/commons/commons-lang/1.2.0/commons-lang-1.2.0.jar
Maven would also download the corresponding POM for commons-lang 1.2.0 from:
<repoURL>/org/apache/commons/commons-lang/1.2.0/commons-lang-1.2.0.pom
This POM may contain references to other dependencies which would then be retrieved from the same repository using the same URL patterns.
2.2.4
The Maven Central Repository
The most useful Maven repository is the Maven Central Repository. The Maven Central repository contains almost 90,000 software artifacts occupying around 70 GB of disk space. You can look at Central as an example of how Maven repositories operate and how they are assembled. Here are some of the properties of release repositories such as the Maven Central repository: Artifact Metadata All software artifacts added to Central require proper metadata including a Project Object Model (POM) for each artifact which describes the artifact itself, and any dependencies that software artifact might have. Release Stability Once published to the Maven Central repository, an artifact and the metadata describing that artifact never change. This property of release repositories guarantees that projects which depend on releases will be repeatable and stable over time. While new software artifacts are being published to central every day, once an artifact is assigned a release number on Central, there is a strict policy against modifying the contents of a software artifact after a release. Repository Mirrors Central is a public resource, and it is currently used by the millions of developers who have adopted Maven and the tools that understand how to interact with the Maven repository structure. There are a series of mirrors for the Central repository which are constantly synchronized with Central. Users are encouraged to query central for project metadata and cryptographic hashes and they are encouraged to retrieve the actual software artifacts from one of Centrals many mirrors. Tools like Nexus are designed to retrieve metadata from Central and artifact binaries from mirrors. Artifact Security The Maven Central repository contains cryptographic hash cryptographic hashes and PGP signatures which can be used to verify the authenticity and integrity of software artifacts served from Central or one of the many mirrors of Central.
Ed. 3.0.2

11 / 241
2.3
What is a Repository Manager
If you use Maven, you are using a repository to retrieve artifacts and Maven plugins. In fact, Maven used a Maven repository to retrieve core plugins that implement the bulk of the features used in your builds. Once you start to rely on repositories, you realize how easy it is to add a dependency on an open source software library available in the Maven Central repository, and you might start to wonder how you can provide a similar level of convenience for your own developers. When you install a repository manager, you are bringing the power of a repository like Central into your organization, you can use it to proxy Central, and host your own repositories for internal and external use. In this section, we discuss the core functionality which denes what a repository manager does. Put simply, a repository manager provides two core features: The ability to proxy a remote repository and cache artifacts saving both bandwidth and time required to retrieve a software artifact from a remote repository, and The ability the host a repository providing an organization with a deployment target for software artifacts. In addition to these two core features, a repository manager also allows you to manage binary software artifacts through the software development lifecycle, search and catalog software artifacts, audit development and release transactions, and integrate with external security systems such as LDAP. The following sections dene the feature sets of Nexus Open Source and Nexus Professional.
2.3.1
Core Capabilities of a Repository Manager
The base-line features of a repository manager are a description of the core capabilities of Nexus Open Source. Nexus Open Source provides for the: Management of Software Artifacts A repository manager is able to manage packaged binary software artifacts. In Java development, this would include JARs containing bytecode, source, or javadoc. In other environments, such as Flex, this would include any SWCs or SWFs generated by a Flex build. Management of Software Metadata A repository manager should have some knowledge of the metadata which describes artifacts. In a Maven repository this would include project coordinates (groupId, artifactId, version, classier) and information about a given artifacts releases. Proxying of External Repositories Proxying an external repository yields more stable builds as the artifacts used in a build can be served to clients from the repository managers cache even if the external repository becomes unavailable. Proxying also saves bandwidth and time as checking for the presence of an artifact on a local network is often orders of magnitude faster than querying a heavily loaded public repository Deployment to Hosted Repositories Organizations which deploy internal snapshots and releases to hosted repositories have an easier time distributing software artifacts across different teams and departments. When a department or development group deploys artifacts to a hosted repository, other departments and development groups can develop systems in parallel, relying upon dependencies served from both release and snapshot repositories. Searching an Index of Artifacts When you collect software artifacts and metadata in a repository manager, you gain the ability to create indexes and allow users and systems to search for artifacts. With the Nexus index, an IDE such as Eclipse has almost instantaneous access to the contents of all proxy repositories (including the Central repository) as well as access to your own internal and 3rd party artifacts. While the Central repository transformed the way that software is distributed, the Nexus index format brings the power of search to massive libraries of software artifacts. Infrastructure for Artifact Management A repository manager should also provide the appropriate infrastructure for managing software artifacts and a solid API for extension. In Nexus, Sonatype has provided a plugin API which allows developers to customize both the behavior, appearance, and functionality of the tool.
Ed. 3.0.2

12 / 241
2.3.2
Additional Features of a Repository Manager
Once you adopt the core features of a repository manager, you start to view a repository manager as a tool which enables more efcient collaboration between development groups. Nexus Professional builds upon the foundations of a repository manager and adds capabilities such as Procurement and Staging. Managing Project Dependencies Many organizations require some level of oversight over the open source libraries and external artifacts that are let into an organizations development cycle. An organization could have specic legal or regulatory constraints which requires every dependency to be subjected to a rigorous legal or security audit before it is integrated into a development environment. Another organization might have an architecture group which needs to make sure that a large set of developers only has access to a well-dened list of dependencies or specic versions of dependencies. Using the Procurement features of Nexus Professional, managers and architecture groups have the ability to allow and deny specic artifacts from external repositories. Managing a Software Release Nexus Professional adds some essential workow to the process of staging software to a release repository. Using Nexus Professional, developers can deploy to a staging directory which can trigger a message to a Release Manager or to someone responsible for QA. Quality assurance (or a development manager) can then test and certify a release having the option to promote a release to the release repository or to discard a release if it didnt meet release standards. Nexus Professionals staging features allow managers to specify which personnel are allowed to certify that a release can be promoted to a release repository giving an organization more control over what software artifacts are released and who can release them. Integration with LDAP Nexus integrates with an LDAP directory, allowing an organization to connect Nexus to an existing directory of users and groups. Nexus authenticates users against an LDAP server and provides several mechanisms for mapping existing LDAP groups to Nexus roles. Advanced Security Using Nexus Professional, an organization can dene a master User Password Encryption Key. Each user will be given a separate Maven settings le with an encrypted password using the Maven Nexus plugin. When users interact with Nexus, Nexus uses the User Password Encryption Key to decrypt a users Nexus credentials avoiding the need to send an easily compromised plain-text password over the network. Settings Templates Nexus Professional allows you to dene Maven settings templates for developers. Developers can then automatically receive updates to Maven settings (~/.m2/settings.xml) using the Maven Nexus plugin. The ability to dene Maven settings templates and to distribute customized Maven settings les to developers makes it easy for an organization to change global proles or repository conguration without relying on developers to manually install a new settings le in a development environment. Support for Multiple Repository Formats Nexus Professional supports the p2 and the OSGi Bundle repository format used by the new Eclipse provisioning platform and OSGi developers. You can use the p2 plugin to consolidate, provision, and control the plugins that are being used in an Eclipse IDE. Using Nexus procurement, repository groups, and proxy repositories to consolidate multiple plugin repositories, an organization can use Nexus Professional to standardize the conguration of Eclipse IDE development environments.
2.4
Reasons to Use a Repository Manager
Here are a few reasons why using a repository manager is an imperative. While most people wouldnt even think of developing software without the use of a source code control system like Subversion or Perforce, the concept of using a repository manager is still something that needs development. There are many who use Maven for years without realizing the benets of using a repository manager. This section was written as an attempt to capture some of the benets of using a repository manager.
Ed. 3.0.2

13 / 241
2.4.1
Speed Up Your Builds
When you run your multi-module project in Maven, how do you think Maven knows if it needs to update plugins or snapshot dependencies? It has to make a request for each artifact it needs to test. Even if nothing has changed, if your project depends on a few SNAPSHOTs or if you dont specify plugin version, Maven might have to make tens to hundreds of requests to a remote repository. All of these requests over the public Internet add up to real, wasted, time. Ive seen complex builds cut build time by 75% after installing a local instance of Nexus. You are wasting time better spent coding waiting for your build to needlessly interrogate a remote Maven repository.
2.4.2
Save Bandwidth
The larger the organization, the more critical bandwidth savings can be. If you have thousands of developers regularly wasting good bandwidth to download the same les over and over again, using a repository manager to keep a local cache is going to save you a good deal of bandwidth. Even for smaller organizations with limited budgets for connectivity and IT operations, having to deal with a set of developers maxing out your connection to the Internet to download the same things over and over again seems backwards.
2.4.3
Ease the Burden on Central
Running the Maven Central repository is no short order. It aint cheap to serve the millions of requests and Terabytes of data required to satisfy the global demand for software artifacts from the Maven Central repository. Something as simple as installing a repository manager at every organization that uses Maven would likely cut the bandwidth requirements for Central by at least half. If you have more than a couple developers using Maven, install a repository manager for the sake of keeping Central available and in business.
2.4.4
Gain Predictability and Scalability
How often in the past few years has your business come to a crashing halt because of an outage? Depending on Central for your day to day operations also means that you depend on having Internet connectivity (and on the fact the Central will remain available 24/7). While Sonatype is condent in its ability to keep Central running 24/7, you should take some steps of your own to make sure that your development team isnt going to be surprised by some network outage on either end. If you have a local repository manager, like Nexus, you can be sure that your builds will continue to work even if you lose connectivity.
2.4.5
Control and Audit Dependencies and Releases
So, youve moved over to Maven (or maybe Ivy, Ivy reads the same repository), and you now have a whole room full of developers who feel empowered to add or remove dependencies and experiment with new frameworks. Weve all seen this. Weve all worked in places with a developer who might be more interested in experimenting than in working. It is unfortunate to say so, but there are often times when an architect, or an architecture group needs to establish some baseline standards which are going to be used in an organization. Nexus provides this level of control. If you need more oversight over the artifacts that are making it into your organization, take a look at Nexus. Without a repository manager, you are going to have little control over what dependencies are going to be used by your development team.
2.4.6
Deploy 3rd Party Artifacts
How do you deal with that one-off JAR from a vendor that is not open source, and not available on the Maven Central repository? You need to deploy these artifacts to a repository and congure your Maven instance to read from that repository. Instead of hand-crafting some POMs, download Nexus and take the two or three minutes it is going to take to get your hands on a tool that can create such a repository from 3rd-party artifacts. Nexus provides an intuitive upload form that you can use to upload any random free-oating JAR that nds its way into your projects dependencies.
Ed. 3.0.2

14 / 241
2.4.7
Collaborate with Internal Repositories
Many organizations require every developer to checkout and build the entire system from source simply because they have no good way of sharing internal JARs from a build. You can solve a problem like this by splitting projects up and using Nexus as an internal repository to host internal dependencies. For example, consider a company that has 30 developers split into three groups of 10, each group focused on a different part of the system. Without an easy way to share internal dependencies, a group like this is forced either to create an ad hoc lesystem-based repository or to build the system in its entirety so that dependencies are installed in every developers local repository. The alternative is to separate the projects into different modules that all have dependencies on artifacts hosted by an internal Nexus repository. Once youve done this, groups can collaborate by exchanging compiled snapshot and release artifacts via Nexus. In other words, you dont need to ask every developer to checkout a massive multi-module project that includes the entire organizations code. Each group within the organization can deploy snapshots and artifacts to a local Nexus instance, and each group can maintain a project structure which includes only the projects it is responsible for.
2.4.8
Distribute with Public Repositories
If you are an open source project, or if you release software to the public, Nexus can be the tool you use to serve artifacts to external users. Think about it this way. . . When was the last time you cut a release for your software project? Assuming it wasnt deployed to a Maven repository, you likely had to write some scripts to package the contents of the release, maybe someone special had to sign the release with a super-secret cryptographic key. Then, you had to upload it to some web server, and then make sure that the pages that describe the upload were themselves updated. Lots of needless complexity. . . If you were using something like Nexus, which can be congured to expose a hosted repository to the outside world, you could use the packaging and assembly capabilities of Maven and the structure of the Maven repository to make a release that is more easily consumed. And, this isnt just for JAR les and Java web applications; Maven repositories can host any kind of artifact. Nexus, and Maven repositories in general, dene a known structure for releases. If you are writing some Java library, publishing it to your own Nexus instance serving a public repository will make it easier for people to start using your code right away.
2.5
Adopting a Repository Manager
This section talks about the stages of moving to a repository manager. Adopting a repository manager is not an all or nothing proposition, and there are various levels (or stages) of adoption that can be distinguished when approaching repository management. On one end of the adoption spectrum is the organization that installs a repository manager just to control and consolidate access to a set of remote repositories. On the other end of the spectrum is the organization which has integrated the repository manager into an efcient software development lifecycle, using it to facilitate decision points in the lifecycle, encouraging more efcient collaboration throughout the enterprise, and keeping detailed records to increase visibility into the software development process.
2.5.1
Stage Zero: Before Using a Repository Manager
While this isnt a stage of adoption, Stage Zero is a description of the way software builds work in the absence of a repository manager. When a developer decides that a he needs a particular open source software component, he will download it from the components web site, read the documentation, and nd the additional software that his components rely on (referred to as "dependencies"). Once he has manually assembled a collection of dependencies from various open source project web sites and proprietary vendors, he will place all these components somewhere on the network so that he, his team members, the build script, the QA team, and the production support team can nd it. At any time, other developers may bring in other components, sometimes with overlapping dependencies, placing them in different network locations. The instructions to bring all of these ad-hoc, developer-managed components libraries together in a software build process can become very complicated and hard to maintain. Maven was introduced to improve this build process by introducing the concept of structured repositories from which the build scripts can retrieve the software components. In Maven language, these software components or dependencies are referred to as "artifacts", a term which can refer to any generic software artifact including components, libraries, frameworks, containers, etc.
Ed. 3.0.2

15 / 241
Maven can identify artifacts in repositories, understand their dependencies, retrieve all that are needed for a successful build, and deploy its output back to repositories when done. Developers using Maven without a repository manager nd most of their software artifacts and dependencies in Maven Central. If they happen to use another remote repository or if they need to add a custom artifact, the solution, in Stage Zero, is to manually manipulate the les in a local repository and share this local repository with multiple developers. While this approach may yield a working build for a small team, managing a shared local repository doesnt allow an organization to scale a development effort. There is no inherent control over who can set up a local repository, who can add to them or change or delete from them, nor are there tools to protect the integrity of these repositories. That is, until Repository Managers were introduced.
2.5.2
Stage One: Proxying Remote Repositories
This is the easiest stage to understand both in terms of benets to an organization and action required to complete this stage. All you need to do to start proxying a remote repository is to deploy Nexus and start the server with the default conguration. Congure your Maven clients to read from the Nexus public repository group, and Nexus will automatically retrieve artifacts from remote repositories, such as Maven Central, caching them locally. Without a repository manager, your organization might have hundreds of developers independently downloading the same artifacts from public, remote repositories. With a repository manager, these artifacts can be downloaded once and stored locally. After Stage One, your builds run considerably faster than they did when you relied upon the Maven Central repository. Once youve installed Nexus and youve congured all of your organizations clients to use it as a single point of access to remote repositories, you begin to realize that it now provides you with a central conguration point for the artifacts used throughout your organization. Once youve started to proxy, you can start to think about using Nexus as a tool to control policy and what dependencies are allowed to be used in your organization. Nexus Professional provides a procurement plugin which allows for ne-grained control over which artifacts can be accessed from a remote repository. This procurement feature is described in more detail in the section which deals with Lifecycle Integration.
2.5.3
Stage Two: Hosting a Repository Manager
Once you have started to proxy remote repositories and you are using Nexus as a single, consolidated access point for remote repositories, you can start to deploy your own artifacts to Nexus hosted repositories. Most people approach repository management to nd a solution for proxying remote repositories, and while proxying is the most obvious and immediate benet of installing a repository manager, hosting internally generated artifacts tends to be the stage that has the most impact on collaboration within an organization. To understand the benets of hosting an internal repository, you have to understand the concept of managing binary software artifacts. Software development teams are very familiar with the idea of a source code repository or a source code management tool. Versioning control systems such as Subversion, Clearcase, Git, and CVS provide solid tools for managing the various source artifacts that comprise a complex enterprise application, and developers are comfortable checking source out from source control to build enterprise applications. However, past a certain point in the software development lifecycle, source artifacts are no longer relevant. A QA department trying to test an application or an Operations team attempting to deploy an application to a production network no longer needs access to the source artifacts. QA and Operations are more interested in the compiled end-product of the software development lifecycle: the binary software artifacts. A repository manager allows you to version, store, search, archive, and release binary software artifacts derived from the source artifacts stored in a source control system. A repository manager allows you to apply the same systematic operations on binary software artifacts which you currently apply to your source code. When your build system starts to deploy artifacts to an internal repository, it changes the way that developers and development groups can interact with one another in an enterprise. Developers in one development group can code and release a stable version of an internal library, deploy this library to an internal Nexus release repository, and so share this binary artifact with another group or department. Without a repository manager managing internal artifacts, you have ad-hoc solutions and the organizational equivalent of "duct tape". How does the infrastructure group send a new library to the applications group without Nexus? Someone copies a le to a shared directory, and sends an email to the team lead. Organizations without repository managers are full of these ad-hoc processes that get in the way of efcient development and deployment.
Ed. 3.0.2

16 / 241
With a repository manager, every developer and every development group within the enterprise understands and interacts with a common collaborative structure: the repository manager. Do you need to interact with the Commerce teams new API? Just add a dependency to your project and Maven will retrieve the library from Nexus automatically. One of the other direct benets of deploying your own artifacts to a repository such as Nexus is the ability to quickly search the metadata and contents of those artifacts both via a web UI and through IDE integration tools such as m2eclipse. When you start to deploy internal artifacts you can synchronize all development groups to a common version and naming standard, and you can use the highly congurable authentication and role-based access controls to control which developers and which development groups can deploy artifacts to specic repositories or paths within a repository.
2.5.4
Stage Three: Continuous Collaboration
Developing this collaborative model further, if your application is being continuously built and deployed using a tool like Hudson, a developer can checkout a specic module from a large multi-module build and not have to constantly deal with the entire source tree at any given time. This allows a software development effort to scale efciently. If every developer working on a complex enterprise application needs to checkout the entire source tree every time he or she needs to make a simple change to a small component, you are quickly going to nd that building the entire application becomes a burdensome bottleneck to progress. The larger your enterprise grows, the more complex your application becomes, the larger the collective burden of wasted time and missed opportunities. A slow enterprise build prevents the quick turnaround or quick feedback loop that helps your developers maintain focus during a development cycle. Once you are building with Maven, sharing binary artifacts with Nexus, continuously testing and deploying with Hudson, and generating reports and metrics with tools like Sonar, your entire organization gains a collaborative "central nervous system" that enables a more agile approach to software development.
2.5.5
Stage Four: Lifecycle Integration
Once youve congured a repository manager to proxy remote repositories and you are using a repository manager as an integration point between developers and departments, you start to think about the various ways your repository manager can be used to support the decisions that go into software development. You can start using the repository manager to stage releases and supporting the workow associated with a managed release, and you can use the procurement features of a tool like Nexus Professional to give management more visibility into the origins, characteristics and open source licenses of the artifacts used during the creation of an enterprise application. Nexus Professional enables organizations to integrate the management of software artifacts tightly with the software development lifecycle: Provisioning, Compliance, Procurement, Enterprise Security, Staging and other capabilities that support the workow that surrounds a modern software development effort. Using Nexus Professionals Maven Settings management feature and integrated security features you can congure a developers Maven settings by running a single, convenient Maven goal and downloading customized settings for a particular developer. When you use Maven and Nexus Professional together, developers can get up and running quickly, collaborating on projects that share common conventions without having to manually install dependencies in local repositories. Provisioning Using Nexus as an integration point between Engineering and Operations means that Engineering can be responsible for delivering solid, tested artifacts to Quality Assurance and Operations via a standard repository format. Often development teams are roped into the production deployment story and become responsible for building entire production environments within a build system. This conates software engineering with system administration and blurs the line between Engineering and Operations. If you use Nexus as a end-point for releases from Engineering, Operations can then retrieve, assemble, and congure an application from tested components in the Nexus repository. Compliance Procurement, staging, and audit logs are all features which increase the visibility into who and what is involved with your software development effort. Using Nexus Professional, Engineering can create the reports and documents which can be used to facilitate discussions about oversight. Organizations subject to various regulations often need to produce a list of components involved in a software release. Legal departments often require a list of open source licenses being used in a particular software component, and managers often lack critical visibility into the software development process.
Ed. 3.0.2

17 / 241
Procurement The ease with which todays developer can add a dependency on a new open source library and download this library from a Central repository has a downside. Organizations large and small are constantly wondering what open source libraries are being used in applications, and whether these libraries have acceptable open source licenses for distribution. The Procurement features of Nexus Professional give architects and management more oversight over the artifacts which are allowed into an organization. Using the Procurement features, a Nexus administrator or Procurement manager can allow or deny specic artifacts by group, version, or path. You can use the procurement manager as a rewall between your own organizations development environment and the 95,000 artifacts available on the Maven Central repository. Enterprise Security Nexus LDAP integration allows an enterprise to map existing LDAP groups to Nexus roles and provides Nexus administrators with a highly congurable interface to control which individuals or groups have access to a ne-grained set of Nexus permissions. Staging Nexus Professional adds an important step to the software release workow, adding the concept of a managed (or staged) release to a hosted repository. When a developer needs to perform a production release, Nexus Professional can isolate the artifacts involved in a release in a staged repository which can then be certied and tested. A manager or a quality assurance tester can then promote or discard a release. The staging feature allows you to specify the individuals that are allowed to promote a release and keeps an audit of who was responsible for testing, promoting, or discarding a software release.
Ed. 3.0.2

18 / 241
Chapter 3
Installing and Running Nexus

3.1 Downloading Nexus
There are two distributions of Nexus: Nexus Open Source and Nexus Professional. Nexus Open Source is a fully-featured repository manager which can be freely used, customized, and distributed under the GNU Affero General Public License (AGPL) Version 3. Nexus Professional is a distribution of Nexus with features that are relevant to large enterprises and organizations which require complex procurement and staging work-ows in addition to more advanced LDAP integration, Atlassian Crowd support, and other development infrastructure. The differences between Nexus Open Source and Nexus Professional are explored in the previous chapter.
3.1.1
Downloading Nexus Open Source
Download Nexus Open Source from http://nexus.sonatype.org/download-nexus.html then download the appropriate Nexus Open Source distribution by clicking on the appropriate archive as shown in Figure 3.2. Nexus Open Source is available as a ZIP and a Gzipd TAR le under the le names nexus-oss-webapp-1.9.2-bundle.zip and nexus-oss-webapp-1.9.2-bundle.tgz
Figure 3.1: Downloading Nexus Open Source from nexus.sonatype.org
Ed. 3.0.2

19 / 241
Figure 3.2: Selecting the Nexus Open Source Distribution Download Nexus Open Source can also be deployed as a web application in a servlet container like Jetty or Tomcat or an application server like Glasssh or JBoss. Instructions for installing Nexus as a WAR are found in Section 3.8.
3.1.2
Downloading Nexus Professional
To download Nexus Professional, go to the Nexus Trial evaluation form. Fill out the form and then check your email account for download instructions. After lling out a brief contact form and agreeing to the evaluation license, you will be sent an email with a link to download the Nexus Professional distribution. Nexus is available as a ZIP le under the le names nexus-professional-webapp-1.9.2-bundle.zip and nexus-professional-webapp-1.9.2-bundle.tgz
3.2
Installing Nexus
The following sections detail the installation process for both Nexus Open Source and Nexus Professional.
3.2.1
Nexus Prerequisites
Nexus Open Source and Nexus Professional only have one prerequisite, a Java Runtime Environment (JRE) compatible with Java 5 or higher. Nexus is most often run with the JRE that is bundled with a Java Development Kit (JDK) installation, and it can be run with the latest version of Suns JDK for Java 5 or Java 6. To download the latest release of the Sun JDK, go to http://developers.sun.com/downloads/, and download the latest Java 6 JDK or an older Java 5 JDK, either will work but Java 6 is recommended.
3.2.2
Installing Nexus Open Source
The following instructions are for installing Nexus Open Source as a stand-alone server. Nexus comes bundled with a Jetty instance which listens to all congured IP addresses on a host (0.0.0.0) and runs on port 8081 by default. If you would like to run Nexus Open Source as a web application in an existing application server or servlet container, please refer to the instructions in Section 3.8.
Ed. 3.0.2

20 / 241
Installing Nexus Open Source is straightforward. Unpack the Nexus web application archive in a directory. If you are installing Nexus on a local workstation to give it a test run, you can install it in your home directory or wherever you like; Nexus doesnt have any hard coded directories, it will run from any directory. If you downloaded the ZIP
$ unzip nexus-oss-webapp-1.9.2-bundle.zip
And, if you download the GZipd TAR archive, run:

$ tar xvzf nexus-oss-webapp-1.9.2-bundle.tgz
Note There are some known incompatibilities with the version of tar provided by Solaris and the gzip tar format. If you are installing Nexus on Solaris, you must use the GNU tar application, or you will end up with corrupted les.
Note If you are installing Nexus on a server, you might want to use a directory other than your home directory. On a Unix machine, this book assumes that Nexus is installed in /usr/local/nexus-oss-webapp-1.9.2 with a symbolic link /usr/local/nexus to the nexus directory. Using a generic symbolic link nexus to a specic version is a common practice which makes it easier to upgrade when a newer version of Nexus is made available.
$ $ $ $
sudo cp nexus-oss-webapp-1.9.2-bundle.tgz /usr/local cd /usr/local sudo tar xvzf nexus-oss-webapp-1.9.2-bundle.tgz ln -s nexus-oss-webapp-1.9.2 nexus
Although it isnt required for Nexus to run, you may want to set an environment variable NEXUS_HOME in your environment which points to the installation directory of Nexus. This chapter will refer to this location as $NEXUS_HOME The Nexus installation directory nexus-oss-webapp-1.9.2 has a sibling directory named sonatype-work. This directory contains all of the repository and conguration data for Nexus and is stored outside of the Nexus installation directory to make it easier to upgrade to a newer version of Nexus. By default, this directory is always a sibling to the nexus installation directory; if you installed nexus in /usr/local directory would also contain a sonatype-work subdirectory containing all of the content and conguration. The location of the sonatype-work directory can be customized by altering the nexus-work property in $NEXUS_HOME/conf/plexus.properties
3.2.3
Installing Nexus Professional
The following instructions are for installing Nexus Professional as a stand-alone server. Nexus Professional is bundled with a Jetty instance which listens to all congured IP addresses on a host (0.0.0.0) and runs on port 8081 by default. Installing Nexus is straightforward, unpack the Nexus web application archive in a directory. If you are installing Nexus on a local workstation to give it a test run, you can install it in your home directory or wherever you like; Nexus doesnt have any hard coded directories, it will run from any directory. If you downloaded the ZIP
$ unzip nexus-professional-webapp-1.9.2-bundle.zip
And, if you download the GZipd TAR archive, run:

$ tar xvzf nexus-professional-webapp-1.9.2-bundle.tgz
If you are installing Nexus on a server, you might want to use a directory other than your home directory. On a Unix machine, this book assumes that Nexus is installed in /usr/local/nexus-professional-webapp-1.9.2 with a symbolic link /usr/local/nexus to the nexus directory. Using a symbolic link nexus to a directory which holds a specic version of Nexus is a common practice that makes it easier to upgrade to a newer version of Nexus.
Ed. 3.0.2

21 / 241
$ $ $ $
sudo cp nexus-professional-webapp-1.9.2-bundle.tgz /usr/local cd /usr/local sudo tar xvzf nexus-professional-webapp-1.9.2-bundle.tgz ln -s nexus-professional-webapp-1.9.2 nexus
Although it isnt required for Nexus to run, you may want to set an environment variable NEXUS_HOME in your environment which points to the installation directory of Nexus. This chapter will refer to this location as $NEXUS_HOME. The Nexus installation directory nexus-professional-webapp-1.9.2 has a sibling directory named sonatype-work. This directory contains all of the repository and conguration data for Nexus and is stored outside of the Nexus installation directory to make it easier to upgrade to a newer version of Nexus.
3.3
Upgrading Nexus
Since Nexus separates its conguration and data storage from the application, it is easy to upgrade an existing Nexus installation. To upgrade Nexus, unpack the Nexus archive in the directory which contains the existing Nexus installation. Once the archive is unpacked, the new Nexus application directory should be a sibling to your existing sonatype-work/ directory. If you have dened a symbolic link for the version of Nexus to use, change that to point at the new Nexus application directory. When you start the new instance of Nexus it will read the existing repository conguration from the sonatype-work/
3.4
Running Nexus
When you start Nexus, you are starting a web server on the default port of 0.0.0.0:8081. Nexus runs within a servlet container called Jetty and it is started with a native service wrapper called the Tanuki Java Service Wrapper. This service wrapper can be congured to run Nexus as a Windows service or a Unix daemon. To start Nexus, you will need to nd the appropriate startup script for your platform. To see the list of available platforms, list the contents of the $NEXUS_HOME/bin/jsw The following example listing starts Nexus using the script for Mac OSX. First we list the contents of the $NEXUS_HOME/bin/jsw to show you the available platforms, then we make the contents of the bin directory executable with chmod. The Mac OS X wrapper is started with a call to nexus start, and then we tail the wrapper.log in $NEXUS_HOME/logs. Nexus will initialize itself and print a message stating what IP address and port it is listening on.
$ cd /usr/local/nexus $ ls ./bin/jsw/ conf/ linux-x86-64/ solaris-x86-32/ lib/ macosx-universal-32/ windows-x86-32/ license/ macosx-universal-64/ windows-x86-64/ linux-ppc-64/ solaris-sparc-32/ linux-x86-32/ solaris-sparc-64/ $ chmod -R a+x bin $ ./bin/jsw/macosx-universal-64/nexus start Starting Nexus Repository Manager... Started Nexus Repository Manager. $ tail -f logs/wrapper.log INFO ... [ServletContainer:default] - [email protected]:8081
At this point, Nexus will be running and listening on all IP addresses (0.0.0.0) that are congured for the current host on port 8081. To use Nexus, re up a web browser and type in the URL: http://localhost:8081/nexus While we use "localhost" throughout this book, you may need to use the IP Loopback Address of "127.0.0.1" or the IP address assigned to the machine running Nexus. Click on the "Log In" link in the upper right-hand corner of the web page, and you should see the login dialog. THE DEFAULT NEXUS USERNAME AND PASSWORD IS "admin" AND "admin123".
Ed. 3.0.2

22 / 241
Figure 3.3: Default Nexus Administrative Credentials (admin/admin123)
Figure 3.4: Nexus Application Window (default login/password is admin/admin123)
3.5
Post-Install Checklist
Nexus ships with some default passwords and settings for repository indexing that need to be changed for your installation to be useful (and secure). After installing and running Nexus, you need to make sure that you complete the following tasks: Step 1: Change the Administrative Password and Email Address The administrative password defaults to admin123. The rst thing you should do to your new Nexus installation is change this password. To change the administrative password login as "admin" with the password "admin123", and click on Change Password under the Security menu in the left-hand side of the browser window. For more detailed instructions, see Section 5.8. Step 2: Congure the SMTP Settings Nexus can send username and password recovery emails, to enable this feature, you will need to congure Nexus with a SMTP Host and Port as well as any necessary authentication parameters that Nexus needs to connect to the mail server. To congure the SMTP settings, load the server conguration dialog shown in Figure 6.1. Step 3: Enable Remote Index Downloads Nexus ships with three important proxy repositories for the Maven Central repository, Apache Snapshot repository, and the Codehaus Snapshot repository. Each of these repositories contains thousands (or tens of thousands) of artifacts and it would be impractical to download the entire contents of each. To that end, most repositories maintain an index which catalogs the entire contents and provides for fast and efcient searching. Nexus uses these remote indexes to search for artifacts, but weve disabled the index download as a default setting. To download remote indexes: 1. Click on Repositories under the Administration menu in the left-hand side of the browser window.
Ed. 3.0.2

23 / 241
2. Select each of the three proxy repositories and change Download Remote Indexes to true in the Conguration tab. Youll need to load the dialog shown in Figure 6.9 for each of the three repositories. This will trigger Nexus to re-index these repositories, during which the remote index les will be downloaded. It might take Nexus a few minutes to download the entire index, but once you have it, youll be able to search the entire contents of the Maven repository. Once youve enabled remote index downloads, you still wont be able to browse the complete contents of a remote repository. Downloading the remote index allows you to search for artifacts in a repository, but until you download those artifacts from the remote repository they will not show in the repository tree when you are browsing a repository. When browsing a repository, you will only be shown artifacts which have been downloaded from the remote repository. Step 4: Change the Deployment Password The deployment users password defaults to deployment123. Change this password to make sure that only authorized developers can deploy artifacts to your Nexus installation. To change the deployment password: log in as an administrator, click on Security to expand the Security menu, then click on Users. You should then see a list of users. Right-click on the deployment user and select "Set Password". Step 5: Install Professional License (Nexus Professional Only) If you are running Nexus Professional and you have purchased a license from Sonatype, you will need to upload your license. This license will be emailed to you after you have purchased Nexus Professional from http://store.sonatype.com. To load the License tab, click on Licensing under the Enterprise menu in the Nexus application menu. For more information about installing a Nexus Professional license le, see Section 3.9. Step 6: If necessary, set the LANG Environment Variable If your Nexus instance needs to store conguration and data using an international character set, you should set the LANG environment variable. The Java Runtime will adapt to the value of the LANG environment variable and ensure that conguration data is saved using the appropriate character type. If you are starting Nexus as a service, place this environment variable in the startup script found in /etc/init.d/nexus. For more information about locale settings in Ubuntu read https://help.ubuntu.com/community/Locale
3.6
Conguring Nexus as a Service
When installing Nexus, you will often want to congure Nexus as a service. If you are on Windows, the Nexus distribution includes binaries that can work with the Windows Services subsystem and if you are on another platform such as GNU/Linux Nexus also includes scripts that can be congured to start Nexus as a service. The following sections provide instructions for conguring Nexus as a service.
3.6.1
Startup Scripts for GNU/Linux
You can congure Nexus to start automatically, by copying the nexus script to the /etc/init.d directory. On a GNU/Linux system (tested with Redhat, Fedora, Ubuntu, or CentOS) perform the following operations as the root user:
1. Copy either $NEXUS_HOME/bin/jsw/linux-ppc-64/nexus, $NEXUS_HOME/bin/jsw/linux-x86-32/nexus, or $NEXUS_HOME/b x86-64/nexus to /etc/init.d/nexus 2. Make the /etc/init.d/nexus script executable - chmod 755 /etc/init.d/nexus 3. Edit this script changing the following variables: a. Change APP_NAME b. Change APP_LONG_NAME to "Sonatype Nexus" c. Add a variable NEXUS_HOME which points to your Nexus installation directory d. Add a variable PLATFORM which contains either linux-x86-32, linux-x86-64, or linux-ppc-64
Ed. 3.0.2

24 / 241
4. Change WRAPPER_CMD to $NEXUS_HOME/bin/jsw/$PLATFORM/wrapper 5. Change WRAPPER_CONF to $NEXUS_HOME/bin/jsw/conf/wrapper.conf 6. Change PIDDIR to /var/run 7. Add a JAVA_HOME variable which points to your local Java installation 8. Add a $JAVA_HOME/bin to the PATH 9. (Optional) Set the RUN_AS_USER to "nexus". If you do this, you will need to: a. Create a nexus user b. Change the Owner and Group of your nexus install directory to nexus
Note If you set the "RUN_AS_USER" variable, youll have to change the "pid" directory to point to a directory where this user has read/write permissions. In most Linux distributions, /var/run is only writable by root. The properties that would need to be added to customize the PID le location is "wrapper.pid". For more information about this property and how it would be congured in wrapper.conf, see: http://wrapper.tanukisoftware.com/doc/english/properties.html
Figure 3.5: Script Directory for 32-bit GNU/Linux At the end of this you should have a le in /etc/init.d/nexus which starts with a series of conguration properties which look something like this (assuming that youve installed Nexus in /usr/local/nexus and that you have Java installed in /usr/java/latest
JAVA_HOME=/usr/java/latest PATH=$PATH:$JAVA_HOME/bin APP_NAME="nexus" APP_LONG_NAME="Sonatype Nexus" NEXUS_HOME=/usr/local/nexus PLATFORM=linux-x86-64 WRAPPER_CMD="$NEXUS_HOME/bin/jsw/${PLATFORM}/wrapper" WRAPPER_CONF="$NEXUS_HOME/bin/jsw/conf/wrapper.conf" PRIORITY= PIDDIR="/var/run" #RUN_AS_USER=nexus
Ed. 3.0.2

25 / 241
3.6.1.1
Add Nexus as a Service on Redhat, Fedora, and CentOS
This script has the appropriate chkcong directives, so all you need to do to add Nexus as a service is run the following commands:
$ cd /etc/init.d $ chkconfig --add nexus $ chkconfig --levels 345 nexus on $ service nexus start Starting Sonatype Nexus... $ tail -f /usr/local/nexus/logs/wrapper.log
The second command adds nexus as a service to be started and stopped with the service command and managed by the chkcong manages the symbolic links in /etc/rc[0-6].d which control the services to be started and stopped when the operating system restarts or transitions between run-levels. The third command adds nexus to run-levels 3, 4, and 5. The service command starts Nexus, and the last command tails the wrapper.log to verify that Nexus has been started successfully. If Nexus has started successfully, you should see a message notifying you that Nexus is listening for HTTP
3.6.1.2 Add Nexus as a Service on Ubuntu
The process for setting Nexus up as a service on Ubuntu differs slightly from the process used on a Redhat variant. Instead of running chkcong, you should run the following sequence of commands once youve congured the startup script in /etc/init.d
$ cd /etc/init.d $ update-rc.d nexus defaults $ service nexus start Starting Sonatype Nexus... $ tail -f /usr/local/nexus/logs/wrapper.log
3.7
Running Nexus Behind a Proxy
If you installed Nexus as a stand-alone application, Nexus is running on a high-performance servlet container based on Java NIO. From a performance perspective, there is no reason for you not to run Nexus by itself without a proxy. Yet, more often than not, organizations run applications behind a proxy for security concerns and to consolidate multiple disparate applications using tools like mod_rewrite. For this reason, weve included some brief instructions for conguration Apache httpd. We assume that youve already installed Apache 2, and that you are using a Virtual Host for www.somecompany.com. Lets assume that you wanted to host Nexus behind Apache HTTPd at the URL http://www.somecompany.com. To do this, youll need to change the context path that Nexus is served from. 1. Edit plexus.properties in $NEXUS_HOME/conf. Youll see an element named webapp-context-path. Change this value from "/nexus" to "/" 2. Restart Nexus and Verify that it is available on http://localhost:8081/ 3. Clear the Base URL in Nexus as shown in Figure 6.3 under Application Server Settings. At this point, edit the HTTPd conguration le for the www.somecompany.com virtual host. Include the following to expose Nexus via mod_proxy at http://www.somecompany.com/
ProxyRequests Off ProxyPreserveHost On <VirtualHost *:80> ServerName www.somecompany.com ServerAdmin [email protected] ProxyPass / http://localhost:8081/ ProxyPassReverse / http://localhost:8081/ ErrorLog logs/somecompany/nexus/error.log CustomLog logs/somecompany/nexus/access.log common </VirtualHost>
Ed. 3.0.2

26 / 241
If you just wanted to continue to serve Nexus at the /nexus context path, you would not change the contextPath in $NEXUS_HOME/conf/p and you would include the context path in your ProxyPass and ProxyPassReverse
ProxyPass /nexus/ http://localhost:8081/nexus/ ProxyPassReverse /nexus/ http://localhost:8081/nexus/
Apache conguration is going to vary based on your own applications requirements and the way you intend to expose Nexus to the outside world. If you need more details about Apache httpd and mod_proxy, please see http://httpd.apache.org
3.8
Installing the Nexus WAR
The Nexus Open Source WAR has been successfully tested in Tomcat, Jetty, and Resin. If you need to run Nexus under Glasssh, please see Section 3.8.1. To download the Nexus Open Source WAR, go to http://nexus.sonatype.org/using/download.html. Click on the Download Site link and then download the Nexus WAR. Once you have downloaded the Nexus Open Source WAR, you can install it in a servlet container or application server. The process for installing a WAR in an servlet container or application server is going to vary for each specic application. Often, this installation process is as simple as dropping a WAR le in a special directory and restarting the container. For example, to install the Nexus WAR in Tomcat, drop the nexus-webapp-1.6.0.war le in $TOMCAT_HOME/webapps and restart your Tomcat instance. Assuming that Tomcat is congured on port 8080 once Tomcat is started, Nexus will be available on http://localhost:8080/nexus-webapp-1.6.0. If you would like a less verbose URL, copy nexus-webapp-1.6.0.war to a le named nexus.war before copying the distribution to $TOMCAT_HOME/webapps
Note When installing Nexus as a WAR in an application server or servlet container, it automatically creates a sonatype-work directory in ~/sonatype-work. This directory contains all of the necessary conguration and repository storage for Nexus.
3.8.1
Running the Nexus WAR in Glasssh
There is a known logging conguration conict between the Nexus Open Source WAR and Glasssh. To address this conict, you will need to modify the log4j.properties le and change a few of the directives that print messages to the console. The log4j.properties le is located in /sonatype-work/conf/log4j.properties. This le is created the rst time you attempt to deploy Nexus to Glasssh. To create this le, deploy work and the log4j.properties Edit this log4j.properties le as follows: 1. On the rst line, change "log4j.rootLogger=INFO, console," to "loglelog4j.rootLogger=INFO, logle" 2. Remove the last three lines starting with "log4j.appender.console" These changes will instruct Log4J not to print messages to the console. Once you make these edits, restart Glasssh.
3.9
Installing a Nexus Professional License
To install a Nexus Professional license, click on Licensing in the Enterprise menu. Clicking on Licensing will bring up the panel shown in Figure 3.6. To upload your Nexus Professional license, click on Browse. . . , select the le, and click on Upload.
Ed. 3.0.2

27 / 241
Figure 3.6: Nexus Professional Licensing Panel Once you have selected a license and uploaded it to Nexus, Nexus Professional will display a dialog box with the Nexus Professional End-user License Agreement as shown in Figure 3.7. If you agree with the terms and conditions, click on "I Agree".
Ed. 3.0.2

28 / 241
Figure 3.7: Nexus Professional End-user License Agreement Once you have agreed to the terms and conditions contained in the End User License Agreement, Nexus Professional will then display a dialog box conrming the installation of a Nexus Professional license as shown in Figure 3.8.
Figure 3.8: License Upload Finished Dialog If you need to move your Nexus Professional license, you can click on the "Uninstall License" button at the bottom of the Licensing Panel. Clicking on this button will show the dialog in Figure 3.9 which conrms that you want to uninstall a license.
Ed. 3.0.2

29 / 241
Figure 3.9: Uninstall License Conrmation Dialog Clicking Yes in this dialog box will uninstall the license from Nexus Professional and display another dialog which conrms that the license has been successfully uninstalled.
Figure 3.10: License Uninstall Completed Dialog
3.9.1
Evaluation Expiration
If you have downloaded the Nexus Professional evaluation, you will have thirty days to evaluate the product. After the expiration of this thirty day evaluation period, Nexus Professional will revert back to Nexus Open Source. To reactivate Nexus Professional after the end of your evaluation period, contact a Sonatype sales representative at [email protected]
3.10
Sonatype Nexus Directories
The following sections describe the various directories that are a part of any Nexus installation. When you install Nexus Open Source or Nexus Professional, you are creating two directories: a directory which contains the Nexus runtime and application, and a directory which contains your own conguration and data. When you upgrade to a newer version of Nexus, you replace the Nexus application directory and retain all of your own custom conguration and repository data in sonatype-work/
3.10.1
Sonatype Nexus Work Directory
The Sonatype Work directory is installed as a sibling to the nexus application directory, and the location of this directory can be congured via the plexus.properties le which is described in Section 3.10.2. Figure 3.11 shows the Sonatype Nexus work directory with the conf/
Ed. 3.0.2

30 / 241
Figure 3.11: The Sonatype Nexus Work Directory The Sonatype Nexus work directory contains the following subdirectories: backup/ If you have congured a scheduled job to backup Nexus conguration, this directory is going to contain a number of ZIP archives that contain snapshots of Nexus conguration. Each ZIP le contains the contents of the conf/ directory. (Automated backups are a feature of Nexus Professional.) conf/ This directory contains the Nexus conguration. Settings that dene the list of Nexus repositories, the logging conguration, the staging and procurement conguration, and the security settings are all captured in this directory. indexer/ Contains a Nexus index for all repositories and repository groups managed by Nexus. A Nexus index is a Lucene index which is the standard for indexing and searching a Maven repository. Nexus maintains a local index for all repositories, and can also download a Nexus index from remote repositories. logs/ The nexus.log le that contains information about a running instance of Nexus. This directory also contains archived copies of Nexus log les. Nexus log les are rotated every day. To reclaim disk space, you can delete old log les from the logs/ p2/ If you are using the P2 repository management features of Nexus Professional, this directory contains a local cache of P2 repository artifacts. proxy/ Stores data about the les contained in a remote repository. Each proxy repository has a subdirectory in the proxy/attributes/ directory and every le that Nexus has interacted with in the remote repository has an XML le which captures such data as the: last requested timestamp, the remote URL for a particular le, the length of the le, and the digests for a particular le among other things. If you need to backup the local cached contents of a proxy repository, you should also back up the contents of the proxy repositorys directory under proxy/attributes/
Ed. 3.0.2

31 / 241
storage/ Stores artifacts and metadata for Nexus repositories. Each repository is a subdirectory which contains the artifacts in a repository. If the repository is a proxy repository, the storage directory will contain locally cached artifacts from the remote repository. If the repository is a hosted repository, the storage directory will contain all artifacts in the repository. If you need to backup the contents of a repository, you should backup the contents of the storage directory. template-store/ Contains templates for default repositories. If you examine the XML les in this directory, you will see that they contain default templates for each different type of repository. For example, the repository-default_proxy_release.xml le contains defaults for a Proxy repository with a release policy. timeline/ Contains an index which Nexus uses to store events and other information to support internal operations. Nexus uses this index to store feeds and history. trash/ If you have congured scheduled jobs to remove snapshot artifacts or to delete other information from repositories, the deleted data will be stored in this directory. To empty this trash folder, view a list of Nexus repositories, and then click on the Trash icon in the Nexus user interface. The conf/ directory contains a number of les which allow for conguration and customization of Nexus. All of the les contained in this directory are altered by the Nexus administrative user interface. While you can change the conguration settings contained in these les with a text editor, Sonatype recommends that you modify the contents of these les using the Nexus administrative user interface. log4j.properties Contains Log4J conguration, if you need to customize the detail of log messages, the frequency of log le rotation, or if you want to connect your own, custom Log4J appenders, you would alter this conguration le. lvo-plugin.xml Contains conguration for the latest version plugin. This XML le contains the location of the properties le which Nexus queries to check for a newer version of Nexus. nexus.xml The bulk of the conguration of Nexus is contained in this le. This le maintains a list of repositories, and all server-wide conguration like the SMTP settings, security realms, repository groups, targets, and path mappings. pgp.xml Contains PGP key server conguration. nexus-obr-plugin.properties Contains conguration for the Nexus OSGi Bundle repository plugin in Nexus Professional. procurement.xml Contains conguration for the Nexus Procurement plugin in Nexus Professional. security.xml Contains security information about users and roles in Nexus. staging.xml Contains conguration for the Nexus Staging plugin in Nexus Professional.
3.10.2
Nexus Conguration Directory
After installing Nexus Professional, you will have a nexus-professional-webapp-1.9.2/ directory and a sonatype-work/ directory, and after installing Nexus Open Source, you will have a nexus-webapp-1.9.2/ directory and a sonatype-work/ directory. This section details the contents of the conf directory that is shown in Figure 3.12. This directory contains conguration for the Jetty servlet container. You will only need to modify the les in this directory if you are customizing the conguration of Jetty servlet container, or the behavior of the scripts that start Nexus.
Ed. 3.0.2

32 / 241
Figure 3.12: Nexus Professional Conguration Directory The les and folders contained in this directory are: classworlds.conf Denes the order in which resources and classes are loaded from the classpath. It is unlikely that even the most advanced Nexus users will ever need to customize the contents of this le. plexus.properties This le contains conguration variables which control the behavior of Plexus and the Jetty servlet container. If you are customizing the port and host that Nexus will listen to, you would change the application-port and application-host properties dened in this le. If you wanted to customize the location of the Sonatype work directory, you would modify the value of the nexus-work property in this conguration le. plexus.xml Denes the class names and conguration of components which are loaded by Plexus at startup. This le should never be changed as all congurable values have been removed from this le and placed in plexus.properties jetty.xml If this le is present in the conf/ directory, it will be used to congure Jetty. The conf/examples/ directory contains sample Jetty conguration les which can be used to customize the behavior of the Jetty servlet container: jetty.xml contains a jetty.xml sample with no customizations. This sample le listens on the "application-port" dened in plexus.properties jetty-ajp.xml Contains a jetty.xml sample which will congure Nexus to listen on an AJP port 8009. This conguration can be used if you are proxying your Nexus server with web server which understands the AJP protocol such as Apache httpd with the mod_proxy_ajp module. jetty-dual-ports-with-ssl.xml Contains a jetty.xml sample which congures Nexus to listen on both the "application-port" and "application-port-ssl" (as dened in plexus.properties). This sample conguration also contains the SSL redirect rule. jetty-faster-windows.xml Contains a jetty.xml sample which congures a response buffer size that will address performance issues on Windows 2003 Server, for more information about this x see the Jetty Wiki
Ed. 3.0.2

33 / 241
jetty-header-buffer.xml Contains a jetty.xml sample which increases the headerBufferSize to 8k from the default of 4k. Documentation about the header buffer size can be found on the Jetty Wiki jetty-simple-https-proxy.xml Contains a jetty.xml sample which should be used if you are proxying a Nexus instance with a web server that is handling SSL. For example, if you were proxying Nexus with Apache httpd server using mod_ssl you would use this conguration to congure the Jetty RewriteHandler jetty-ssl.xml Contains a jetty.xml sample which will only serve SSL encrypted content from "application-port" (as dened in plexus.properties The conf/examples/proxy-https/ directory contains two les: apache2.conf and jetty.xml contains sample mod_proxy directives to congure Apache httpd to handle SSL.
Ed. 3.0.2

34 / 241
Chapter 4
Conguring Maven to Use Nexus

4.1 Introduction
To use Nexus, you will congure Maven to check Nexus instead of the public repositories. To do this, youll need to edit your mirror settings in your ~/.m2/settings.xml le. First, were going to demonstrate how to congure Maven to consult your Nexus installation instead of retrieving artifacts directly from the Maven Central repository. After we override the central repository and demonstrate that Nexus is working, well circle back to provide a more sensible set of settings that will cover both releases and snapshots.
4.2
Conguring Maven to Use a Single Nexus Group
If you are adopting Nexus for internal development you should congure a single Nexus group which contains both releases and snapshots. To do this, add snapshot repositories to your public group, and add the following mirror conguration to your Maven settings in ~/.m2/settings.xml Conguring Maven to Use a Single Nexus Group
<settings> <mirrors> <mirror>  <id>nexus</id> <mirrorOf>*</mirrorOf> <url>http://localhost:8081/nexus/content/groups/public</url> </mirror> </mirrors> <profiles> <profile> <id>nexus</id>   <repositories> <repository> <id>central</id> <url>http://central</url> <releases><enabled>true</enabled></releases> <snapshots><enabled>true</enabled></snapshots> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>central</id>
Ed. 3.0.2

35 / 241
<url>http://central</url> <releases><enabled>true</enabled></releases> <snapshots><enabled>true</enabled></snapshots> </pluginRepository> </pluginRepositories> </profile> </profiles> <activeProfiles>  <activeProfile>nexus</activeProfile> </activeProfiles> </settings>
In Conguring Maven to Use a Single Nexus Group we have dened a single prole: nexus prole is congured to download from the central repository with a bogus URL. This URL is overridden by the mirror setting in the same settings.xml le to point to the URL of your single Nexus group. The nexus group is then listed as an active prole in the activeProles element.
4.3
Adding Custom Repositories for Missing Dependencies
If youve congured your Maven settings.xml to list the Nexus public group as a mirror for all repositories, you might encounter projects which are unable to retrieve artifacts from your local Nexus installation. This usually happens because you are trying to build a project which has dened a custom set of repositories and snapshotRepositories in a pom.xml. When you encounter a project which contains a custom repository element in a pom.xml add this repository to Nexus as a new proxy repository and then add the new proxy repository to the public group.
4.4
Adding a New Repository
To add a repository, log into Nexus as an Administrator, and click on the Repositories link in the left-hand navigation menu in the Views/Repositories section. Clicking on this link should bring up a window that lists all of the repositories which Nexus knows about. Youll then want to create a new proxy repository. To do this, click on the Add link that is directly above the list of repositories. When you click the Add button, click the down arrow directly to the right of the word Add, this will show a drop-down which has the options: Hosted Repository, Proxy Repository, Virtual Repository, and Repository Group. Since you are creating a proxy repository, click on Proxy Repository.
Figure 4.1: Creating a New Nexus Proxy Repository
Ed. 3.0.2

36 / 241
Once you do this, you will see a screen resembling Figure 4.2. Populate the required elds Repository ID and the Repository Name with "caja" and "Google Caja". Set the Repository Policy to "Release", and the Remote Storage Location to http://googlecaja.googlecode.com/svn/maven
Figure 4.2: Adding a Nexus Repository Once youve lled out this screen, click on the Save button. Nexus will then be congured with the caja proxy repository. Do the same thing for the oauth repository. Create a repository with the Repository ID of oauth, with a Release policy, and the Remote Storage Location of http://oauth.googlecode.com/svn/code/maven
4.5
Adding a Repository to a Group
Next you will need to add both of these new repositories to the public Nexus Group. To do this, click on the Repositories link in the left-hand navigation menu in the Views/Repositories section. Nexus lists Groups and Repositories in the same list so click on the public group. After clicking on the public group, you should see the Browse and Conguration tabs in the lower half of the Nexus window.
Note If you click on a repository or a group in the Repositories list and you do not see the Conguration tab, this is because your Nexus user does not have administrative privileges. To perform the conguration tasks outlined in this chapter, you will need to be logged in as a user with administrative privileges.
Ed. 3.0.2

37 / 241
Clicking on the Conguration tab will bring up a screen which looks like Figure 4.3.
Figure 4.3: Adding New Repositories to a Nexus Group To add the two new repositories to the public Nexus Group, nd the repositories in the Available Repositories list on the right, click on the repository you want to add and drag it to the left to the Ordered Group Repositories list. Once the repository is in the Ordered Group Repositories list you can click and drag the repository within that list to alter the order in which a repository will be searched for a matching artifact. Once the Google Caja and Google OAuth project repositories are added to the public Nexus Group, you should be able to build Apache Shindig and watch Maven download the Caja and OAuth artifacts from the respective repositories.
Note Nexus makes use of an interesting Javascript widget library named ExtJS. ExtJS provides for a number of interesting UI widgets that allow for rich interaction like the drag-drop UI for adding repositories to a group and reordering the contents of a group.
In the last few sections, you encountered a situation where you needed to add two custom repositories to a build in order to download two libraries (Google Caja and Google OAuth) which are not available in the Maven Central repository. If you were not using a repository manager, you would have added these repositories to the repository element of your projects POM, or you would have asked all of your developers to modify ~/.m2/settings.xml to reference two new repositories. Instead, you used the Nexus repository manager to add the two repositories to the public group. If all of the developers are congured to point to the public group in Nexus, you can freely swap in new repositories without asking your developers to change local conguration, and youve gained a certain amount of control over which repositories are made available to your development team.
Ed. 3.0.2

38 / 241
Chapter 5
Using Nexus
5.1 Introduction
Nexus provides for anonymous access for users who only need to search repositories, browse repositories, and peruse the system feeds. This anonymous access level changes the navigation menu and some of the options available when you right-click on a repository. This read-only access displays a user interface shown in Figure 5.1.
Figure 5.1: Nexus Interface for Anonymous Users
Ed. 3.0.2

39 / 241
5.2
Browsing Repositories
One of the most straightforward uses of the Nexus is to browse the structure of a Maven repository. If you click on the Browse Repositories menu item in the Views menu, you should see the following display. The top-half of Figure 5.2 shows you a list of groups and repositories along with the type of the repository and the repository status. To browse the artifacts that are stored in a local Nexus instance, click on the Browse Storage tab for a repository as shown in Figure 5.2.
Figure 5.2: Browsing a Nexus Repository When you are browsing a repository, you can right click on any le and download it directly to your browser. This allows you to retrieve specic artifacts manually, or examine a POM le in the browser.
Note When browsing a remote repository you might notice that the tree doesnt contain all of the artifacts in a repository. When you browse a proxy repository, Nexus is displaying the artifacts which have been cached locally from the remote repository. If you dont see an artifact you expected to see through Nexus, it only means that Nexus has yet to cache the artifact locally. If you have enabled remote repository index downloads, Nexus will return search results that may include artifacts not yet downloaded from the remote repository. Figure 5.2, is just an example, and you may or may not have the doxia-core artifact available in your installation of Nexus.
A Nexus proxy repository acts as a local cache for a remote repository, in addition to downloading and caching artifacts locally, Nexus will also download an index of all the artifacts stored in a particular repository. When searching or browsing for artifacts, it is often more useful to search and browse the repository index. To view the repository index, click on the Browse Index tab for a particular repository to load the interface shown in Figure 5.3.
Ed. 3.0.2

40 / 241
Figure 5.3: Browsing a Nexus Repository Index As shown in Figure 5.3, if an artifact has been downloaded from a remote repository and cached in Nexus, the artifact or folder will display a small Nexus logo.
5.2.1
View Artifact Dependencies
Nexus Professional provides you with the ability to browse an artifacts dependencies. Using the artifact metadata found in an artifacts POM, Nexus will scan a repository or a repository group and attempt to resolve and display an artifacts dependencies. To view an artifacts dependencies, browse the repository storage or the repository index, select an artifact (or an artifacts POM), and then click on the Maven Dependency tab. On the Maven Dependency tab, you will see the following form elements: Repository When resolving an artifacts dependencies, Nexus will query an existing repository or repository group. In many cases it will make sense to select the same repository group you are referencing in your Maven Settings. If you encounter any problems during the dependency resolution, you need to make sure that you are referencing a repository or a group which contains these dependencies. Mode An artifacts dependencies can be list as either a tree or a list. When dependencies are displayed in a tree, you can inspect direct dependencies and transitive dependencies. This can come in handy if you are assessing an artifact based on the dependencies it is going to pull into your projects build. When you list dependencies as a list, Nexus is going to perform the same process used by Maven to collapse a tree of dependencies into a list of dependencies using rules to merge and override dependency versions if there are any overlaps or conicts. Once you have selected a repository to resolve against and a mode to display an artifacts dependencies, click on the Resolve button as shown in Figure 5.4. Clicking on this button will start the process of resolving dependencies, depending on the number of artifacts already cached by Nexus, this process can take anywhere from a few seconds to minute. Once the resolution process is nished, you should see the artifacts dependencies as shown in Figure 5.4.
Ed. 3.0.2

41 / 241
Figure 5.4: View an Artifacts Dependencies Once you have resolved an artifacts dependencies, you can double click on a row in the tree or list of dependencies to navigate to other artifacts within the Nexus interface.
5.2.2
Viewing Artifact Metadata
Nexus Professional gives you the ability to view artifact metadata. When browsing repository storage or a repository index, clicking on an artifact will load the Artifact Information panel. Selecting the Artifact Metadata tab will display the interface shown in Figure 5.5.
Figure 5.5: Viewing Artifact Metadata
Ed. 3.0.2

42 / 241
Artifact metadata consists of a key, a value, and a namespace. Existing metadata from an artifacts POM is given a urn:maven namespace, and custom attributes are stored under the urn:nexus/user namespace.
5.2.3
Editing Artifact Metadata
Nexus Professional gives you the ability to add custom attributes to artifact metadata. To add a custom attribute, click on an artifact in Nexus, and select the Artifact Metadata tab. On the Artifact Metadata tab, click on the Add. . . button and a new row will be inserted into the list of attributes. Supply a key and value and click the Save button to update an artifacts metadata. Figure 5.6 shows the Artifact Metadata panel with two custom attributes: "approvedBy" and "approved".
Figure 5.6: Editing Artifact Metadata
5.3
Browsing Groups
Nexus contains ordered groups of repositories which allow you to expose a series of repositories through a single URL. More often than not, an organization is going to point Maven at the two default Nexus groups: Public Repositories and Public Snapshot Repositories. Most end-users of Nexus are not going to know what artifacts are being served from what specic repository, and they are going to want to be able to browse the Public Repository. To support this use case, Maven allows you to browse the contents of a Nexus Group as if it were a single merged repository with a tree structure. Figure 5.7, shows the browsing storage interface for a Nexus Group. There is no difference to the user experience of browsing a Nexus Group vs. browsing a Nexus Repository.
Ed. 3.0.2

43 / 241
Figure 5.7: Browsing a Nexus Group When browsing a Nexus groups storage, you are browsing the underlying storage for all of the repositories which are contained in a group. If a Nexus group contains proxy repositories, the Browse Storage tab will show all of the artifacts in the Nexus group that have been download from the remote repositories. To browse and search all artifacts available in a Nexus group, click on the Browse Index tab to load the interface shown in Figure 5.8.
Ed. 3.0.2

44 / 241
Figure 5.8: Browsing a Nexus Group Index
5.4
Searching for Artifacts
In the left-hand navigation area, there is an Artifact Search text eld next to a magnifying glass. To search for an artifact by groupId or artifactId, type in some text and click the magnifying glass. Typing in the search term "guice" and clicking the magnifying glass should yield a search result similar to Figure 5.9.
Ed. 3.0.2

45 / 241
Figure 5.9: Results of an Artifact Search for "guice" Once youve located the artifact you were looking for you can click on the pom link to download the POM or the artifact link to download the artifact. Look at the Version column in the search results. In this version of the search interface, we decided to list the most recent version. If you need to view a different version, click on "Show All Versions". Clicking on "Show All Versions" will drill down into the list of available versions. Look at the Download column in the search results. This Download column contains direct download links for the most recent version of the artifact. To download a matching artifact, just click on a link in this column. Select a search result, and you will see the artifact in the Repository Tree in the lower left-hand quadrant of this interface. This is helpful to give you context for an artifact. An artifact could be present in more than one repository. If this is the case, click on the value next to "Viewing Repository" to switch between multiple matching repositories. In the lower right-hand quadrant of the interface, you will see a number of tabs which show information about the selected search result: Maven Information: This contains basic identiers and a snippet of XML you can use to add this artifact as a project dependency. Archive Browser (Nexus Professional): This gives you a way to explore the contents of an archive in the repository. You can view the les and folders contained in a matching search result. Artifact Information: This tab contains timestamps, le size, checksum values, and a list of repositories containing a given artifact. Artifact Metadata (Nexus Professional): This tab shows all of the built-in and custom metadata associated with an artifact. In addition to searching by a groupId or an artifactId, Nexus has a feature which allows you to search for an artifact by a checksum.
Ed. 3.0.2

46 / 241
Warning Let me guess? You installed Nexus, ran to the search box, typed in the name of a group or an artifact, pressed search, and saw absolutely nothing. No results. Nexus isnt going to retrieve the remote repository indexes by default, you need to activate downloading of remote indexes for the three proxy repositories that Nexus ships with. Without these indexes, Nexus has nothing to search. Find instructions for activating index downloads in Section 6.5.
5.4.1
Nexus OpenSearch Integration
OpenSearch a standard which facilitates searching directly from your browsers search box. If you are using Internet Explorer 7+ or Firefox 2+ you can add any Nexus instance as an OpenSearch provider. Then you can just type in a search term into your browsers search eld and quickly search for Maven artifacts. To congure OpenSearch, load Nexus in a browser and then click on the dropdown next to the search tool that is embedded in your browser. Figure 5.10 shows the Add Nexus option that is present in Firefoxs OpenSearch provider dropdown.
Figure 5.10: Conguring Nexus as an OpenSearch Provider Once you have added Nexus to the list of OpenSearch providers, click on the dropdown next to the search term and select Nexus (localhost) from the list of OpenSearch providers. Type in a groupId, artifactId, or portion of a Maven identier and press enter. Your opensearch-friendly web browser will then take you to the search results page of Nexus displaying all the artifacts that match your search term.
Ed. 3.0.2

47 / 241
Figure 5.11: OpenSearch Search Results in Nexus Once, you have congured your browser to use Nexus as an OpenSearch provider, searching for a Maven artifact is as simple as typing in a groupId or artifactId, selecting Nexus from the dropdown shown in Figure 5.12, and performing a search.
Figure 5.12: Nexus Available as an Option in the Firefox OpenSearch Provider List
Ed. 3.0.2

48 / 241
5.4.2
Searching Artifact Metadata
Nexus Professional provides you with the ability to congure custom artifact metadata and search for artifacts with specic metadata. To search for artifacts using metadata, click on the Advanced Search link directly below the search eld in the Nexus application menu to open the Search panel. Once in the search panel, click on the Keyword Search and click on Metadata Search in the search type dropdown as shown in Figure 5.13.
Figure 5.13: Searching Artifact Metadata Once you select the Metadata Search you will see two search elds and an operator dropdown. The two search elds are the key and value of the metadata you are searching for. The key corresponds to the key of the metadata you are searching for, and the value contains the value or value range you are searching for. The operator dropdown can be set to Equals, Matches, Bounded, or Not Equal.
Figure 5.14: Metadata Search Results for Custom Metadata Once you locate a matching artifact in the Metadata Search interface, click on the artifact and then select the Artifact Metadata to examine an artifacts metadata as shown in Figure 5.15.
Ed. 3.0.2

49 / 241
Figure 5.15: Metadata Search Results for Custom Metadata
5.5
Uploading Artifacts
When your build makes use of proprietary or custom dependencies which are not available from public repositories, you will often need to nd a way to make them available to developers in a custom Maven repository. Nexus ships with a precongured 3rd Party repository that was designed to hold 3rd Party dependencies which are used in your builds. To upload artifacts to a repository, select a hosted repository in the Repositories panel and then click on the Artifact Upload tab. Clicking on the Artifact Upload tab will display the tab shown in Figure 5.16.
Ed. 3.0.2

50 / 241
Figure 5.16: Artifact Upload Form To upload an artifact, click on Select Artifact(s) for Upload. . . and select one or more artifacts from the lesystem to upload. Once you have selected an artifact, you can modify the classier and the extension before clicking on the Add Artifact button. Once you have clicked on the Add Artifact button, you can then congure the source of the Group, Artifact, Version (GAV) parameters. If the artifact you are uploading is a JAR le that was created by Maven it will already have POM information embedded in it. If you are uploading a JAR from a vendor you will likely need to set the Group Identier, Artifact Identier, and Version manually. To do this, select GAV Parameters from the GAV Denition dropdown at the top of this form. Selecting GAV Parameters will expose a set of form elds which will let you set the Group, Artifact, Version, and Packaging of the artifacts being uploaded. If you would prefer to set the Group, Artifact, and Version from a POM le associated with the uploaded artifact, select From POM in the GAV Denition dropdown. Selecting From POM in this dropdown will expose a button labeled "Select POM to Upload". Once a POM le has been selected for upload, the name of the POM le will be displayed in the form eld below this button. The Artifact Upload panel supports multiple artifacts with the same Group, Artifact, and Version identiers. For example, if you need to upload multiple artifacts with different classiers, you may do so by clicking on Select Artifact(s) for Upload and Add Artifact multiple times.
5.6
Browsing System Feeds
Nexus provides feeds that capture system events, you can browse these feeds by clicking on System Feeds under the View menu. Clicking on System Feeds will show the panel in Figure 5.17. You can use these simple interface to browse the most recent reports of artifact deployments, cached artifacts, broken artifacts, and storage changes that have occurred in Nexus.
Ed. 3.0.2

51 / 241
Figure 5.17: Browsing Nexus System Feeds These feeds can come in handy if you are working at a large organization with multiple development teams deploying to the same instance of Nexus. If such an arrangement, all developers in an organization can subscribe to the RSS feeds for New Deployed Artifacts as a way to ensure that everyone is aware when a new release has been pushed to Nexus. Exposing these system events as RSS feeds also opens to the door to other, more creative uses of this information, such as connecting Nexus to external automated testing systems. To access the RSS feeds for a specic feed, select the feed in the System Feeds view panel and then click on the Subscribe button. Nexus will then load the RSS feed in your browse and you can subscribe to the feed in your favorite RSS There are six system feeds available in the System Feeds view, and each has a URL which resembles the following URL
http://localhost:8081/nexus/service/local/feeds/recentlyChangedFiles
Where recentChanges would be replaced with the identier of the feed you were attempting to read. Available system feeds include: Table 5.1: Available System Feeds Feed Identier authcAuthz Broken Artifacts (Checksum mismatch, missing checksums, invalid POMs) errorWarning Description Authentication and Authorization Events brokenFiles
brokenArtifacts Broken Files (Checksum errors.)
Errors, warnings, and exceptions from Nexus
recentlyCachedOrDeployedArtifacts
Ed. 3.0.2

52 / 241
Table 5.1: (continued) Feed Identier New artifacts in all repositories (cached or deployed) recentlyCachedArtifacts New cached les in all repositories recentlyDeployedFiles Changed artifacts in all repositories systemRepositoryStatusChanges Description recentlyCachedOrDeployedFiles New cached artifacts in all repositories recentlyDeployedArtifacts New deployed les in all repositories recentlyChangedFiles Automatic or User-initiated status changes (out-of-service and blocked proxies)
New les in all repositories (cached or deployed) recentlyCachedFiles New deployed artifacts in all repositories recentlyChangedArtifacts Changed les in all repositories systemChanges
5.7
Log Files and Conguration
The Logs and Cong Files link is only visible to Administrative users under the Views menu. Click on this option brings up the dialog shown in Figure 5.18. From this screen you can view the following log and conguration les by clicking on the drop down selection next to the Download button. nexus.log Think of this as the general application log for Nexus. Unless you are an administrative user, you might not have must interest in the information in this log. If you are trying to debug an error, or if you have uncovered a bug in Nexus, youll use this log viewer to diagnose problems with Nexus.
nexus.xml This XML le contains most of the conguration data for your instance of Nexus. It is stored in $NEXUS_HOME/runtime/apps/nex log4j.properties This le controls the logging facility of Nexus using the standard Log4J property le syntax. To edit the format or level of the Log4J logging, click on Log under the Administration menu. For more information about conguring the Nexus Log, see Section 6.15. security.xml This XML le contains the conguration for the XmlAuthenticatingRealm and the XmlAuthorizingRealm. It contains built-in user denitions and any externally mapped users that are mapped to Nexus roles.
Ed. 3.0.2

53 / 241
Figure 5.18: Browsing Nexus Logs and Conguration If you are running Nexus Professional, you should see a few more conguration les in this directory which will correspond to the Procurement and Staging suites. The conguration les specic to Nexus Professional are: procurement.xml This le contains the conguration for the Nexus Procurement Suite as described in Chapter 8. staging.xml This le contains the conguration for the Staging Suite as described in Chapter 9. In Figure 5.18 there is a "tail" checkbox. If this box is checked, then Nexus will always show you the end of a log le. This can come in handy if you want to see a continuously updated log le. When this tail box is checked, a dropdown at the bottom of the panel allows you to set the update frequency. The contents of this dropdown are shown in Figure 5.19. If an update interval is selected, Nexus will periodically refresh the selected log le.
Figure 5.19: Selecting the Update Frequency when Tailing a Log File
5.8
Changing Your Password
If you have the appropriate security privilege, you will see an option to change your password in the left-hand side of the browser. To change your password, click on change password, supply your current password, and choose a new password. When you click on Change Password, your Nexus password will be changed.
Ed. 3.0.2

54 / 241
Figure 5.20: Changing Your Nexus Password
5.9
Filing a Problem Report
If you encounter a problem with Nexus, you can use the Nexus UI to report a bug or le an issue against the Nexus project in Sonatypes JIRA instance. To le a problem report, you will rst need to sign up for an account on http://issues.sonatype.org. In Nexus 1.6, you can click on "File Issue" in the Nexus menu, supply your Sonatype JIRA credentials, and le a problem report. Supply your JIRA username and password along with a short title and a description as shown in the following gure. When you le a Nexus problem report, Nexus will create a new issue in JIRA and attach your conguration and logs to the newly led issue.
Figure 5.21: Generating a Nexus Problem Report
Ed. 3.0.2

55 / 241
Chapter 6
Conguring Nexus
6.1 Conguring Nexus
Many of the conguration screens shown in this section are only available to administrative users. Nexus allows the admin user to customize the list of repositories, create repository groups, customize server settings, and create routes or "rules" that Maven will use to include or exclude artifacts from a repository.
6.2
Customizing Server Conguration
In a production installation of Nexus, youll probably want to customize the administrative password to something other than "admin123", and you might want to override the default directories that Nexus uses to store repository data. To do this, log in as the administrative user and click on Server under Conguration in the left-hand navigation menu. The server conguration screen is shown in Figure 6.1 and Figure 6.2.
Ed. 3.0.2

56 / 241
Figure 6.1: Nexus Server Conguration (File, SMTP, and HTTP Cong)
Ed. 3.0.2

57 / 241
Figure 6.2: Nexus Server Conguration (Security Settings, Anonymous Access)
Ed. 3.0.2

58 / 241
Figure 6.3: Nexus Server Conguration (App Server and HTTP Proxy Cong)
Figure 6.4: Conguring PGP Key server Preferences This screen allows you to change: SMTP Settings Nexus sends email to users who need to recover user names and password. To do this, youll need to congure the SMTP server settings in this dialog. This section of the form takes an SMTP Host and Port as well as other parameters relating to SMTP authentication and encryption. You can also change the From: header of an email from Nexus. User Agent This is the identier which Nexus uses when it is making an HTTP request. You may want to change this if Nexus needs to use an HTTP Proxy, and the Proxy will only work if the User Agent is set to a specic value. Additional URL This is a list of extra parameters to place on a GET request to a remote repository. You could use this to add identifying information to requests.
Ed. 3.0.2

59 / 241
Request Timeout The amount of time Nexus will wait for a request to succeed when interacting with an external, remote repository. Request Retry Attempts The number of times Nexus will retry a failed HTTP Security Settings You can choose to enable or disable security, enable or disable anonymous access, and set the username and password for anonymous access. If you choose to enable security, you are telling Nexus to enforce role-based access control to enforce read and write access to repositories. The anonymous username and password is used to integrate with other realms that may need a special username for anonymous access. In other words, the username and password here is what we attempt to authorize when someone makes an anonymous request. You would change the anonymous username to "guest" if you wanted to integrate Nexus with Microsofts Active Directory. Application Server Settings This section allows you to change the Base URL for your Nexus installation. It is used when generating links in emails and RSS feeds. The Sonatype Nexus repository is available on http://respository.sonatype.org, and it makes use of this Base URL eld to ensure that links in emails and RSS feeds point to the correct URL. If you are hosting Nexus behind a proxy server and you want to make sure that Nexus always uses the specied Base URL, check the "Force Base URL" checkbox. If the Force Base URL is not checked, Nexus will craft URLs in HTTP responses based on the request URL, but it will use the Base URL when it is generating emails. HTTP Proxy Settings There are a number of HTTP Proxy settings for Nexus installations which need to be congured to use an HTTP Proxy. You can specify a host, port, and a number of authentication options which might be required by your proxy server. PGP Key Server Information Nexus Professional uses a PGP Key Server to retrieve PGP keys when validating artifact signatures. To add a new Key Server URL, enter the URL in the Key Server URL eld and click on the Add button. To remove a Key Server URL, click on the URL you wish to remove from the list and click on the Remove button. Key Servers are consulted in the order that they are listed in the Key Server URLs list, to reorder your Key Server URLs, click and drag a URL in the Key Server URLs list.
6.3
Conguring Automated Error Reporting Settings
Nexus can be congured to automatically le exception and error reports with the Nexus project in the Sonatype issue tracker. Activating this setting in your own Nexus installation helps to improve Nexus as the development team will receive automatic error reports if your Nexus instance experiences an error or a failure. The Nexus Server congurations Automated Error Reporting Settings section is shown in Figure 6.5. This section accepts a JIRA username and password, and allows you to congure Nexus to use the default HTTP Proxy Settings when Nexus attempts to le an error report with the Sonatype issue tracker.
Figure 6.5: Conguring the Automated Error Reporting To sign up for an account on the Sonatype JIRA instance, go to http://issues.sonatype.org. Once you see the web site shown in Figure 6.6, click on the "Signup" link below the Login form.
Ed. 3.0.2

60 / 241
Figure 6.6: Sonatype Issue Tracker Fill out the sign-up form shown in Figure 6.7, and choose a username and password. This is the username and password you should use in the Automated Error Reporting Settings section of the Server conguration shown in Figure 6.5.
Ed. 3.0.2

61 / 241
Figure 6.7: Signing Up for a Sonatype Issue Tracker Account
6.4
New Version Notication
Nexus can notify you of new versions of Nexus via the Nexus interface. To enable this feature, check the Enable checkbox in the New Version Notication section of the Nexus server settings as shown in Figure 6.8.
Figure 6.8: New Version Notication Settings
6.5
Managing Repositories
To manage Nexus repositories, log in as the administrative user and click on Repositories in the Views/Repositories menu in the left-hand navigation menu. If you are logged into Nexus as a user with administrative privileges, you will see Conguration and Mirrors tabs in the lower portion of the Nexus window. Nexus provides for three different kinds of repositories: Proxy Repository A proxy repository is a proxy of a remote repository. By default, Nexus ships with the following congured proxy repositories:
Ed. 3.0.2

62 / 241
Apache Snapshots This repository contains snapshot releases from the Apache Software Foundation http://people.apache.org/repo/m2-snapshotrepository Codehaus Snapshots This repository contains snapshot released from Codehaus http://snapshots.repository.codehaus.org/ Maven Central Repository This is the central repository (for releases). http://repo1.maven.org/maven2/ Hosted Repository A hosted repository is a repository which is hosted by Nexus. Maven ships with the following congured hosted repositories: 3rd Party This hosted repository should be used for third-party dependencies not available in the public Maven repositories. Examples of these dependencies could be commercial, proprietary libraries such as an Oracle JDBC driver that may be referenced by your organization. Releases This hosted repository is where your organization will publish internal releases. Snapshots This hosted repository is where your organization will publish internal snapshots. Virtual Repository This serves as an adapter to and from different types of repositories. Currently Nexus supports conversion to and from Maven 1 repositories and Maven 2 repositories.
Ed. 3.0.2

63 / 241
Figure 6.9: Repository Conguration Screen for a Proxy Repository
Ed. 3.0.2

64 / 241
Figure 6.10: Repository Conguration Screen for a Proxy Repository
Figure 6.11: Proxy Conguration Access Settings for a Hosted Repository
Ed. 3.0.2

65 / 241
Figure 6.9 shows the Repository conguration screen for a Proxy repository in Nexus. From this screen, you can manage the settings for proxying an external repository. From this screen, you can congure: Repository ID The repository ID is the identier which will be used in the Nexus URL. For example, the central proxy repository has an ID of "central", this means that maven can access the repository directly at http://localhost:8081/nexus/content/repositories/central. The Repository ID must be unique in a given Nexus installation. ID is required. Repository Name The display name for a repository. Name is required. Repository Type The type of repository (proxy, hosted, or virtual). You cant change the type of a repository, it is selected when you create a repository. Repository Policy If a proxy repository has a policy of release than it will only access released versions from the remote repository. If a proxy repository has a policy of snapshot, it will download snapshots from the remote repository. Default Storage Location Not editable, shown for reference. This is the default storage location for the local cached contents of the repository. Override Storage Location You can choose to override the storage location for a specic repository. You would do this if you were concerned about storage and wanted to put the contents of a specic repository (such as central) in a different location. Remote Repository Access This section tells Nexus where to look for and how to interact with the remote Maven repository being proxied. Remote Storage Location This is the URL of the remote Maven repository. Download Remote Indexes (Not shown in gure) This eld controls the downloading of the remote indexes. Currently only central has an index at http://repo1.maven.org/maven2/.index. If enabled, Nexus will download the index and use that for its searches as well as serve that up to any clients which ask for the index (like m2eclipse). The default for new proxy repositories is enabled, but all of the default repositories included in Nexus have this option disabled. To change this setting for one of the proxy repositories that ship with Nexus, change the option, save the repository, and then re-index the repository. Once this is done, artifact search will return every artifact available on the Maven Central repository. Auto blocking active If Auto blocking active is set to true, Nexus will automatically block a proxy repository if the remote repository becomes unavailable. While a proxy repository is blocked, artifacts will still be served to clients from a local cache, but Nexus will not attempt to locate an artifact in a remote repository. Nexus will periodically retest the remote repository and unblock the repository once it becomes available. File content validation (Not shown in gure) If set to true, Nexus will perform a lightweight check on the content of downloaded les. This will prevent invalid content to be stored and proxied by Nexus, which otherwise can happen in cases where the remote repository (or some proxy between Nexus and the remote repository) for example returns an HTML page instead of the requested le. Checksum Policy Sets the checksum policy for a remote repository. This option is set to Warn by default. The possible values of this setting are: Ignore - Ignore the checksums entirely Warn - Print a warning in the log if a checksum is not correct
Ed. 3.0.2

66 / 241
StrictIfExists - Refuse to cache an artifact if the calculated checksum is inconsistent with a checksum in the repository. Only perform this check if the checksum le is present. Strict - Refuse to cache an artifact if the calculated checksum is inconsistent or if there is no checksum for an artifact. Authentication This section allows you to set a Username, Password, Private Key, Key Passphrase, NT LAN Host, and NT Lan Manager Domain for a remote repository. Access Settings This section congures access settings for a repository. Deployment Policy This setting controls how a Hosted repository allows or disallows artifact deployment. If this policy is set to "Read Only", no deployment is allowed. If this policy is set to "Disable Redeploy", a client can only deploy a particular artifact once and any attempt to redeploy an artifact will result in an error. If this policy is set to "Allow Redeploy", clients can deploy artifacts to this repository and overwrite the same artifact in subsequent deployments. This option is visible for Hosted repositories as shown in Figure 6.11. Allow File Browsing When set to true, users can browse the contents of the repository with a web browser. Include in Search When set to true, this repository is search when you perform an Artifact Search in Nexus. If this setting is false, the contents of the repository are excluded from a search. Publish URL If this property is set to false, the repository will not be published on a URL, and you will not be able to access this repository remotely. You would set this conguration property to false if you want to prevent clients for connecting to this repository directly. Expiration Settings Nexus maintains a local cache of artifacts and metadata, you can congure expiration parameters for a proxy repository. The expiration settings are: Not Found Cache TTL If Nexus fails to locate an artifact, it will cache this result for a given number of minutes. In other words, if Nexus cant nd an artifact in a remote repository, it will not repeated attempt to resolve this artifact until the Not Found Cache TTL time has been exceeded. The default for this setting is 1440 minutes (or 24 hours). Artifact Max Age Tells Nexus when that maximum age of an artifact is before it retrieves a new version from the remote repository. The default for this setting is -1 for a repository with a Release policy and 1440 for a repository with Snapshot policy. Metadata Max Age Nexus retrieves metadata from the remote repository. It will only retrieve updates to metadata after the Metadata Max Age has been exceeded. The default value for this setting is 1440 minutes (or 24 hours). HTTP Request Settings This section lets you change the properties of the HTTP request to the remote repository. In this section you can congure the User Agent of the request, add parameters to a request, and set the timeout and retry behavior. This section refers to the HTTP request made from Nexus to the remote Maven repository being proxied. HTTP Proxy Settings This section lets you congure the HTTP Proxy for the request from Nexus to the remote repository. You can congure a proxy host and port plus an authentication settings you need tell Nexus to use an HTTP Proxy for all requests to a remote repository.
Ed. 3.0.2

67 / 241
6.5.1
Selecting Mirrors for Proxy Repositories
Nexus also allows you to select which mirrors Nexus will consult for a particular Proxy repository. Clicking on the Mirrors tab will show the gure shown in Figure 6.12.
Figure 6.12: Conguring Mirrors for Proxy Repositories To congure a mirror repository, click on the Mirror URL dropdown and select a mirror for the Proxy repository. Click the Add button, and Nexus will then be congured to download artifacts from the selected mirror. Nexus will always download checksums and metadata from the original (or Canonical) URL for a proxy repository. For example, if Nexus is going to download an artifact, it will retrieve the MD5 checksum from the original Maven Central repository and then retrieve the artifact from the selected mirror.
6.5.2
Adding a Mirror Entry for a Hosted Repository
If you are logged in as a user with Administrative privilege, there will be a Mirrors tab available when you are viewing a Hosted repository, clicking on this Mirrors tab will show the form shown in Figure 6.13. This tab contains a list of mirror URLs for this hosted repository. If there are other sites which mirror the contents of this hosted repository, this tab allows you to populate the repository mirror metadata with those URLs.
Ed. 3.0.2

68 / 241
Figure 6.13: Conguring Mirrors for a Hosted Repository This repository mirror metadata can then be consumed by other systems that interact with your hosted repository. For example, if you have a release repository which is used by your customers or by the general public, if one of people consuming your Hosted repository is also running a Nexus, they can congure a Proxy repository that targets your Hosted repository and they can use the mirror metadata to congure their instance of Nexus to consume artifacts from mirrors of your Hosted repository.
6.5.3
Viewing Repository Summary Panel
The Repository Summary panel can be loaded by selecting a Hosted, Proxy, or Virtual repository and then clicking on the Summary tab. When viewing the Summary tab of a Hosted repository, as shown in Figure 6.14, you will also see the Distribution Management settings which can be used to congure Maven to publish artifacts to a Hosted repository.
Ed. 3.0.2

69 / 241
Figure 6.14: Repository Summary Panel for a Hosted Repository The Repository Summary panel for a Proxy repository, as shown in Figure 6.15, contains all of the repository identiers and conguration in addition to the size of the local storage for the proxy repository and the URL of the remote repository.
Ed. 3.0.2

70 / 241
Figure 6.15: Repository Summary Panel for a Proxy Repository The Repository Summary panel for a Virtual repository, as shown in Figure 6.16, displays repository identiers and the size of the Virtual repository on disk.
Figure 6.16: Repository Summary Panel for a Virtual Repository
Ed. 3.0.2

71 / 241
6.5.4
Auto Block/Unblock of Remote Repositories
What happens when Nexus is unable to reach a remote repository? If youve dened a proxy repository, and the remote repository is unavailable Nexus will now automatically block the remote repository. Once a repository has been auto-blocked, Nexus will then periodically retest the remote repository and unblock the repository once it becomes available. You can control this behavior by changing the Auto-blocking Active setting under the Remote Repository Access section of the proxy repository conguration as shown in the following gure:
Figure 6.17: Conguring Remote Repository Auto Block/Unblock
6.6
Managing Groups
Groups are a powerful feature of Nexus, they allow you to combine multiple repositories and other repository groups in a single URL. Nexus ships with two groups: public and public-snapshots. The public group combines the three hosted repositories: 3rd Party, Releases, and Snapshots with the Maven Central repository. The public-snapshots repository combines the Apache Snapshots and Codehaus Snapshots repositories. In Section 4.2 we congured Maven via the settings.xml to look for artifacts in the public group managed by Nexus. Figure 6.18 shows the group conguration screen in Nexus, in this gure you can see the contents of the public
Ed. 3.0.2

72 / 241
Figure 6.18: Group Conguration Screen in Nexus Note that the order of the repositories listed in Order Group Repositories is important. When Nexus searches for an artifact in a group it will return the rst match. To reorder a repository in this list, click and the drag the repositories and groups in the Ordered Group Repositories selection list. The order of repositories or other groups in a group can be used to inuence the effective metadata that will be retrieved by Maven from a Nexus Repository Group. We recommend placing release repositories higher in the list than snapshot repositories so that LATEST and RELEASE versions are merged appropriately. We also recommend placing repositories with a higher probability of matching the majority of artifacts higher in this list. If most of your artifacts are going to be retrieved from the Maven Central Repository, putting Central higher in this list than a smaller, more focused repository is going to be better for performance as Nexus is not going to interrogate the smaller remote repository for as many missing artifacts.
6.7
Managing Routes
Nexus Routes are like lters you can apply to Nexus Groups, they allow you to congure Nexus to include or exclude repositories from a particular artifact search when Nexus is trying to locate an artifact in a Nexus Group. There are a number of different scenarios in which you might congure a route in Nexus, the most common is when you want to make sure that you are retrieving artifacts in a particular group ID from a particular repository. This is especially useful when you want to make sure that you are trying to retrieve your own organizations artifacts from the hosted Release and Snapshot repositories. Nexus Routes are applicable when you are trying to resolve an artifact from a Nexus Group; using Routes allow you to modify the repositories Nexus will consult when it tries to resolve an artifact from a group of repositories.
Ed. 3.0.2

73 / 241
Figure 6.19: Routes Conguration Screen in Nexus Figure 6.19 shows the Route Conguration screen. Clicking on a route will bring up a screen which will allow you to congure the properties of a route. The conguration options available for a route are: URL Pattern This is the pattern which Nexus will use to match a request to Nexus. If the regular expression in this pattern is matched, Nexus will either include or exclude the listed repositories from a particular artifact query. In Figure 6.19 the two patterns are: "./(com|org)/somecompany/." This pattern would match all of the paths which included either "/com/somecompany/" or "/org/somecompany". The expression in the parenthesis matches either com or org, and the ".*" matches one or more characters. You would use a route like this to match your own organizations artifacts and map these requests to the hosted Nexus Releases and Snapshots repositories. "./org/some-oss/." This pattern is used in an exclusive route. It matches every path that contains "/org/some-oss/". This particular exclusive route excludes the local hosted Releases and Snapshots directory for all artifacts which match this path. When Nexus tries to resolve artifacts that match this path, it will exclude the Releases and Snapshots repositories. Rule Type Rule Type can be either "inclusive" or "exclusive". An inclusive rule type denes the set of repositories which should be searched for artifacts when the URL pattern has been matched. An exclusive rule type denes repositories which should not be searched for a particular artifact. Ordered Route Repositories This is an ordered list of repositories which Nexus will search to locate a particular artifact. Nexus searches top to bottom; if its looking for an artifact, it will return the rst match. When Nexus is looking for metadata, all repositories in a group are checked and the results are merged. The merging is applied giving preference to the earlier repositories. This is relevant when a project is looking for a LATEST or a RELEASE version. Within a Nexus Group, you should dene the release repositories before the snapshot repositories, otherwise LATEST may incorrectly resolve to a snapshot version.
Ed. 3.0.2

74 / 241
In this gure you can see the two dummy Routes that Nexus has as default routes. The rst route is an inclusive route, it is provided as an example of a custom route an organization might use to make sure that internally generated artifacts are resolved from the Releases and Snapshots repositories. If your organizations group IDs all start with com.somecompany, and if you deploy internally generated artifacts to the Releases and Snapshots repositories, this Route will make sure that Nexus doesnt waste time trying to resolve these artifacts from public Maven repositories like the Maven Central Repository or the Apache Snapshots repository. The second dummy route is an exclusive route. This route excludes the Releases and Snapshots repositories when the request path contains "/org/some-oss". This example might make more sense if we replaced "some-oss" with "apache" or "codehaus". If the pattern was "/org/apache", this rule is telling Nexus to exclude the internal Releases and Snapshots repositories when it is trying to resolve these dependencies. In other words, dont bother looking for an Apache dependency in your organizations internal repositories. What if there is a conict between two routes? Nexus will process inclusive routes before it will process the exclusive routes. Remember that Nexus Routes only affect Nexus resolution of artifacts when it is searching a Group. When Nexus starts to resolve an artifact from a Nexus Group it will start with the list of repositories in a group. If there are matching inclusive routes, Nexus will then take the intersection of the repositories in the Group and the repositories in the inclusive Nexus Route. The order as dened in the Nexus Group will not be affected by the Inclusive routes. Nexus will then take the result of applying the inclusive routes and apply the exclusive routes to this new group. The resulting list is then searched for a matching artifact. One straightforward use of routes is to create a route that excludes the Maven Central repository from all searches for your own organizations hosted artifacts. If you are deploying your own artifacts to Nexus under a groupId of org.mycompany, and if you are not deploying these artifacts to a public repository, you can create a rule that tells Nexus not to interrogate Central for your own organizations artifacts. This will improve performance because Nexus will not need to communicate with a remote repository when it serves your own organizations artifacts. In addition to the performance benets, excluding Central from searches for your own artifacts will reduce needless queries to the public repositories. To summarize, there are creative possibilities with Routes that the designers of Nexus may not have anticipated, but we advise you to proceed with caution if you start relying on conicting or overlapping Routes. Use Routes sparingly, and use course URL patterns, as Nexus evolves there will be more features which allow for more ne grained rules to allow you to prohibit requests for specic artifacts and specic versions of artifacts. Remember that routes are only applied to Nexus Groups, routes are not used when an artifact is requested from a specic repository.
6.8
Managing Scheduled Tasks
Nexus allows you to schedule tasks that will be applied to all repositories or to specic repositories on a congurable schedule. You can create the following kinds of scheduled tasks: Download Indexes This scheduled task will cause Nexus to download indexes from remote repositories. Empty Trash The Evict and Purge actions do not delete data from the Nexus working directory. They simply move data to be cleared or evicted to a trash directory under the Nexus work directory. This service deletes the data in this trash directory. Evict Unused Proxied Items From Repository Caches Use it or lose it. This scheduled task tells Nexus to get rid of all proxied items which havent been "used" (referenced or retrieved by a client). This can be a good job to run if you are try to conserve storage space. In this service you can specify the number of days over which Nexus will look for activity before making the decision to evict an artifact. (See note about deletion.) Optimize Repository Index To speed up searches in Nexus, this task tells the internal search engine to optimize its index les. This has no affect on the indexes published by Nexus. Typically, this task does not have to run more than once a week. Publish Indexes Just as Maven downloads an index from a remote repository, Nexus can publish an index in the same format. This will make it easier for people using m2eclipse or Nexus to interact with your repositories.
Ed. 3.0.2

75 / 241
Purge Nexus Timeline Nexus maintains a lot of data that relates to the interaction between itself, proxied remote repositories, and clients on Nexus. While this information can be important for purposes of auditing, it can also take up storage space. Using this scheduled task you can tell Nexus to periodically purge this information. (See note about deletion.) Repair Repositories Index In certain cases it might be required to remove the internal index as well as the published ones of a repository. This task does that and then rebuilds the internal index by rst trying to download remote indexes (if a proxy repository), then scanning the local storage and updating the internal index accordingly. Lastly, the index is published for the repository as well. There should be no need to schedule this task. But when upgrading Nexus, the upgrade instructions may sometimes include a manual step of executing this task. Remove Snapshots from Repository Often, you will want to remove snapshots from a snapshot repository to preserve storage space. Note that conguring and running this job is not enough to reclaim disk space. You will also need to congure a scheduled job to empty the trash folder. Files are not deleted by the Remove Snapshots job, they are only moved into the Trash folder. When you create a scheduled task to remove snapshots, you can specify: <itemizedlist> Minimum Snapshots to preserve in a repository - This conguration option allows you to specify a minimum number of SNAPSHOTs to preserve per artifact. For example, if you congured this option with a value of 2, Nexus will always preserve at least two SNAPSHOT artifacts. Snapshot Retention (in days) - This conguration option allows you to specify the number of days to retain SNAPSHOT artifacts. For example, if you want to make sure that you are always keeping the last three days worth of SNAPSHOT artifacts, congure this option with a value of 3. Whether snapshots should be removed if an artifact has been released - If your Nexus repository also contains a release repository, you can congure Nexus to remove all SNAPSHOT artifacts once an artifact has been released.</itemizedlist> Synchronize Shadow Repository This service synchronizes a shadow (or virtual) repository with its master repository. Update Repositories Index If les are deployed directly to a repositorys local storage (not deployed through Nexus), you will need to instruct Nexus to update its index. When executing this task, Nexus will update its index by rst downloading remote indexes (if a proxy repository) and then scan the local storage to index the new les. Lastly, the index is published for the repository as well. Normally, there should be no need to schedule this task. One possible except would be if les are deployed directly to the local storage regularly.
Note The Evict and Purge actions do not delete data from the Nexus working directory. They simply move data to be cleared or evicted to a trash directory under the Nexus work directory. If you want to reclaim disk space, you need to clear the Trash on the Browse Repositories screen. If something goes wrong with a evict of clear service, you can move the data back to the appropriate storage location from the trash. You can also schedule the Empty Trash service to clear this directory on a periodic basis.
When you create a new service you can congure it to apply to all repositories, the repositories in a Nexus Group, or a specic Nexus Repository. A service can be scheduled to run once at a specic date and time, or periodically once every Day, Week, or Month. If none of these options suit your specic needs, you can select a recurrence of "Advanced" which will allow you to supply your own cron expression to specify when the job should execute. To create a new scheduled task, click on Scheduled Tasks under the Administration menu, and click on the Add button. This will bring up the screen shown in Figure 6.20.
Ed. 3.0.2

76 / 241
Figure 6.20: Managing Nexus Scheduled Tasks
6.8.1
Managing Conguration Backups with a Scheduled Task
Nexus Professional includes a scheduled task which allows you to create automated, scheduled backups of your Nexus conguration. This scheduled job will archive the contents of the sonatype-work/nexus/conf directory. Figure 6.21 shows a scheduled conguration backup job congured to backup the contents of the Nexus conguration every day at 12:15 AM.
Ed. 3.0.2

77 / 241
Figure 6.21: Conguring a Scheduled Backup of Nexus Conguration Once a backup has been run, the contents of the backup will be available in sonatype-work/nexus/backup in a series of ZIP archives which include the date and a timestamp.
6.9
Managing Security
Nexus has role-based access control (RBAC) which gives administrators very ne-grained control over who can read from a repository (or a subset of repositories), who can administer the server, and who can deploy to repositories. The security model in Nexus is also so exible as to allow you to specify that only certain users or roles can deploy and manage artifacts in a specic repository under a specic groupId or asset class. The default conguration of Nexus ships with four roles and four users with a standard set of permissions that will make sense for most users. As your security requirements evolve, youll likely need to customize security settings to create protected repositories for multiple departments, or development groups. Nexus provides a security model which can adapt to any scenario. Nexus Role-based access control (RBAC) system is designed around the following four security concepts: Privileges Privileges are rights to read, update, create, or manage resources and perform operations. Nexus ships with a set of core privileges which cannot be modied, and you can create new privileges to allow for ne-grained targeting of role and user permissions for specic repositories. Targets Privileges are usually associated with resources or targets. In the case of Nexus, a target can be a specic repository or a
Ed. 3.0.2

78 / 241
set of repositories grouped in something called a repository target. A target can also be a subset of a repository or a specic asset classes within a repository. Using a target you can apply to a specic privilege to apply to a single groupId. Roles Collections of privileges can be grouped into roles to make it easier to dene collections of privileges common to certain classes of users. For example, deployment users will all have similar sets of permissions. Instead of assigning individual privileges to individual users, you use Roles to make it easier to manage users with similar sets of privileges. A role has one or more privilege and/or one or more roles. Users Users can be assigned roles and privileges, and model the individuals who will be logging into Nexus and read, deploying, or managing repositories.
6.10
Managing Privileges
Nexus has three types of privileges: application privileges which cover actions a user can execute in Nexus, repository target privileges which govern the level of access a user has to a particular repository or repository target, and repository view privileges which control whether a user can view a repository. Behind the scenes, a privilege is related to a single REST operation and method like create, update, delete, read.
Figure 6.22: Managing Security Privileges To create a new privilege, click on the Add. . . button in the Privileges panel and choose Repository Target privilege. Creating a privilege will load the New Repository Target Privilege form shown in Figure 6.23. This form takes a privilege name, a privilege description, the repository to target, and a repository target.
Ed. 3.0.2

79 / 241
Figure 6.23: Managing Security Privileges Once you create a new privilege, it will create four underlying privileges: create, delete, read, and update. The four privileges created by the form in Figure 6.23 are shown in Figure 6.24.
Ed. 3.0.2

80 / 241
Figure 6.24: Create, Delete, Read, and Update Privileges Created
6.11
Managing Repository Targets
A target is a set of regular expressions to match on a path (exactly how the route rules work now). This allows you to dene for example a target called Apache Maven which is "org/apache/maven/.*" You can then add a new privilege that relates to the target and controls the CRUD operations for artifacts matching that path (the privilege can span multiple repositories if you want). You could thus delegate all control of org.apache.maven targets to a "Maven" team. In this way, you dont need to create separate repositories for each logical division of your artifacts.
Ed. 3.0.2

81 / 241
Figure 6.25: Managing Repository Targets
Figure 6.26: Managing Repository Targets
Ed. 3.0.2

82 / 241
6.12
Managing Security Roles
Nexus ships with four roles: Nexus Administrator Role, Nexus Anonymous Role, Nexus Developer Role, and Nexus Deployment Role. Click on the Roles link under Security in the Nexus menu to show the list of roles shown in Figure 6.27.
Figure 6.27: Managing Security Roles To create a new role, click on the Add. . . button and ll out the New Nexus Role form shown in Figure 6.28. When creating a new role, you will need to supply a role identier, a role name, a description, and a session timeout. Roles are comprised of other roles and individual privileges, to assign a role or privilege to a role, click on the role or privilege under Available Roles/Privileges and drag the role or privilege to the Selected Roles/Privileges list.
Ed. 3.0.2

83 / 241
Figure 6.28: Managing Security Roles The built-in roles Nexus Administrator Role, Nexus Anonymous Role, Nexus Deployment Role, and Nexus Developer Role are managed by Nexus and cannot be edited or deleted. Selecting one of these built-in roles will load the form shown in Figure 6.29.
Ed. 3.0.2

84 / 241
Figure 6.29: Managing Security Roles A Nexus role is comprised of other Nexus roles and individual Nexus privileges. To view the component parts of a Nexus Role, select the role in the Roles panel and then choose the Role Tree tab as shown in Figure 6.30.
Ed. 3.0.2

85 / 241
Figure 6.30: Managing Security Roles With the Repository Targets, you have ne grained control over every action in the system. For example you could make a target that includes everything except sources (.(?!-sources)\.) and assign that to one group while giving yet another group access to everything. This means you can host your public and private artifacts in a single repository without giving up control of your private artifacts.
6.13
Managing Users
Nexus ships with three users: admin, anonymous, and deployment. The admin user has all privileges, the anonymous user has read-only privileges, and the deployment user can both read and deploy to repositories. If you need to create users with a more focused set of permissions, you can click on Users under Security in the left-hand navigation menu. Once you see the list of users, you can click on a user to edit that specic users user ID, name, email, or status. You can also assign or revoke specic roles or permissions for a particular user.
Ed. 3.0.2

86 / 241
Figure 6.31: Managing Users A user can be assigned one or more roles which in turn can include references to other Nexus roles or to individual Nexus privileges. To view a tree of assigned Nexus roles and privileges, select the Role Tree for a particular user as shown in Figure 6.32.
Ed. 3.0.2

87 / 241
Figure 6.32: Nexus User Role Tree If you need to nd out exactly how a particular user has been granted a particular privilege, you can use the Privilege Trace pane as shown in Figure 6.33. The Privilege Trace pane lists all of the privileges that have been granted to a particular user. Clicking on a privilege loads a tree of roles that grant that particular privilege to a user. If a user has been assigned a specic privilege by more than one Role or Privilege assignment, you will be able to see this reected in the Role Containment list.
Ed. 3.0.2

88 / 241
Figure 6.33: Nexus User Privilege Trace
6.14
Network Conguration
By default, Nexus listens on port 8081. You can change this port, by changing the value in $NEXUS_HOME/conf/plexus.properties this le is shown in Contents of conf/plexus.properties. To change the port, stop Nexus, change the value of applicationPort in this le, and then restart Nexus. Once you do this, you should see a log statement in $NEXUS_HOME/logs/wrapper.log telling you that Nexus is listening on the altered port. Contents of conf/plexus.properties
applicationPort=8081 runtime=${basedir}/runtime apps=${runtime}/apps work=${runtime/work webapp=${runtime}/apps/nexus/webapp nexus.configuration=${runtime}/apps/nexus/conf/nexus.xml
6.15
Nexus Logging Conguration
You can congure the format and level of logging from within the Nexus interface. To do this, click on Log Conguration under the Administration menu in the left-hand navigation menu. Clicking on this link will display the panel shown in Figure 6.34.
Ed. 3.0.2

89 / 241
Figure 6.34: The Log Conguration Panel From this panel you can congure the following logging conguration properties: Root Logger Level This controls how verbose the Nexus logging will be. If set to DEBUG, Nexus will be very verbose printing all log messages include debugging statements. If set to ERROR, Nexus will be far less verbose only printing out a log statement if Nexus encounters an error. File Appender Pattern This eld controls the format of each log line. This elds format corresponds to the format expected by a Log4J PatternAppender. For more information about this format, refer to the Javadoc for Log4Js PatternAppender. The other conguration parameters: Root Logger Appenders and File Append Location, are not editable in this release of Sonatype Nexus.
6.16
Managing Nexus Plugins
Use the Nexus Plugin Console to list all installed Nexus plugins and browse REST services made available by installed Nexus Plugin. To open the Nexus Plugin Console, click on the Plugin Console link in the Administration section of the Nexus menu as shown in Figure 6.35.
Figure 6.35: Administrative Menu Link for the Plugin Console Once you open the Nexus Plugin Console, you will see a list of plugins installed in your Nexus installation. Clicking on a Nexus plugin in this list will display information about the plugin including: the plugins name, the plugin version, status, a description, SCM information about the plugin, and the URL of the plugins project web site.
Ed. 3.0.2

90 / 241
Figure 6.36: Nexus Plugin Console Once you have selected a plugin from the list of installed plugin, you can browse the available REST interfaces by selecting the REST Services tab as shown in Figure 6.37. Each plugin can contribute one or more REST services to Nexus.
Figure 6.37: Nexus Plugin Console Displaying REST endpoints for a Plugin
Ed. 3.0.2

91 / 241
Chapter 7
Nexus LDAP Integration

Nexus Open Source has a Lightweight Directory Access Protocol (LDAP) Authentication realm which provides Nexus with the capability to authenticate users against an LDAP server. In addition to handling authentication, Nexus can be congured to map Nexus roles to LDAP user is a member of a group that matches the ID of a Nexus role, Nexus will grant that user the matching Nexus Role. In addition to this highly congurable user and group mapping capability, Nexus can augment LDAP group membership with Nexus-specic user-role mapping. Nexus Professional offers LDAP support features for enterprise LDAP deployments including the ability to cache authentication information, support for multiple LDAP servers and backup mirrors, the ability to test user logins, support for common user/group mapping templates, and the ability to support more than one schema across multiple servers.
7.1
Enabling the LDAP Authentication Realm
Authentication realm, you will need to add the Nexus LDAP Authentication Realm to the Selected Realms in the Security section of the Server conguration panel. To load the Server conguration panel, click on the Server link under Administration in the Nexus menu. Once you have the Server conguration panel loaded, select OSS LDAP Authentication Realm in the Available Realms list under the Security section and click the Add button (or Left Arrow) as shown in Figure 7.1.
Figure 7.1: Adding the LDAP Authentication Realm to Available Realms Next, click on the Save button in the Server conguration panel. To make sure that your Nexus instance attempts to authenticate against LDAP rst, click on the OSS LDAP Authentication Realm in the Selected Realms list and drag it to the top of the list as shown in Figure 7.2. This will ensure that Nexus will consult the LDAP Server before it consults the other Authentication Realms.
Ed. 3.0.2

92 / 241
Note Nexus will continue to fall-back to the Xml Authenticating Realm if it cannot authenticate a user against the LDAP server. If your LDAP server is unavailable, and you need to recongure the LDAP connection, you can always login as the default admin
Figure 7.2: Move the LDAP Authentication Realm to the Top of Selected
7.2
Conguring Nexus LDAP Integration
To congure LDAP integration, click on the LDAP Conguration link in the Nexus menu as shown in Figure 7.3. LDAP Conguration is under Security in the Nexus menu.
Figure 7.3: LDAP Conguration Option in the Nexus Menu Clicking on the LDAP Conguration link will load the LDAP Conguration panel as shown in [?informalgure] and [?informalgure]. The following sections outline the conguration options available in the LDAP Conguration Panel.
7.3
Connection and Authentication
The following gure shows Nexus congured to connect to an LDAP server running on localhost port 10389 using the search base of "ou=system". On a more standard installation, you would likely not want to use Simple Authentication as it sends the password in clear text over the network, and you would also use a search base which corresponds to your organizations top-level domain components such as "dc=sonatype,dc=com".
Ed. 3.0.2

93 / 241
Table 7.1 and Table 7.2 contain detailed descriptions of the conguration elds in both the Connection and Authentication sections of the LDAP Conguration panel. Table 7.1: Connection Conguration for LDAP Integration Field Name Protocol Hostname Port Search Base Description Valid values in this dropdown are ldap and ldaps which correspond to the Lightweight Directory Access Protocol and the Lightweight Directory Access Protocol over SSL The hostname or IP address of the LDAP The port on which the LDAP server is listening. Port 389 is the default port for the ldap protocol, and port 636 is the default port for the ldaps The search base is the Distinguished Name (DN) to be appended to the LDAP. The search base usually corresponds to the domain name of an organization. For example, the search base on the Sonatype LDAP server is "dc=sonatype,dc=com"
Ed. 3.0.2

94 / 241
Table 7.2: Authentication Conguration for LDAP Integration Field Name Authentication Method Description Nexus provides four distinct authentication methods to be used when connecting to the LDAP Server: Simple Authentication:: Simple authentication is not recommended for production deployments not using the secure ldaps protocol as it sends a clear-text password over the network. Anonymous Authentication:: Used when Nexus only needs read-only access to non-protected entries and attributes when binding to the LDAP Digest-MD5:: This is an improvement on the CRAM-MD5 authentication method. For more information, see http://www.ietf.org/rfc/rfc2831.txt CRAM-MD5:: The Challenge-Response Authentication Method (CRAM) based on the HMAC-MD5 MAC algorithm. In this authentication method, the server sends a challenge string to the client, the client responds with a username followed by a Hex digest which the server compares to an expected value. For more information, see RFC 2195 For a full discussion of LDAP authentication approaches, see http://www.ietf.org/rfc/rfc2829.txt and http://www.ietf.org/rfc/rfc2251.txt The Simple Authentication and Security Layer (SASL) Realm to connect with. The SASL Realm is only available if the authentication method is Digest-MD5 or CRAM-MD5. Username of an LDAP User to connect (or bind) with. This is a Distinguished Name of a user who has read access to all users and groups Password for an Administrative LDAP User
SASL Realm
Username Password
7.4
User and Group Mapping
The LDAP Conguration panel also contains sections to manage User Element Mapping and Group Element Mapping as shown in [?informalgure].
Ed. 3.0.2

95 / 241
The elds for both the User Element Mapping and Group Element Mapping sections are described in detail in Table 7.3 and Table 7.4. Table 7.3: User Element Mapping Conguration for LDAP Integration Field Name Base DN Description Corresponds to the Base DN containing user entries. This DN is going to be relative to the Search Base which was specied in [?informalgure]. For example, if your users are all contained in "ou=users,dc=sonatype,dc=com" and you specied a Search Base of "dc=sonatype,dc=com" you would use a value of "ou=users" True if there is a tree below the Base DN which can contain user entries. False if all users are contain within the specied Base DN. For example, if all users are in "ou=users,dc=sonatype,dc=com" this eld should be false. If users can appear in organizational units within organizational units such as "ou=development,ou=users,dc=sonatype,dc=com" this eld should be true. This value defaults to inetOrgPerson which is a standard object class dened in RFC 2798. inetOrgPerson contains standard elds such as mail, uid. Other possible values are posixAccount or a custom class. This is the attribute of the Object class which supplies the User ID. Nexus will use this attribute as the Nexus User ID. This is the attribute of the Object class which supplies the real name of the user. Nexus will use this attribute when it needs to display the real name of a user. This is the attribute of the Object class which supplies the email address of the user. Nexus will use this attribute when it needs to send an email to a user. This is the attribute of the Object class which supplies the password of the user. Nexus will use this attribute when it is authenticating a user against an LDAP server.
User Subtree
Object Class
User ID Attribute Real Name Attribute E-Mail Attribute Password Attribute
Ed. 3.0.2

96 / 241
Table 7.3: (continued) Field Name Password Encoding Description Denes the preferred password encoding mechanism to be used when sending password data to the LDAP server.
Table 7.4: Group Element Mapping Conguration for LDAP Integration Field Name Group Type Description Groups are generally one of two types in LDAP systems - static or dynamic. A static group contains a list of users. A dynamic group is where the user contains a list of groups the user belongs to. In LDAP a static group would be captured in an entry with an Object class groupOfUniqueNames which contains one or more uniqueMember attributes. In a dynamic group conguration, each user entry in LDAP contains an attribute which lists group membership. This eld is similar to the Base DN eld described in Table 7.3. This eld is visible if Static Groups is selected. If your groups were dened under "ou=groups,dc=sonatype,dc=com", this eld would have a value of "ou=groups This eld is similar to the User Subtree eld described in Table 7.3. If all groups are dened under the entry dened in Base DN, this eld should be false, if a group can be dened in a tree of organizational units under the Base DN, this eld should be true. This eld is visible if Static Groups is selected. This value defaults to groupOfUniqueNames which is a standard object class dened in RFC 4519 groupOfUniqueNames is simply a collection of references to unique entries in an LDAP directory and can be used to associate user entries with a group. Other possible values are posixGroup or a custom class. This eld is visible if Static Groups is selected. Species the attribute of the Object class which species the Group ID. If the value of this eld corresponds to the ID of a Nexus Role, members of this group will have the corresponding Nexus privileges. Defaults to "cn". This eld is visible if Static Groups is selected. Species the attribute of the Object class which species a member of a group. A groupOfUniqueNames has multiple uniqueMember attributes for each member of a group. Defaults to "uniqueMember". This eld is visible if Static Groups is selected. This eld captures the format of the Group Member Attribute and it is used by Nexus to extract a username from this attribute. For example, if the Group Member Attribute has the format "uid=brian,ou=users,dc=sonatype,dc=com", then the Group Member Format would be "uid=$username,ou=users,dc=sonatype,dc=com". If the Group Member Attribute had the format "brian", then the Group Member Format would be "$username". This eld is visible if Static Groups is selected. When Dynamic Groups is selected, Nexus will inspect an attribute of the user entry to get a list of groups that the user is a member of. In this conguration, a user entry would have an attribute such as memberOf which would contain the name of a group. This eld is visible if Dynamic Groups is selected.
Base DN
Group Subtree
Object Class
Group ID Attribute
Group Member Attribute
Group Member Format
Member of Attribute
If your installation does not use Static Groups, you can congure Nexus LDAP Integration to refer to an attribute on the User entry to derive group membership. To do this, select Dynamic Groups in the Group Type eld in Group Element Mapping. Selecting Dynamic Groups will show a single eld named Member of Attribute as shown in [?informalgure].
Ed. 3.0.2

97 / 241
7.5
Mapping Users and Groups with Active Directory
When mapping users and groups to an Active Directory installation, try the common conguration values listed in Table 7.6 and Table 7.7. Table 7.5: Connection and Authentication Conguration for Active Directory Conguration Element Protocol Hostname Port Search Base Authentication Username Conguration Value ldap Hostname of Active Directory Server 389 (or port of AD server) DC=yourcompany,DC=com (customize for your organization) Simple Authentication CN=Administrator,CN=Users,DC=yourcompany,DC=com
Table 7.6: User Element Mapping Conguration for Active Directory Conguration Element Base DN User Subtree Object Class User ID Attribute Real Name Attribute E-Mail Attribute Password Attribute Password Encoding Conguration Value cn=users false user sAMAccountName cn mail (Not Used) Crypt
Table 7.7: Group Element Mapping Conguration for Active Directory Conguration Element Group Type Member Of Attribute Conguration Value Dynamic Groups memberOf
Ed. 3.0.2

98 / 241
Figure 7.4: Conguring Nexus LDAP for Active Directory
Warning You should connect to the AD through port 3268 if you have a multidomain, distributed Active Directory forest. Connecting directly to port 389 might lead to errors.
7.6
Mapping Users and Groups with posixAccount
When mapping users and groups to LDAP entries of type posixAccount, try the common conguration values listed in Table 7.8 and Table 7.9. Table 7.8: User Element Mapping Conguration for posixAccount Conguration Element Base DN User Subtree Object Class User ID Attribute Real Name Attribute E-Mail Attribute Password Attribute Password Encoding Conguration Value (Not Standard) false posixAccount sAMAccountName uid mail (Not Used) (Not Used)
Ed. 3.0.2

99 / 241
Table 7.9: Group Element Mapping Conguration for posixGroup Conguration Element Group Type Base DN Group Subtree Object Class Group ID Attribute Group Member Attribute Group Member Format Conguration Value Static Groups (Not Standard) false posixGroup cn memberUid
7.7
Mapping Roles to LDAP Users
Once User and Group Mapping has been congured, you can start verifying how LDAP users and groups are mapped to Nexus Roles. If a user is a member of an LDAP group that has a Group ID corresponding to the ID of a Nexus Role, that user is granted the appropriate permissions in Nexus. For example, if the LDAP user entry in "uid=brian,ou=users,dc=sonatype,dc=com" is a member of a groupOfUniqueNames attribute value of admin, when this user logs into Nexus, it will be granted the Nexus Administrator Role if Group Element Mapping is congured properly. To verify the User Element Mapping and Group Element Mapping, click on Check User Mapping in the LDAP Conguration panel directly below the Group Element Mapping section, Figure 7.5 shows the results of this check.
Figure 7.5: Checking the User and Group Mapping in LDAP Conguration
Ed. 3.0.2

100 / 241
In Figure 7.5, Nexus LDAP Integration locates a user with a User ID of "brian" who is a member of the "admin" group. When brian logs in, he will have all of the rights that the admin Nexus Role has.
7.8
Mapping Nexus Roles for External Users
If you are unable to map all of the Nexus roles to LDAP groups, you can always augment the Role information by adding a specic user-role mapping for an external LDAP user in Nexus. In other words, if you need to make sure that a specic user in LDAP gets a specic Nexus role and you dont want to model this as a group membership, you can add a role mapping for an external user in Nexus. Nexus will keep track of this association independent of your LDAP server. Nexus continues to delegate authentication to the LDAP server for this user, Nexus will continue to map the user to Nexus roles based on the group element mapping you have congured, but Nexus will also add any roles specied in the User panel. You are augmenting the role information that Nexus gathers from the group element mapping. Once the User and Group Mapping has been congured, click on the Users link under Security in the Nexus menu. The Users tab is going to contain all of the "congured" users for this Nexus instance as shown in Figure 7.6. A congured user is a user in a Nexus-managed Realm or an External User which has an explicit mapping to a Nexus role. In Figure 7.6, you can see the three default users in the Nexus-managed default realm plus the brian user from LDAP. The brian user appears because this user has been mapped to a Nexus role.
Figure 7.6: Viewing All Congured Users The list of users in Figure 7.6 is a combination of all of the users in the Nexus default realm and all of the External Users with role mappings. To explore these two sets of users, click on the All Congured Users dropdown and choose "Default Realm Users". Once you select this, click in the search eld and press Enter. Searching with a blank string in the Users panel will return all of the users of the selected type. In Figure 7.7 you see a dialog containing all three default users from the Nexus default realm.
Ed. 3.0.2

101 / 241
Figure 7.7: All Default Realm Users If you wanted to see a list of all LDAP users, select "LDAP" from the "All Congured Users" dropdown shown in Figure 7.6 and click on the search button (magnifying glass) with an empty search eld. Clicking search with an empty search eld will return all of the LDAP users as shown in Figure 7.8.
Note Note that the user "tobrien" does not show up in the "All Congured Users" list. This is by design. Nexus is only going to show you information about users with external role mappings. If an organization has an LDAP directory with thousands of developers, Nexus doesnt need to retain any conguration information for users that dont have custom Nexus role mappings.
Figure 7.8: All LDAP Users To add a mapping for an external LDAP user, you would click on the "All Congured Users" dropdown and select LDAP. Once youve selected LDAP, type in the user ID you are searching for and click the search button (magnifying glass icon to right of the search eld). In Figure 7.9, a search for "brian" yields one user from the LDAP server.
Ed. 3.0.2

102 / 241
Figure 7.9: Search LDAP Users To add a Nexus role mapping for the external user "brian" shown in Figure 7.9, click on the user in the results table and drag a role from Available Roles to Selected Roles as shown in Figure 7.10. In this case, the user "brian" is mapped to the Administrative group by virtue of his membership in an "admin" group in the LDAP server. In this use case, a Nexus administrator would like to grant Brian the Deployment Role without having to create a LDAP group for this role and modifying his group memberships in LDAP
Figure 7.10: Mapping the Deployment Role to an External User
Ed. 3.0.2

103 / 241
The end result of this operation is to augment the Group-Role mapping that is provided by the LDAP integration. You can use LDAP groups to manage coarse-grained permissions to grant people administrative privileges and developer roles, and if you need to perform more targeted privilege assignments in Nexus you can Map LDAP users to Nexus roles with the techniques shown in this section.
7.9
Mapping External Roles to Nexus Roles
Nexus makes it very straightforward to map an external role to an internal Nexus role. This is something you would do, if you want to grant every member of an externally managed group (such as an LDAP group) a certain privilege in Nexus. For example, assume that you have a group in LDAP named "svn" and you want to make sure that everyone in the "svn" group has Nexus Administrative privileges. To do this, you would click on the Add.. dropdown in the Role panel as shown in Figure 7.11. This dropdown can be found in the Role management panel which is opened by clicking on Roles in the Security menu.
Figure 7.11: Selecting External Role Mapping in the Role Management Panel Selecting External Role Mapping under Add. . . will show you a dialog which contains a dropdown of External Realms. Selecting an external realm such as LDAP will then bring up a list of roles managed by that external realm. The dialog shown in Figure 7.12 shows the external realm LDAP selected and the role "svn" being selected to map to a Nexus role.
Ed. 3.0.2

104 / 241
Figure 7.12: Selecting an Externally Managed Role to Map to a Nexus Role Once the external role has been selected, Nexus will create a corresponding Nexus Role. You can then assign other Roles to this new externally mapped Role. Figure 7.13 shows that the SVN role from LDAP is being assigned the Nexus Administrator Role. This means that any user that is authenticated against the external LDAP Realm who is a member of the svn LDAP group will be assigned a Nexus role that maps to the Nexus Administrator Role.
Ed. 3.0.2

105 / 241
Figure 7.13: Mapping an External Role to a Nexus Role
7.10
Enterprise LDAP Support
The following sections outline Enterprise LDAP features which are available in Nexus Professional. Enterprise LDAP Fail-over Support When an LDAP server fails, the applications authenticating against it can also become unavailable. Because a central LDAP server is such a critical resource, many large software enterprises will install a series of primary and secondary LDAP servers to make sure that the organization can continue to operate in the case of an unforeseen failure. Nexus Professionals Enterprise LDAP plugin now provides you with the ability to dene multiple LDAP servers for authentication. To congure multiple LDAP servers, click on Enterprise LDAP under Security in the Nexus application menu. You should see the Enterprise LDAP panel shown in the following gure.
Ed. 3.0.2

106 / 241
Figure 7.14: Dening Multiple LDAP Servers in Nexus Professional You can use the Backup Mirror setting for an LDAP repository. This backup mirror is another LDAP server which will be consulted if the original LDAP server cannot be reached. Nexus Professional assumes that the backup mirror is a carbon copy of the original LDAP server, and it will use the same user and group mapping conguration as the original LDAP server. Instead of using the backup mirror settings, you could also dene multiple LDAP backup mirrors in the list of congured LDAP servers shown in the previous gure. When you congure more than one LDAP server, Nexus Professional will consult the servers in the order they are listed in this panel. If Nexus cant authenticate against the rst LDAP server, Nexus Professional will move on to the next LDAP server until it either reaches the end of the list or nds an LDAP server to authenticate against.
Figure 7.15: Use Multiple LDAP Servers in a Fail-over Scenario
Ed. 3.0.2

107 / 241
The feature just described is one way to increase the reliability of your Nexus instance. In the previous case, both servers would have the same user and group information. The secondary would be a mirror of the primary. But, what if you wanted to connect to two LDAP servers that contained different data? Nexus Professional also provides. . .
7.10.1
Support for Multiple Servers and LDAP Schemas
The same ability to list more than one LDAP server also allows you to support multiple LDAP servers which may or may not contain the same user authentication information. Assume that you had an LDAP server for the larger organization which contained all of the user information across all of the departments. Now assume that your own department maintains a separate LDAP server which you use to supplement this larger LDAP installation. Maybe your department needs to create new users that are not a part of the larger organization, or maybe you have to support the integration of two separate LDAP servers that use different schema on each server. A third possibility is that you need to support authentication against different schema within the same LDAP server. This is a common scenario for companies which have merged and whose infrastructures has not yet been merged. To support multiple servers with different user/group mappings or to support a single server with multiple user/group mappings, you can congure these servers in the Enterprise LDAP panel shown above. Nexus will iterate through each LDAP server until it can successfully authenticate a user against an LDAP server.
Figure 7.16: Supporting Multiple LDAP Schemas with Nexus Professional
7.10.2
Enterprise LDAP Performance Caching and Timeout
If you are constantly authenticating against a large LDAP server, you may start to notice a signicant performance degradation. With Nexus Professional you can cache authentication information from LDAP. To congure caching, create a new server in the Enterprise LDAP panel, and scroll to the bottom of the Connect tab. You should see the following input eld which contains the number of seconds to cache the results of LDAP queries.
Figure 7.17: Setting the LDAP Query Cache Duration (in Seconds) You will also see options to alter the connection timeout and retry interval for an LDAP server. If you are conguring a number of different LDAP servers with different user and group mappings, you will want to make sure that youve congured low timeouts for LDAP servers at the beginning of your Enterprise LDAP server list. If you do this properly, it will take Nexus next to no time to iterate through the list of congured LDAP servers.
Ed. 3.0.2

108 / 241
Figure 7.18: Setting the LDAP Connection Timeout (in Seconds) We improved the overall caching in this release. The cache duration is congurable and applies to authentication and authorization, which translates into pure speed! Once youve congured LDAP caching in Nexus Professional, authentication and other operations that involve permissions and credentials once retrieved from an external server will run in no time.
7.10.3
User and Group Templates
If you are conguring your Nexus Professional instance to connect to an LDAP server there is a very good chance that your server follows one of several, well-established standards. Nexus Professionals LDAP server conguration includes these widely used user and group mapping templates which great simplify the setup and conguration of a new LDAP server. To congure user and group mapping using a template, select a LDAP server from the Enterprise LDAP panel, and choose the User and Group Settings. You will see a User & Group Templates section as shown in the following gure.
Figure 7.19: Using User & Group Mapping Templates
7.10.4
Testing a User Login
Nexus Professional provides you with the ability to test a user login directly. To test a user login, go to the User and Group Settings tab for a server listed in the Enterprise LDAP panel. Scroll to the bottom of the form, and you should see a button named "Check Login".
Figure 7.20: Testing a User Login If you click on Check Login, you will then be presented with the login credentials dialog shown below. You can use this dialog to login as an LDAP user and test the user and group mapping conguration for a particular server. This feature allows you to test user and group mapping conguration directly. This feature allows you to quickly diagnose and address difcult authentication and access control issues via the administrative interface.
Ed. 3.0.2

109 / 241
Figure 7.21: Supply a Users Login Credentials
Ed. 3.0.2

110 / 241
Chapter 8
Nexus Procurement Suite

8.1 Introduction
Nexus Procurement Suite provides an organization with control over what artifacts are allowed into a repository from an external, proxied repository such as the Maven Central Repository. Such control can be a prerequisite for organizations unwilling or unable to trust the entire contents of an external public repository. If an organization is developing mission critical code, they will likely want to subject every third party dependency to intense scrutiny and testing before making an artifact available to build a release or support a team of developers. In most Enterprise development environments, a developer cant just decide to add in a new dependency to Hibernate or to the Spring Framework on a whim; the decision to add dependencies to third-party libraries will need to be funneled through an oversight process that relies on an architect or an administrator to promote artifacts to a certied release repository. Another, more common experience is an organization which needs to proxy something like the Maven Central Repository but wants to limit access to specic versions of artifacts or prevent dependencies on everything contained under a specic group. Some organizations are more amenable to trusting the contents of a remote, proxied repository like Central, but they also need the ability to block certain dependencies. Maybe you work on a team that needs to limit access to dependencies with a certain license, or maybe you just want to make sure no one uses a problematic version of Hibernate with a known bug? The procurement suite is the tool that provides for both coarse and ne-grained control of the artifacts that can appear in a repository.
8.2
The Stages of Procurement
A procured repository is a Hosted Repository which procures artifacts from a Proxy Repository. For example, one could create a hosted repository named "Secured Maven Central" and then congure this hosted repository to procure artifacts from the "Maven Central" repository. Once the hosted repository has been created and the source of procurement has been congured, the repository will obtain artifacts from the proxy repository as long as procurement is activated. If you start procurement for a Hosted repository, the hosted repository will fetch artifacts from the Proxy repository specied in the procurement settings. If you stop procurement for a Hosted Repository, no additional artifacts will be retrieved from the Proxy repository specied in the procurement settings. The ability to enable or disable procurement for a Hosted repository comes in very handy when you want to "certify" a Hosted repository as containing all of the artifacts (no more and no less) required for a production build. You can start procurement, run a build which triggers artifact procurement, and then stop procurement knowing that the procured repository now contains all of the artifacts required for building a specic project. Stopping procurement assures you that the contents of the repository will not change if the third-party, external proxied repository does. This is an extra level of assurance that your release artifacts depend on a set of artifacts under your complete control.
Ed. 3.0.2

111 / 241
8.3
Two Approaches to Procurement
There are two main use cases for the Procurement Suite. In the rst use case, the Procured Release Repository, the Procurement features of Nexus Professional are used to create a procured release repository to make sure that the organization has full control over the artifacts that are making it into a production release. The other use case, the Procured Development Repository, is for organizations that need more up-front control over which artifacts are allowed during the development of a project. The following sections describe these two uses cases in more detail. === Procured Release Repository The Procurement Suite can be used in two different ways. In the "Procured Release" mode, developers work with a proxied 3rd party repository exactly as they would without the Procurement Suite. When a developer needs to add a dependency on a new artifact, Nexus will retrieve the artifact from the third-party repository (like Central or Apache Snapshots) and this artifact will be served to Maven via a proxied Nexus repository. When a QA or Release engineer needs to build a release or staging artifact, the Release or QA build would be congured to execute against a procured repository. A procured repository is one which only serves the artifacts which have been explicitly approved using the Procurement Suite.
Figure 8.1: Procurement to a Certied Release Repository In this model, developers can add as many third-party dependencies as they want, and it is the responsibility of the QA and Release engineers to approve (or procure) artifacts from the Development Repository to the QA/Release Repository. Developers can move forward, adding dependencies freely from a third-party, proxied repository, but once it is time to populate a Release repository, a Nexus administrator can audit the required artifacts, create a hosted repository, turn on procurement, populate the repository, and then deactivate procurement. This has the effect of "locking down" the artifacts that are involved in a production release.
8.4
Procured Development Repository
There are some development environments which require even more control over which artifacts can be used and referenced by developers. In these situations, it might make sense to only allow developers to work with a procured repository. In this mode, a developer must ask a Nexus administrator for permission to add a dependency on a particular third-party artifact. A Procurement Manager would then have to approve the artifact, or group of artifacts so that they would be made available to the developers. This is the "ask-rst" model for organizations that want to control which artifacts make it into the development cycle.
Figure 8.2: Procurement to a Certied Development Repository This is a model common in industries that have strict oversight requirements. More often than not, banks, hospitals, and government agencies have fairly strict regulations on the software that can be used by large development teams. With the Procured Development Repository approach, an architecture group can have full control over what artifacts can be referenced by a large development team.
Ed. 3.0.2

112 / 241
8.5
Installing the Procurement Suite
If you installed Nexus Professional, the Nexus Procurement Suite is already installed. Just start Nexus and look for the Artifact Procurement option in the left-hand navigation menu of the Nexus interface. If you see the Artifact Procurement link as shown in Figure 8.3, the Procurement Suite is available and ready to be congured.
Figure 8.3: Artifact Procurement in the Nexus Menu
8.6
Setting up a Procured Repository
This section will walk through the process of creating and conguring a hosted repository named "Procured Central" which will be procured from the "Maven Central" proxy repository. Setting up a procured repository consists of the following steps: Enabling Remote Index Downloads for a Proxy Repository Creating a Hosted Repository to be Procured Conguring Procurement for the Hosted Repository Conguring Procurement Rules Before conguring a procured repository, you need to make sure that you have enabled Remote Index downloading for the proxied repository that will serve as the source for your procured repository.
Note If you are attempting to procure artifacts from a remote repository which does not have a repository index, you can still use the procurement suite. Without a remote repository index, you will need to congure procurement rules manually without the benet of the already populated repository tree shown in Section 8.12.
8.7
Enable Remote Index Downloads
When you congure procurement rules for a hosted repository, the administrative interface displays the repository as a tree of groups and artifacts populated from the Remote Repositorys Nexus Index. Nexus ships with a set of proxy repositories, but remote index downloading is disabled by default. To use procurement, you will need to tell Nexus to download the remote indexes for a proxy repository. Click on "Repositories" under Views/Repositories in the Nexus menu, then click on the Maven Central repository in the list of repositories. Click on the Conguration tab, locate Download Remote Indexes, and switch this option to "True" as shown in Figure 8.4.
Ed. 3.0.2

113 / 241
Figure 8.4: Enabling Remote Index Downloads for a Proxy Repository Click on the Save button in the dialog shown in Figure 8.4. Right-click on the Index in the Repositories list and select "ReIndex". Nexus will then download the remote repository and recreate the index for any Repository Groups that contain this proxied repository. Nexus may take a few minutes to download the remote index for a large repository. Depending on your connection to the Internet, this process can take anywhere from under a minute to a few minutes. The size of the remote index for Maven Central is on the order of 30 MB. To check on the status of the remote index download, click on System Feeds under Views in the Nexus menu. Click on the last feed to see a list of "System Changes in Nexus". If you see a log entry like the one highlighted in Figure 8.5, Nexus has successfully downloaded the Remote Index from Maven Central.
Ed. 3.0.2

114 / 241
Figure 8.5: Verication that the Remote Index has been Downloaded
8.8
Create a Hosted Repository
When you congure procurement you are establishing a relationship between a Proxy repository and a Hosted repository. To create a Hosted repository, select Repositories from the Administration section of the Nexus menu, and click on the Add button selecting Hosted as shown in Figure 8.6.
Ed. 3.0.2

115 / 241
Figure 8.6: Adding a Hosted Repository Selecting Hosted will then load the Repository Cong form shown in Figure 8.7. Create a repository with a Repository ID of "secured" and a name of "Secured". Make the release policy "Release". Click the <guibutton>Save button to create the new Hosted Repository.
Ed. 3.0.2

116 / 241
Figure 8.7: Adding the "Secured" Hosted Repository
8.9
Conguring Procurement for Hosted Repository
At this point, the list of Repositories will have a new Hosted repository named "Secured". The next step is to start procurement for the new Secured repository. When you do this, you are establishing a relationship between the new Hosted repository and a Proxy repository. In this case, were conguring procurement for the Secured repository and were telling the Procurement Suite to procure artifacts from the Maven Central proxy repository. To congure this relationship and to start procurement, click on Artifact Procurement under the Enterprise menu. In the Procurement panel, click on Add Procurement Repository as shown in Figure 8.8.
Ed. 3.0.2

117 / 241
Figure 8.8: Adding a Procured Repository You will then be presented with the Start Procurement dialog as shown in Figure 8.9. Select the "Maven Central" proxy repository from the list of available Source repositories.
Figure 8.9: Conguring Procurement for a Hosted Repository Procurement is now congured and started, if you are using an instance of Nexus installed on localhost port 8081, you can congure your clients to reference the new Secured repository at http://localhost:8081/nexus/content/repositories/secured By default, all artifacts are denied and without further customization of the procurement rules no artifacts will be available in the new Secured repository. One interesting thing to note about the "Secured" repository is that the Repository Type changed, once procurement was started. When procurement is activate for a Hosted repository, the repository will show up in the Nexus interface as a Proxy repository. Click refresh in the Repositories list, and look at the Secured repository in the list of repositories, you will see that the repository type column contains "proxy" as shown in Figure 8.10. When procurement is started for a hosted repository it is effectively a proxy repository, and when it is stopped it will revert back to being a normal hosted repository.
Ed. 3.0.2

118 / 241
Figure 8.10: Hosted Repository is a Proxy Repository while Procurement is Active
8.10
Procured Repository Administration
Once youve dened the relationship between a Hosted repository and a Proxy repository and you have started procurement, you can start dening the rules which will control which artifacts are allowed in a procured repository and which artifacts are denied. You can also start and stop procurement. This section details some of the administration panels and features which are available for a procured repository.
8.11
Viewing the Procurement Management Interface
A procurement rule is a rule to allow or deny the procurement of a group, artifact, or a collection of groups or artifacts. You load the Artifact Procurement interface by selecting Artifact Procurement under the Enterprise section of the Nexus menu. Clicking on this link will load a list of procured repositories. Clicking on the repository will load the entire repository in a tree as shown in Figure 8.11. This section will illustrate the steps required for blocking access to an entire artifact and then selectively allowing access to a particular version of that same artifact. This is a common use-case in organizations which want to standardize on specic versions of a particular dependency.
Note If you are attempting to procure artifacts from a remote repository which does not have a repository index, you can still use the procurement suite. Without a remote repository index, you will need to congure procurement rules manually without the benet of the already populated repository tree shown in this section.
Ed. 3.0.2

119 / 241
Figure 8.11: Viewing a Repository in the Artifact Procurement Interface The directory tree in Figure 8.11 is the index of the proxy repository from which artifacts are being procured.
8.12
Conguring a Procurement Rule
To congure a procurement rule, right click on a folder in the tree. Figure 8.12 displays the procurement interface after right clicking on the jython artifact folder. In this dialog, we are telling the procurement interface to deny everything in the jython group and its sub-groups. If you attempt to retrieve any version under the jython artifact after this rule is created, the Procurement Suite will prevent access to this artifact. For example, if you attempt to build a project that depends on jython:jython:2.1, it will not be made available via the Secured repository created in Section 8.6.
Ed. 3.0.2

120 / 241
Figure 8.12: Denying Procurement for Everything Under a Group After denying access to the entire jython artifact, right-click on the 2.1 version folder under the jython artifact folder. Select "Exactly the artifact" as shown in Figure 8.13 to allow for the procurement of only the 2.1 version. This has the effect of creating a specic rule which allows the procurement of a single version of the jython:jython artifact.
Ed. 3.0.2

121 / 241
Figure 8.13: Allowing Access to a Single Artifact in a Denied Group After allowing this element, your procurement tree is going to contain red and green markers on the affected folders as shown in Figure 8.14. While the jython artifact folder has a red slash through it the 2.1 version folder has a green check. You have congured the Procurement Suite to deny access to all versions of the jython artifact except version 2.1.
Ed. 3.0.2

122 / 241
Figure 8.14: Viewing the Effect of Composite Procurement Rules on the Tree
8.13
Managing Procurement Rules
Once youve created a set of procurement rules you are going to want to know how to view the procurement rules which are applicable to a particular node. Procurement rules will frequently overlap; for example, in Section 8.10, there are two rules: one rule applies to all of the versions (folder) below the jython artifact folder, and the other rule applies to a particular version directory. Since rules can overlap, Nexus provides a simple way to list and manage the rules which apply to a specic node in the directory tree. Figure 8.14 shows the resolved procurement rules after clicking on the Jython 2.1 version artifact from Section 8.6.
Ed. 3.0.2

123 / 241
Figure 8.15: Effective Procurement Rules for a Particular Node This dialog gives the procurement administrator a ne-grained view into the rules that apply to a particular node. From this dialog you can remove rules which apply to a specic node.
8.14
Stopping Procurement
Some organizations may want to "lock down" the artifacts that a release build can depend upon, and it is also a good idea to make sure that your build isnt going to be affected by changes to a repository not under you control. A procurement administrator might congure a procured repository, start procurement, and run an enterprise build against the repository to populate the procured, hosted repository with all of the necessary artifacts. After this process, the procurement administrator can stop procurement and continue to run the same release build against the hosted repository which now contains all of the procured artifacts. To stop procurement, go to the Artifact Procurement management interface by clicking on Artifact Procurement under the Enterprise section of the Nexus menu. Right click on the repository and choose Stop Procurement as shown in Figure 8.16.
Ed. 3.0.2

124 / 241
Figure 8.16: Stopping Procurement for a Procured Repository After choosing Stop Procurement, you will then see a dialog conrming your decision to stop procurement as shown in Figure 8.17.
Figure 8.17: Stop Procurement Conrmation Dialog Once procurement is stopped, the Secure repository will revert back to being a plain-old Hosted repository. You can validate this by looking at the repository type in the list of repositories.
Ed. 3.0.2

125 / 241
Chapter 9
Build Promotion with the Nexus Staging Suite

9.1 Introduction
If you release software, you will often need to test a release before deploying it to a production system or an externally accessible repository. For example, if you are developing a large, enterprise web application you may want to stage a release candidate to a production system and perform a series of rigorous tests before a release manager makes a decision to either return a system to development or deploy a system to production. The Nexus Staging Suite in Nexus Professional allows an organization to create a temporary staging repository and to manage the promotion of artifacts from a staging repository to a release repository. This ability to create an isolated, release candidate repository that can discarded or promoted makes it possible to support the decisions that go into certifying a release.
9.2
Releasing Software with a Staging Repository
Without the Staging Suite, when a developer deploys an artifact to a Hosted repository such as the Release repository, this artifact is published to a hosted repository and is immediately made available - there is no oversight, there is no approval or certication process. There is no chance to test the artifact before writing the artifact to a hosted repository. If there is a mistake in the release, often the only option available is to republish the artifacts to the release repository or deploy a new version of the artifacts.
Figure 9.1: Without the Nexus Staging Suite While this is acceptable for some users, organizations and enterprises with a QA cycle often need a temporary staging repository for potential release candidates: a staging repository. With the Nexus Staging Suite, an organization can automatically stage releases to a temporary repository which can then be used to test and certify a set of artifacts before they are published to a nal release repository. This temporary repository can then be promoted as a whole or dropped depending on the results of testing.
9.3
How the Staging Suite Works
Heres how staging works in Nexus Professional:
Ed. 3.0.2

126 / 241
1. A developer deploys an artifact (or a set of artifacts) to Nexus Professional. 2. The Staging Suite intercepts this deployment and matches the artifacts path against a set of Staging Proles. 3. If the path of the artifact activates a staging prole, a temporary staging repository is created and the artifacts are deployed to this repository. 4. Once the developer has deployed a set of artifacts to Nexus, they will then "Close" the staging repository. 5. The Staging Suite will then add this temporary staging repository to one or more Target Repository Groups. Once the staging repository is closed, and the staging repository has been added to a Target repository group, the artifacts in the staging repository are then made available to developers or testers via a repository group. Tests can be performed on the artifacts as if they were already published in a hosted repository. From this point, one of two things can happen to a staging repository: Release A Nexus user can "release" a staging repository and select a hosted repository to publish artifacts to. Releasing the contents of a repository publishes all artifacts from the staging repository to a hosted repository and deletes the temporary staging repository. Drop A Nexus user can "drop" a staging repository. Dropping a staging repository will remove it from any groups and delete the temporary staging repository. Promote If your Nexus installation contains Build Promotion proles, you will also see an option to "promote" a staging repository to a Build Promotion Group. When you promote a staging repository you can expose the contents of that staging repository via additional groups. Build Promotion proles are explained in detail in the next section.
Figure 9.2: With Nexus Staging Suite
Figure 9.3: Supplying a Description for a Staging Release
9.4
Multi-level Staging and Build Promotion
Nexus Professional also supports multi-level staging and build promotion. With multi-level staging, a staging repository can be tested and then promoted to a separate "build promotion" prole and exposed through different repository groups to allow for additional testing and qualication before a nal release. Figure 9.4 illustrates a potential use for multi-level staging:
Ed. 3.0.2

127 / 241
Stage: A developer publishes artifacts to a QA staging prole which exposes the staged artifacts in a QA repository group used by an internal quality assurance team for testing. Promote to Beta: Once the QA team has successfully completed testing, they promote the temporary staging repository to build promotion prole which will expose the staged artifacts to a limited set of customers who have agreed to act as a beta testers for a new feature. Release: Once this closed beta testing period is nished, the staged repository is then released and the artifacts it contains are published to a hosted release repository and exposed via the public repository group.
Figure 9.4: Multi-level Staging and Build Promotion To support this multi-level staging feature, you can congure Build Promotion proles as detailed in Section 9.9. Once you have promoted a Staging Repository to a Build Promotion prole, you can drop, promote, or release the artifacts it contains as detailed in Section 9.5.
9.5
Using the Nexus Staging Suite
To use the Staging Suite in Nexus Professional, start Nexus and look for the Staging Proles, Staging Repositories, Staging Rulesets, and Staging Upload options in the left-hand navigation menu of the Nexus interface. If you see the links shown in Figure 9.5, the Staging Suite is available and ready to be congured.
Ed. 3.0.2

128 / 241
Figure 9.5: Enterprise Menu after Staging Suite Installation
9.6
Conguring Staging Proles
Staging Proles dene the rules by which artifact deployments are staged in Staging Repositories. Staging Repositories are created as they are needed and are the primary mechanism by which Nexus users can promote or discard the contents of a staging repository to a hosted repository. A staging prole uses a Repository Target to match artifacts as they are deployed. If a matching artifact is deployed to Nexus, the Staging Suite will intercept this deployment and store the artifact in a staging repository. The process for conguring a new Staging Prole is as follows: 1. Congure a Repository Target to match artifacts under the groupId you will be deploying artifacts to. If you are releasing all of your software under the groupId com.example, you would congure a target that matches the pattern "./com/example/.". 2. Create a new Staging Prole using the target dened in the previous step. When you congure this staging prole, you will be dening a target repository group. When the Staging Suite intercepts an artifact and places it in a staging repository, this staging repository will be added to the specied target repository group. 3. Assign the appropriate Staging-specic roles to the appropriate users. When you create a Staging Prole, Nexus also creates two new roles that grant access and privileges to the repositories created by this Staging Prole. The following sections provide a more detailed look at the process of conguring a single staging prole in Nexus Professional.
9.7
Conguring a Repository Target
The Staging Suite intercepts deployments to repository targets. For example, if you wanted to intercept all deployments to the com.sonatype.sample groupId, you would create a Repository Target called the "Sample Target" with a pattern expression of "<varname>./com/sonatype/sample/.". Do this by clicking on "Repository Targets" in the "Security" section of the left-hand navigation menu in Nexus and then clicking on the <guibutton>Add
Ed. 3.0.2

129 / 241
Figure 9.6: Adding a Repository Target for com.sonatype.sample
9.8
Conguring Staging Proles
Staging proles control the process by which artifacts are selected for staging. When you dene a Staging prole, you are dening a set of rules which will control the way in which Nexus intercepts an artifact deployment. When you click on Staging Proles in the Nexus menu, you will see a list of congured staging proles. Clicking on Add. . . will display the dropdown menu shown in Figure 9.7.
Figure 9.7: Multi-level Staging and Build Promotion Selecting Staging Prole will create a new Staging Prole and display the form shown in Figure 9.8. Figure 9.8 denes a Staging Prole using the Repository Target congured in Section 9.7. This target will match all artifacts under the com.sonatype.sample groupId (or the com/sonatype/sample repository path). This staging prole uses the "Maven2
Ed. 3.0.2

130 / 241
(hosted, release)" as a template for newly created temporary staging repositories, and it will automatically add closed staging repositories to the Public Repositories group.
Figure 9.8: Editing a Staging Prole This form allows you to congure a prole. Every prole has a name, is associated with a Repository Target, and points to a template to use when creating a new staging repository. The Staging Prole conguration panel contains the following elds: Prole Name The Name of the Staging Prole. This can be an arbitrary value. It is simply a convenience for the Nexus Administrator, and it is also used to create Nexus roles that are used to grant permissions to view and manipulate staging repositories created by this prole. Staging Mode This eld contains the options "Deploy", "UI Upload", and "Deploy and UI Upload". This controls how artifacts can be staged to this staging prole. If Deploy is selected, artifacts can only be deployed using Maven to upload build artifacts. If UI Upload is selected, users can upload artifacts to Nexus using the Nexus user interface. Template Denes a template for the temporary staging repository. The current version of Nexus Professional provides with the options "Maven2 (hosted, release)" and "Maven1 (hosted, release)". Repository Target This is a reference to the target which we dened in Section 9.7. When a developer deploys an artifact to the Staging URL, the Staging Suite will check to see if the artifact matches the patterns dened in the Repository Target. The Target denes the "trigger" for the creation of a Staging Repository. Release Repository Staged artifacts are stored in a temporary staging repository which is made available via Target Groups. Once a staged
Ed. 3.0.2

131 / 241
deployment has been successfully tested, artifacts contained in the temporary staging repository are promoted to a hosted repository. The Release Repository setting congures the target release repository for this staging prole. Content Type Nexus can create staging repositories for repositories of type maven1, maven2, and Eclipse P2 repositories. This value is automatically selected based on the chosen template. This chapter only deals with maven2 repository types. Target Groups When a Staging Repository is "closed" and is made available to users and developers involved in the testing process, the temporary Staging Repository is added to one or more Repository Groups. This eld denes those groups. Close Repository Notication Settings After a developer has deployed a set of related release artifacts, a staging repository is "closed". This means that no further artifacts can be deployed to the same staging repository. A repository would be closed when a developer is satised that a collection of staged artifacts is ready to be certied by a manager or a quality assurance resource. In this setting, it is possible to dene email addresses and Roles which should be notied of a staging repository being closed. A notication email will be sent to all specied email addresses, as well as all Nexus users in the specied roles, informing that a staging repository has been closed. It is also possible to select that the creator of the staging repository receives this notication. Promote Repository Notication Settings Once a closed staging repository has been certied by whoever is responsible for testing and checking a staged release, it can then be promoted (published) or dropped (discarded). In this setting, it is possible dene email addresses and Roles which should be notied of a staging repository being promoted. A notication email will be sent to all specied email addresses, as well as all Nexus users in the specied roles, informing that a staging repository has been promoted. It is also possible to select that the creator of the staging repository receives this notication. Drop Repository Notication Settings In this setting, it is possible dene email addresses and Roles which should be notied of a staging repository being dropped. A notication email will be sent to all specied email addresses, as well as all Nexus users in the specied roles, informing that a staging repository has been dropped. It is also possible to select that the creator of the staging repository receives this notication. Close Repository Staging Rulesets This denes the rulesets which will be applied to a staging repository before it can be closed. If the staging repository does not pass the rules dened in the specied rulesets, you will be unable to close it. For more information about rulesets, see Section 9.17. Promote Repository Staging Rulesets This denes the rulesets which will be applied to a staging repository on promotion. If the staging repository does not pass the rules dened in the specied rulesets, the promotion will fail with an error message supplied by the failing rule. For more information about rulesets, see Section 9.17. Once youve created a Staging Repository with the values shown in Figure 9.8, you are ready to perform a test deployment to the Staging URL.
9.9
Conguring Build Promotion Proles
A Build Promotion prole is used when you need to add an additional step between initial staging and nal release. To add a new Build Promotion prole, open the Staging Proles link from the Nexus menu and click on Add. . . to display the dropdown menu shown in Figure 9.9. Select Build Promotion Prole from this dropdown to create a new Build Promotion Prole.
Ed. 3.0.2

132 / 241
Figure 9.9: Multi-level Staging and Build Promotion After creating a new Build Promotion prole, you will see the form shown in Figure 9.10. This form contains the following conguration elds: Prole Name This is the name for the Build Promotion prole which will be displayed in the promotion dialog shown in Figure 9.26. This name will also be associated with repositories created from this promotion prole. Template This is the template for repositories generated by this Build Promotion prole. The default value for this eld is "Maven2 (group)". Target Groups This is the most important conguration eld for a Build Promotion prole. It controls the group that promoted artifacts will be made available through. Artifacts can be made available through one or more groups.
Figure 9.10: Conguring a Build Promotion Prole
Ed. 3.0.2

133 / 241
9.10
Adding the Staging Deployer Role
To perform a staged deployment, the user deploying the artifact must have the "Staging: Deployer (admin)" role or the "Staging: Deployer" role for a specic Staging Prole. When you create a Staging Prole, Nexus will create two new Nexus roles that grant permissions specic to that staging prole. If you created the Staging prole from the previous section, Nexus would have created two roles: "Staging: Repositories (Release Staging Prole)" This role grants a user read and view access to the staging repositories created by a specic staging prole. "Staging: Deployer (Release Staging Prole)" This role grants all of the privileges from the Staging: Repositories role and it grants the user permission to deploy artifacts, close a staging repository, and promote or drop a staging repository created by a specic staging prole. In addition to the prole-specic staging roles, the Staging Suite also denes two universal roles which grant read-only or deployer rights across all staging repositories. These roles are: "Staging: Repositories (admin)" This role grants a user read and view access to all staging repositories. "Staging: Deployer (admin) This role grants a user all of the privileges from the Staging: Repositories role and it grants the user permission to deploy artifacts to any staging repository, close all staging repositories, and promote or drop all staging repositories. To congure the deployment user with the appropriate staging role, click on Users under the Security menu in the Nexus menu. Once you see the Users panel, click on the deployment user to edit this users roles. If the Staging Suite is installed, you should see the "Staging: Deployer (admin)" role listed in Available Roles. Select the "Staging: Deployer (admin)" role and then click the left arrow to add this role to the deployment users list of assigned roles.
Figure 9.11: Assigning the Staging Deployer Role to the deployment user
Ed. 3.0.2

134 / 241
Once the deployment user has the "Staging: Deployer (admin)" role, you can then use this user to deploy to the staging URL and trigger any Staging Prole. Without this permission, the deployment user would not be able to publish a staged artifact. If you need to add a specic permission to activate a single Staging Prole, you would select that specic role in the Available Roles list shown in Figure 9.11. In this gure, note that there are two "Staging: Deployer" roles: one for general administrative permission to deploy to any staging prole, and another which targets a specic staging prole.
9.11
Performing a Staged Deployment with Maven
In the previous section, you created a Staging Prole which references the Repository Target created in Section 9.7. If the Staging Suite is congured correctly, any deployment to the staging URL under the groupId com.sonatype.sample should be intercepted by the Staging Suite and placed in a temporary staging repository. Once this repository has been closed, it will be made available in the Target Group you selected when you congured the Staging Prole in Section 9.8. In this section, you will create a new project using the Maven Archetype plugin to test the Staging Prole you created in the previous section.
9.12
Creating a New Project
To create a new project run mvn archetype:generate. Running this at the command line will bring up a list of archetypes, choose the default maven-archetype-quickstart or number 16, and use the identier values listed in Table 9.1 for the new project. Table 9.1: Identiers for New Project Identier groupId artifactId version package Value com.sonatype.sample staging-test 1.0 com.sonatype.sample
If the archetype generate goal is executed successfully, you should have output which resembles the following screen listing:
$ mvn archetype:generate ... [INFO] [archetype:generate] [INFO] Generating project in Interactive mode [INFO] No archetype defined. Using maven-archetype-quickstart \ (org.apache.maven.archetypes:maven-archetype-quickstart:1.0) Choose archetype: 1: internal -> appfuse-basic-jsf (AppFuse archetype for creating a \ web application with Hibernate, Spring and JSF) ... 41: internal -> gmaven-archetype-mojo (Groovy mojo archetype) Choose a number: (1/.../41) 16: : 16 Define value for groupId: : com.sonatype.sample Define value for artifactId: : staging-test Define value for version: 1.0-SNAPSHOT: : 1.0 Define value for package: com.sonatype.sample: : com.sonatype.sample Confirm properties configuration: groupId: com.sonatype.sample artifactId: staging-test version: 1.0 package: com.sonatype.sample Y: :
Ed. 3.0.2

135 / 241
[INFO] [INFO] [INFO] [INFO] [INFO] [INFO] ... [INFO]
Parameter: Parameter: Parameter: Parameter: Parameter: Parameter:
groupId, Value: com.sonatype.sample packageName, Value: com.sonatype.sample basedir, Value: /private/tmp package, Value: com.sonatype.sample version, Value: 1.0 artifactId, Value: staging-test
BUILD SUCCESSFUL
9.13
Update the POM: Deployment Conguration
To deploy a staged release, a developer needs to deploy to the staging URL. To congure this new project to deploy to the Staging URL, add the a distributionManagement element to the stage-test projects POM. Listing the Staging URL in distributionManagement
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.sonatype.sample</groupId> <artifactId>staging-test</artifactId> <packaging>jar</packaging> <version>1.0</version> <name>staging-test</name> <url>http://maven.apache.org</url> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> </dependencies> <distributionManagement> <repository> <id>nexus</id> <name>Nexus Staging Repo</name> <url>http://localhost:8081/nexus/service/local/staging/deploy/maven2/</url> </repository> </distributionManagement> </project>
This conguration element, distributionManagement, denes the repository to which our deployment will be made. It references the Staging Suites Staging URL: http://localhost:8081/nexus/service/local/staging/deploy/maven2 This URL acts as a something of a virtual repository to be published to. If an artifact being published matches one of the Repository Targets in a Staging Prole, that Staging Prole is "activated" and a temporary Staging Repository is created for a specic client as dened by the combination of a clients IP address, Deployment User name, and User-Agent.
9.14
Update settings.xml with Deployment Credentials
To successfully deploy to your Nexus instance, you will need to update your Maven Settings with the credentials for the deployment user. These credentials are stored in the Maven Settings le in /.m2/settings.xml. To add these credentials, add the following element to the servers element le as shown in Listing deployment credentials in Maven Settings. Listing deployment credentials in Maven Settings
Ed. 3.0.2

136 / 241
<settings> ... <servers> ... <server> <id>nexus</id> <username>deployment</username> <password>deployment123</password> </server> </servers> ... </settings>
Note that the server identier listed in Listing deployment credentials in Maven Settings matches the server identier listed in Listing the Staging URL in distributionManagement. The deployment credential listed in Listing deployment credentials in Maven Settings contains the default password for the Nexus deployment user - deployment123. You should change this password to match the deployment password for your Nexus installation.
9.15
Deploying to a Staged Repository
Once the sample projects distributionManagement has been set to point at the Nexus Staging URL and your deployment credentials are updated in your ~/.m2/settings.xml le, you can deploy to the Staging URL. To do this, run mvn deploy
$ mvn deploy [INFO] Scanning for projects... [INFO] -----------------------------------------------------------------------[INFO] Building staging-test [INFO] task-segment: [deploy] [INFO] -----------------------------------------------------------------------[INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Nothing to compile - all classes are up to date [INFO] [surefire:test] [INFO] Surefire report directory: /private/tmp/staging-test/target/surefire-reports ... [INFO] [jar:jar] [INFO] [install:install] [INFO] Installing /private/tmp/staging-test/target/staging-test-1.0.jar to \ ~/.m2/repository/com/sonatype/sample/staging-test/1.0/staging-test-1.0.jar [INFO] [deploy:deploy] altDeploymentRepository = null Uploading: http://localhost:8081/nexus/service/local/staging/deploy/maven2/\ com/sonatype/sample/staging-test/1.0/staging-test-1.0.jar 2K uploaded [INFO] Uploading project information for staging-test 1.0 [INFO] Retrieving previous metadata from nexus [INFO] repository metadata for: artifact com.sonatype.sample:staging-test could not be found on repository: nexus, so will be created [INFO] Uploading repository metadata for: artifact com.sonatype.sample:staging-test [INFO] -----------------------------------------------------------------------[INFO] BUILD SUCCESSFUL
Ed. 3.0.2

137 / 241
9.16
Uploading a Staged Deployment in Nexus
You can also upload a staged deployment via the Nexus interface. To upload a staged deployment, select Staging Upload from the Nexus menu. Clicking Staging Upload will show the panel shown in Figure 9.12.
Figure 9.12: Uploading a Staged Deployment in Nexus To upload an artifact, click on Select Artifact(s) for Upload. . . and select one or more artifacts from the lesystem to upload. Once you have selected an artifact, you can modify the classier and the extension before clicking on the Add Artifact button. Once you have clicked on the Add Artifact button, you can then congure the source of the Group, Artifact, Version (GAV) parameters. If the artifact you are uploading is a JAR le that was created by Maven it will already have POM information embedded in it, but if you are uploading a JAR from a vendor you will likely need to set the Group Identier, Artifact Identier, and Version manually. To do this, select GAV Parameters from the GAV Denition dropdown at the top of this form. Selecting GAV Parameters will expose a set of form elds which will let you set the Group, Artifact, Version, and Packaging of the artifacts being uploaded. If you would prefer to set the Group, Artifact, and Version from a POM le which was associated with the uploaded artifact, select From POM in the GAV Denition dropdown. Selecting From POM in this dropdown will expose a button labeled "Select POM to Upload". Once a POM le has been selected for upload, the name of the POM le will be displayed in the form eld below this button. The Staging Upload panel supports multiple artifacts with the same Group, Artifact, and Version identiers. For example, if you need to upload multiple artifacts with different classiers, you may do so by clicking on Select Artifact(s) for Upload and Add Artifact multiple times. This interface also accepts an Artifact Bundle which is a JAR that contains more than one artifact. Once a staging artifact upload has been completely congured, click on Upload Artifact(s) button to begin the upload process. Nexus will upload the artifacts to the Staging URL which will trigger any staging proles that are activated by the upload. If a staging prole is activated, a new staging repository will be created and can be managed using the procedures outlined in Section 9.20.
Ed. 3.0.2

138 / 241
9.17
Managing Rulesets
Nexus Professional has the ability to dene staging rules that must be satised before a staging repository can be promoted.
9.18
Managing Staging Rulesets
Staging Rulesets are groups of rules that are applied to a Staging repository at promotion time. A staging repository associated with a staging ruleset cannot be promoted until all of the rules associated with the rulesets have been satised. This feature allows you to set standards for your own hosted repositories, and it is the mechanism that is used to guarantee the consistency of artifacts stored in the Maven Central repository. Nexus Professional contains the following rules: Staging Javadoc Validation The Staging Javadoc Validation rule will verify that every project has an artifact with the javadoc classier. If you attempt to promote a staging repository which contains artifacts not accompanied by "-javadoc.jar" artifacts, this validation rule will fail. Staging Artifact Uniqueness Validation This rule checks to see that the artifact being released, promoted, or staged is unique in a particular Nexus instance. Staging Checksum Validation This rule validates le checksums against published artifacts. Staging No Release Repository This rule will fail if a particular staging prole is not dened with a release repository. Staging POM Validation The Staging POM Validation rule will verify the following properties of all POMs to be promoted: Project URL - project/url Project Licenses - project/licenses Project SCM Information - project/scm If any of these POM elements are missing or empty, this Staging Ruleset will cause a promotion to fail. Staging Signature Validation The Staging Signature Validation rule veries that every item in the repository has a valid PGP signature. If you attempt to promote a staging repository which contains artifacts not accompanied by valid PGP signature, this validation will fail. Staging Sources Validation The Staging Sources Validation rule will verify that every project has an artifact with the sources classier. If you attempt to promote a staging repository which contains artifacts not accompanied by "-sources.jar" artifacts, this validation rule will fail. To create a Staging Ruleset, click on the Staging Ruleset link in the Nexus Menu. This will load the interface shown in Figure 9.13. The Staging Ruleset panel is used to dene sets of rules that can be applied to Staging Proles. Figure 9.13 shows a ruleset which contains all four predened staging rules.
Ed. 3.0.2

139 / 241
Figure 9.13: Creating a Staging Ruleset
9.19
Dening Rulesets for Promotion
To dene a ruleset to be used for promotion, click on Staging in the Nexus menu and select a Staging Prole. Click on the Conguration tab, and scroll down to the Promote Repository Staging Rulesets section of the Staging Prole conguration as shown in Figure 9.14. The next time you attempt to promote a staging repository that was created with this prole, Nexus Professional will check that all of the rules in the associated rulesets are being adhered to.
Ed. 3.0.2

140 / 241
Figure 9.14: Associating a Staging Ruleset with a Staging Prole
9.20
Managing Staging Repositories in Nexus
Once you complete the process outlined in Section 9.11, you will then have an automatically generated Staging Repository. In this section, you will walk through the process of managing staging repositories. Once a staging repository has been created, there are two steps in the lifecycle of a staging repository. Once you have deployed a set of related artifacts, you must "Close" the repository moving it from an "Open" to a "Closed" state. Once a repository is in the "Closed" state it is added to a Repository Group and is made available for testing purposes. Once testing is completed, a Nexus administrator can either Promote or Drop a Closed repository. If the repository is Dropped, the repository is discarded and removed from the Repository Group. If the repository is Promoted, the Nexus administrator can select a Hosted repository and publish the contents of the temporary staging repository to a Hosted repository.
9.21
Closing an Open Repository
Once you deploy an artifact that triggers a staging prole, Nexus Staging Suite will create a repository that contains the artifacts you deployed. A separate staging repository is created for every combination of User ID, IP Address, and User Agent. This means that you can perform more than one deployment to a single Staging Repository as long as you perform the deployment from the same IP, with the same deployment user, and the same installation of Maven. You can perform multiple deployments to an "Open" staging repository, to see a list of these temporary "Open" Staging repositories, select "Staging" from the Nexus menu and click on the appropriate Staging Prole to browse a list of staging repositories which correspond to a staging prole.
Ed. 3.0.2

141 / 241
Figure 9.15: Listing Repositories Associated with a Staging Prole Once you are ready to start testing the staging repository, you will need to transition the staging repository from the "Open" state to the "Closed" state. This will close the temporary staging repository to more deployments. To close a repository, right-click on the repository in the Staging Repositories panel and select "Close". This will bring up the following dialog for a staging deployer to describe the contents of a staging repository. This description eld can be used to pass essential information to the person that needs to test a deployment. In Figure 9.16, the description eld is used to describe the release for the user that needs to certify and promote a release.
Figure 9.16: Conrmation and Description Dialog for Closing a Staging Repository Conrming this state transition will close the repository and add the repository to a repository group. Once a repository has been closed, it will be listed as "Closed" in the Proles Repositories tab.
Ed. 3.0.2

142 / 241
Figure 9.17: Closed Repository After Selecting Finish
9.22
Using the Staging Repository
Once the Staging Repository has been closed, it will automatically be added to the Repository Group that was specied in the Staging Prole. Figure 9.18 shows an instance of a staging repository appended to the end of a group named "Public Repositories". This has the effect of making the staged artifacts available to everyone who is referencing this public group. Developers who are referencing this public repository group can now test and interact with the staged artifacts as if they were published to a Hosted repository. While the artifacts are made available in a repository group, the fact that they are held in a temporary staging directory gives the administrator the option of promoting this set of artifacts to a Hosted repository or dropping this temporary staging repository if there are problems discovered during the testing and certication process for a release.
Ed. 3.0.2

143 / 241
Figure 9.18: Staging Repository Added to the End of a Repository Group Once a staging repository is closed, you can also browse and search the repository. To view Staging Repositories, click on Browse Repositories and then select Nexus Managed Repositories as shown in Figure 9.19.
Ed. 3.0.2

144 / 241
Figure 9.19: Viewing Nexus Managed Repositories Once youve selected Nexus Managed Repositories, Nexus will then show you all of the repositories that have been created by the Nexus Staging Suite. You can select and browse this temporary Staging Repository as you would any other repository.
Figure 9.20: Browsing a Staging Repository
Ed. 3.0.2

145 / 241
You can browse the contents of a staging repository from the Staging Repositories panel. Click on Staging Repositories in the Nexus menu, click on a Staging Repository to browse the contents and perform operations a staging repository.
Figure 9.21: Browsing Repository via Staging Proles
9.23
Releasing a Staging Repository
Once you are nished testing or certifying that the contents of a Staging Repository are correct, you are ready to either Release or Drop the Staging Repository. Dropping the Staging Repository will delete the temporary staging repository from Nexus and remove any reference to this repository from the groups it was associated with. Releasing the Staging Repository allows you to publish the contents of this temporary repository to a Hosted repository. To release a Staging Repository select Staging from the Nexus menu and then click on the appropriate Staging Prole. This will display a list of Staging Repositories associated with that Staging Prole. To release the contents of a repository, load the list of Staging Repositories, check the box next to the staging repository you which to promote and then click the Release button shown in Figure 9.22.
Figure 9.22: Promoting a Staging Repository Once you click Release, the Nexus Staging Suite will ask you to supply a description for this release action.
Ed. 3.0.2

146 / 241
Figure 9.23: Selecting the Destination Repository for Staged Repository Promotion Supplying a description and clicking on Release will publish the contents of a Staging Repository to a Hosted repository and delete the Staging Repository from Nexus.
Figure 9.24: Conrmation Dialog for Repository Promotion
9.24
Promoting a Staging Repository
If you have a staging repository that you want to promote to a Build Promotion prole, open the list of Staging Repositories by selecting Staging Repositories from the Nexus menu, select the repository you intend to promote, and click the Promote button as shown in Figure 9.25.
Ed. 3.0.2

147 / 241
Figure 9.25: Promoting a Staging Repository After clicking the Promote button the Promote Staging Repository shown in Figure 9.26 will be displayed. In this dialog, you can choose the Build Promotion prole to promote the staging repository to, and you can supply a short description of the promotion. Clicking on the Promote button in this dialog will promote the staging prole to a build promotion prole and expose the contents of the selected staging repository through a group associated with the build promotion prole.
Figure 9.26: Multi-level Staging and Build Promotion After you promote a staging repository to a Build Promotion prole the build promotion prole will create a temporary repository which contains the contents of the promoted staging repository. The staging repository will be a Group Member of the Build Promotion repository. One or more staging repositories can be promoted to a single Build Promotion prole, and you can browse the Group Member by selecting the Build Promotion repository and viewing the Group Member tab as shown in Figure 9.27.
Ed. 3.0.2

148 / 241
Figure 9.27: Multi-level Staging and Build Promotion
9.25
Releasing, Promoting, and Dropping Build Promotion Proles
When you congure a Build Promotion prole and promote Staging Repositories to promotion proles, each Build Promotion prole creates a repository which contains one or more Staging Repositories. Just like you can promote the contents of a Staging Repository to a Build Promotion prole, you can also promote the contents of a Build Promotion prole to another Build Promotion prole. When you do this you can create hierarchies of staging repositories and build promotion proles which can then be dropped or released together.
Figure 9.28: Releasing, Promoting, and Dropping Build Promotion Proles When you promote a staging repository to a build promotion prole, you make the contents of a staging repository available via a repository group associated with a build promotion prole. For example, if you staged a few artifacts to a QA Staging Repository and then subsequently promoted that repository to a Closed Beta Build Promotion group, the contents of the QA Staging Repository would initially be made available via a QA Repository Group. After a build promotion, these artifacts would also be available via a Closed Beta repository group. You can take it one step further and promote the contents of the Closed Beta Build Promotion prole to yet another Build Promotion prole. In this way you can have an arbitrary number of intermediate steps between the initial staging deployment and the nal release. If you drop the contents of a build promotion prole, you roll back to the previous state. For example, if you decided to drop the contents of the Closed Beta build promotion group, Nexus will revert the status of the Staging Repository from promoted
Ed. 3.0.2

149 / 241
to closed, and make the artifacts available via the QA Staging Repository. The effects of promoting, dropping, and releasing artifacts through a series of Staging Proles and Build Promotion Proles is shown in Figure 9.28. When you perform a release on a Build Promotion prole, each Staging Repository is going to release artifacts to the Release Repository congured in Figure 9.8. Because a Build Repository can contain one or more promoted staging repositories, this means that releasing a Build Promotion prole can cause artifacts to be published to more than one Release Repository. Build Promotion proles are not directly related to release repositories, only staging proles are directly associated with target release repositories. Figure 9.29 illustrates this behavior with two independent Staging Repositories each congured with a separate Release Repository. Releasing the Build Promotion prole causes Nexus to publish each Staging Repository to a separate hosted repository.
Figure 9.29: Promoting Multiple Repositories to the Same Build Promotion Prole
9.26
Managing Staging Repositories with the Nexus Maven Plugin
You can do everything that was described in Section 9.20 with the Nexus Maven Plugin. Using the Nexus Maven Plugin you can: Close a Staging Repository Promote a Staging Repository Drop a Staging Repository List All Available Staging Repositories
9.27
Running the Nexus Maven Plugin
To invoke goals in the Nexus Maven plugin, you will want to add the appropriate plugin group to your Maven settings le. Add the org.sonatype.plugins groupId to ~/.m2/settings.xml as shown in Adding org.sonatype.plugins to pluginGroups in Maven Settings. Adding org.sonatype.plugins to pluginGroups in Maven Settings
<settings> ... <pluginGroups> <pluginGroup>org.sonatype.plugins</pluginGroup> </pluginGroups> ... </settings>
Adding the org.sonatype.plugins group to your Maven Settings will allow you to run the following goals from the Nexus Maven Plugin: nexus:staging-close This goal will close a staging repository from Maven. This goal in the Nexus Maven plugin corresponds to the procedure described in Section 9.21.
Ed. 3.0.2

150 / 241
nexus:staging-list This goal will list all of the staging repositories which are currently visible to a user. nexus:staging-drop This goal allows you to drop a specic staging repository. If no repositories are specied for this goal, this plugin will present an interactive menu listing all of the closed staging repositories currently eligible for a drop operation. nexus:staging-promote This goal allows you to promote a specic repository. If no repositories are specied for this goal, this plugin will present an interactive menu listing all of the closed staging repositories currently eligible for a promote operation. Once you have congured the pluginGroup in your Maven Settings le, you can run the Nexus Maven plugin from the command line. In order to access the staging suite in your Nexus instance, the plugin must be told where Nexus is.
$ mvn nexus:staging-list
9.28
Conguring Nexus Maven Plugin for Staging
All of the Staging goals in the Nexus Maven plugin require security credentials and a base URL for the Nexus server you are attempting to manage. You can specify security credentials by supplying a username and password or by supplying a server id that corresponds to a server in your Maven Settings (~/.m2/settings.xml). The common conguration parameters and security conguration properties are: nexusUrl Points to the Nexus server installations base URL. If you have installed Nexus on your local machine, this would be http://localhost:8081/nexus/ username Username to use for authenticating to Nexus. Default value is $user.name. password Password to use for authenticating to Nexus serverAuthId You should specify either username and password or the serverAuthId. If you specify a value for serverAuthId, the Nexus Maven plugin is going to look at the contents of your ~/.m2/settings.xml le and use the username and password from a server denition. In most cases a valid user login will be required to access your staging information. By default, if you dont specify the nexusUrl and password parameters, the plugin will prompt you for them. If you dont specify the username parameter, the Java System property $user.name In addition to these security options, all of the staging goals have a common conguration property which controls the logging level. verboseDebug If verboseDebug is set to true Maven will print out debug messages that detail the plugins interaction with Nexus.
9.28.1
Listing Your Open Staging Repositories
Once youve deployed one or more sets of artifacts as release candidate to Nexus, youll have one or more open staging repositories. There are a variety of actions you can take with these repositories, but maybe one of the most basic is to list them. This gives you a pretty good view into the status of your release(s). The basic command is:
Ed. 3.0.2

151 / 241
$ mvn nexus:staging-list [...] [INFO] Logging into Nexus: http://localhost:8082/nexus [INFO] User: testuser [INFO] [INFO] The following OPEN staging repositories were found: - staging-003 (profile: Example Profile) URL: http://localhost:8082/nexus/content/repositories/staging-003 [INFO] The following CLOSED staging repositories were found: - staging-001 (profile: Example Profile) URL: http://localhost:8082/nexus/content/repositories/staging-001 Description: This is a test repository - staging-002 (profile: Example Profile) URL: http://localhost:8082/nexus/content/repositories/staging-002 Description: This is another test repository You can find more information about this Mojo https://repository.sonatype.org/content/sites /maven-sites/nexus-maven-plugin/usage-staging.html[here]
9.28.2
Closing a Staging Repository
Before your team can run any tests against the set of artifacts that constitute your release, you need to mark the open staging repository as closed. This means that no additional artifacts can be added to that specic staging repository, making the set of artifacts it contains an immutable snapshot. When it is closed, the repository will become available for artifact resolution. The basic command is:
$ mvn nexus:staging-close [INFO] Available Staging Repositories: 1: staging-002 (profile: Example Profile) URL: http://localhost:8082/nexus/content/repositories/staging-002
Select a repository to close (1) 1: : 1 Repository Description: This is a test repository [INFO] Finishing staging repository for: com.myco:my-project:1: - staging-002 (profile: Example Profile) URL: http://localhost:8082/nexus/content/repositories/staging-002 [INFO] The following CLOSED staging repositories were found for: \ com.myco:my-project:1: - staging-001 (profile: Example Profile) URL: http://localhost:8082/nexus/content/repositories/staging-001 Description: This is a test repository - staging-002 (profile: Example Profile) URL: http://localhost:8082/nexus/content/repositories/staging-002 Description: This is another test repository
Ed. 3.0.2

152 / 241
The output above shows that the staging-close Mojo found an open staging repository - staging-001 - for the current project, then told Nexus to close it. Afterward, it displayed the list of closed staging repositories, which included the one we just closed. If you dont have an open staging repository, youll see something like this instead:
No open staging repositories found. Nothing to do! [INFO] The following CLOSED staging repositories were found for: \ com.myco:my-project:1: - staging-001 (profile: Example Profile) URL: http://localhost:8082/nexus/content/repositories/staging-001 Description: This is a test repository - staging-002 (profile: Example Profile) URL: http://localhost:8082/nexus/content/repositories/staging-002 Description: This is another test repository You can find more information about this Mojo https://repository.sonatype.org/content/sites /maven-sites/nexus-maven-plugin/staging-close-mojo.html[here]
9.28.3
Dropping a Closed Staging Repository
In the unfortunate event that your project artifacts fail during testing, you may need to drop the staging repository that houses them, in order to avoid confusing them with newer candidate releases. The basic command is:
$ mvn nexus:staging-drop [INFO] Available Staging Repositories: 1: staging-006 (profile: Example Profile) URL: http://localhost:8082/nexus/content/repositories/staging-006 Description: This is a test repository Select a repository to drop (1) 1: : 1 [INFO] Dropping staged repository: - staging-006 (profile: Example Profile) URL: http://localhost:8082/nexus/content/repositories/staging-006 Description: This is a test repository
The Mojo will present you with a list of closed staging repositories, with the rst in the list selected as the default response. If you simply hit the Enter key, the default will be used; otherwise, the repository corresponding to the number you select will be used. If you have no closed staging repositories, youll see something like this instead:
[INFO] No closed staging repositories found. Nothing to do! You can find more information about this Mojo https://repository.sonatype.org/content/sites /maven-sites/nexus-maven-plugin/staging-drop-mojo.html[here]
9.28.4
Promoting a Closed Staging Repository
On the other hand, if your project artifacts pass all tests, you will nd that you need to promote the staging repository that houses them, in order to nalize the release and make the artifacts available for public consumption. The basic command is:
Ed. 3.0.2

153 / 241
$ mvn nexus:staging-promote [INFO] Available Staging Repositories: 1: staging-006 (profile: Example Profile) URL: http://localhost:8082/nexus/content/repositories/staging-006 Description: This is a test repository Select a repository to promote (1) 1: : 1 Target Repository ID: releases [INFO] Promoting staging repository to: releases: - staging-006 (profile: Example Profile) URL: http://localhost:8082/nexus/content/repositories/staging-006 Description: This is a test repository
The Mojo will present you with a list of closed staging repositories, with the rst in the list selected as the default response. If you simply hit the Enter key, the default will be used; otherwise, the repository corresponding to the number you select will be used. If you have no closed staging repositories, youll see something like this instead:
[INFO] No closed staging repositories found. Nothing to do! You can find more information about this Mojo https://repository.sonatype.org/content/sites /maven-sites/nexus-maven-plugin/staging-promote-mojo.html[here]
Ed. 3.0.2

154 / 241
Chapter 10
Managing Maven Settings

10.1 Introduction
Nexus Professional allows you to dene templates for Maven Settings and use Nexus as a way to distribute updates to a global Maven Settings template. When you move an organization to a repository manager such as Nexus, one of the constant challenges is keeping everyones Maven Settings synchronized. If a Nexus administrator makes a change which requires every developer to modify his or her ~/.m2/settings.xml le, this feature can be used to manage the distribution of Maven Settings changes to the entire organization. Once you have dened a Maven Settings template in Nexus Professional, developers can then use the Nexus Maven plugin to retrieve the new Maven Settings le directly from Nexus Professional.
10.2
Manage Maven Settings Templates
To manage Maven Settings templates, click on Maven Settings in the Enterprise section of the Nexus menu on the left side of the Nexus UI. Clicking on Maven Settings will load the panel shown in Figure 10.1.
Ed. 3.0.2

155 / 241
Figure 10.1: The Maven Settings Panel The Maven Settings panel allows you to add, delete, and edit a Maven Settings template. The default template has an id of "default" and is read-only, it contains the recommended settings for a standard Nexus installation. To create a new Maven Settings template, click on the Add. . . button and select "Settings Template". Once the new template is created, assign a name to the template and click the Save button. To edit a template, click on a template that is not read only, and edit the template in the Maven Settings panel. Once you are nished editing the template, click Save to save the template. When editing the template, the following variables are available: baseurl This variable will be replaced with the base URL of the Nexus installation. userId This variable will be replaced with the user id of the user that is generating a Maven Settings le from this template. To preview a Maven Settings template, click on the Template URL in the table of Maven Settings templates. Clicking on this URL will load a dialog window which contains the Maven Settings le generated from this template. This rendered view of the Maven Settings template will have all variable references replaced using the current context of the user: $baseurl will be replaced with the Base URL of the current Nexus installation, and $userId will be replaced with the user id of the current user.
10.3
Downloading Maven Settings with the Nexus Maven Plugin
Once you have dened a set of Maven templates, you can use the Nexus Maven plugin to distribute changes to the Maven Settings le to the entire organization.
Ed. 3.0.2

156 / 241
10.3.1
Running the Nexus Maven Plugin
To invoke goals in the Nexus Maven plugin, you will initially have to use a fully qualied groupId and artifactId as shown in Invoking the Nexus Maven Plugin goal settings-download with a fully qualied groupId and artifactId. Invoking the Nexus Maven Plugin goal settings-download with a fully qualied groupId and artifactId
mvn org.sonatype.plugins:nexus-maven-plugin:settings-download
To be able to invoke the plugin with the simple identier "nexus" as shown in Invoking the Nexus Maven Plugin goal settingsdownload with a short identier, you have to add the appropriate plugin group to your Maven Settings le as shown in Adding org.sonatype.plugins to pluginGroups in Maven Settings. An initial invocation of the settings-download goal will update your settings le, with a template from Nexus Professional. Every default template in Nexus Professional adds the org.sonatype.plugins group to the pluginGroups, so you will not have to do this manually. It is essential that you make sure that any new, custom templates also include this plugin group denition. Otherwise, there is a chance that a developer could update his or her Maven Settings and lose the ability to use the Nexus Maven plugin with the short identier Invoking the Nexus Maven Plugin goal settings-download with a short identier
mvn nexus:settings-download
Adding org.sonatype.plugins to pluginGroups in Maven Settings

<settings> ... <pluginGroups> <pluginGroup>org.sonatype.plugins</pluginGroup> </pluginGroups> ... </settings>
The "settings-download" goal of the Nexus Maven Plugin downloads a Maven Settings le from Nexus Professional and stores it on a local machine. This goal can be congured to update a users ~/.m2/settings.xml le or the global conguration le which is stored in the Maven installation directory. If you are replacing a Maven Settings le, this goal can be congured to make a backup of an existing Maven Settings le.
10.3.2
Conguring Nexus Maven Plugin for Settings Management
The Settings Management goal in the Nexus Maven plugin requires security credentials and a base URL for the Nexus server you are interacting with. You can specify security credentials by supplying a username and password or by supplying a server id that corresponds to a server in your Maven Settings (~/.m2/settings.xml). The common conguration parameters and security conguration properties are: nexusURL Points to the Nexus server installations base URL. If you have installed Nexus on your local machine, this would be http://localhost:8081/nexus/ username Username to use for authenticating to Nexus. Default value is $user.name. password Password to use for authenticating to Nexus serverAuthId You should specify either username and password or the serverAuthId. If you specify a value for serverAuthId, the Nexus Maven plugin is going to look at the contents of your ~/.m2/settings.xml le and use the username and password from a server denition.
Ed. 3.0.2

157 / 241
In most cases a valid user login will be required to access your settings templates. By default, if you dont specify the nexusURL and password parameters, the plugin will prompt you for them. If you dont specify the username parameter, the Java System property $user.name will be used. In addition to these security options, all of the Maven Settings management goal has the following conguration parameters: verboseDebug If verboseDebug is set to true Maven will print out debug messages that detail the plugins interaction with Nexus. backupFormat When backing up an existing settings.xml le, use this date format in conjunction with SimpleDateFormat to construct a new lename of the form: settings.xml.$(format). Datestamps are used for backup copies of the settings.xml to avoid overwriting previously backed up settings les. This protects against the case where the download mojo is used multiple times with incorrect settings, where using a single static backup-le name would destroy the original, pre-existing settings. Default value is: yyyyMMdd_HHmmss. destination The standard destination where the downloaded settings.xml template should be saved. If the destination is "global", the Nexus Maven plugin will save the Maven Settings le to $M2_HOME/conf. Is the destination is "user", the Nexus Maven plugin will save the Maven Settings le to ~/.m2/settings.xml. If the target parameter is set, it will override this value. Default value is: user. doBackup If true and there is a pre-existing settings.xml le in the way of this download, backup the le to a datestamped lename, where the specic format of the datestamp is given by the backupFormat parameter. Default value is: true. encoding Use this parameter to dene a non-default encoding for the settings le. target If set, ignore the standard location given by the destination parameter, and use this le location to save the settings template instead. If this le exists, it will be backed up using the same logic as the standard locations (using the doBackup and backupFormat parameters). url The full URL of a settings template available from a particular Nexus Professional instance. If missing, the mojo will prompt for this value.
10.3.3
Downloading Maven Settings
To download Maven Settings from Nexus Professional, you will need to know the URL of the Maven Settings template. If you omit this URL on the command-line, the Nexus Maven plugin will prompt you for a URL when it is executed:
$ mvn org.sonatype.plugins:nexus-maven-plugin:settings-download [INFO] [nexus:settings-download] Settings Template URL: \ .../nexus/service/local/templates/settings/default/content [INFO] Existing settings backed up to: \ /Users/tobrien/.m2/settings.xml.20090408_204422 [INFO] Settings saved to: /Users/tobrien/.m2/settings.xml
Alternatively, you can specify the username, password, and URL on the command line.
$ export NX_URL="http://localhost:8081/nexus/" $ mvn org.sonatype.plugins:nexus-maven-plugin:settings-download \ -Durl=${NX_URL}/service/local/templates/settings/default/content \ -Dusername=admin \ -Dpassword=admin123</screen>
Ed. 3.0.2

158 / 241
Chapter 11
OSGi Bundle Repositories

11.1 Introduction
Nexus Professional supports the OSGi Bundle Repository format. The OSGi Bundle format is dened by the OSGi RFC 112 "Bundle Repository". It is a format for the distribution of OSGi "bundles" which includes any components that are described by the OSGi standards set forth in RFC 112. An OBR repository has a single XML le which completely describes the contents of the entire repository. Nexus Professional can read this OBR repository XML and create proxy repositories which can download OSGi bundles from remote OBR repositories. Nexus Professional can also act as a hosting platform for OSGi bundles, you can congure your builds to publish OSGi bundles to Nexus Professional, and then you can expose these bundle repositories to internal or external developers using Nexus Professional as a publishing and distribution platform. Nexus Professional can also act as a bridge between Maven repositories and OSGi bundle repositories. When you congure a virtual OBR repository which uses a Maven 2 repository as a source repository, Nexus Professional will expose artifacts with the appropriate metadata from the Maven repository as OSGi bundles. In this way, you can unify your OSGi and non-OSGi development efforts and publish artifacts with the appropriate OSGi metadata to Nexus Professional. Non-OSGi clients can retrieve software artifacts from a Maven repository, and OSGi-aware clients can retrieve OSGi bundles from a virtual OBR repository.
11.2
Managing OSGi Bundle Repositories
The following sections detail the procedures for creating and managing OBR repositories.
11.3
Proxy OSGi Bundle Repositories
Nexus can proxy an OSGi Bundle Repository, using the OBR repository XML as the remote storage location. To create a new proxy OBR repository: 1. Login as an Administrator. 2. Click Repositories in the Left Navigation Menu. 3. Click the Add.. button above the list of Nexus repositories, and choose Proxy repository from the dropdown of repository types. 4. In the New Proxy Repository window, a. Select OBR as the Provider. b. Supply an id and a repository name.
Ed. 3.0.2

159 / 241
c. Enter the URL to the remote repository OBR XML as the Remote Storage location. d. Click Save. Figure 11.1 provides some sample conguration used to create a proxy of the Apache Felix OBR repository.
Figure 11.1: Creating an OSGi Bundle Proxy Repository To verify that the OBR proxy repository has been properly congured, you can then load the OBR XML from Nexus Professional. If Nexus Professional is properly congured, you will be able load the obr.xml by navigating to the obr.xml directory:
$curl http://localhost:8081/nexus/content/repositories/felix-proxy/.meta/obr.xml <?xml version=1.0 encoding=utf-8?> <?xml-stylesheet type=text/xsl href=http://www2.osgi.org/www/obr2html.xsl?> <repository name=Felix OBR Repository lastmodified=1247493075615> <resource id=org.apache.felix.javax.servlet/1.0.0 presentationname=Servlet 2.1 API symbolicname=org.apache.felix.javax.servlet uri=../bundles/org.apache.felix.javax.servlet-1.0.0.jar version=1.0.0> <description> Servlet 2.1 API </description> <documentation> http://www.apache.org/ </documentation> <license> http://www.apache.org/licenses/LICENSE-2.0.txt </license> ...
11.4
Hosted OSGi Bundle Repositories
Nexus can host an OSGi Bundle Repository, providing you with a way to publish your own OBR bundles. To create an OBR hosted repository:
Ed. 3.0.2

160 / 241
1. Login as an Administrator. 2. Click Repositories in the Left Navigation Menu. 3. Click the Add.. button above the list of Nexus repositories, and choose Hosted repository from the dropdown of repository types. 4. In the New Hosted Repository window, a. Select OBR as the Provider. 5. Supply an id and a repository name. 6. Click Save. Figure 11.2 provides some sample conguration used to create a hosted OBR repository.
Figure 11.2: Creating a Hosted OSGi Bundle Repository
11.5
Virtual OSGi Bundle Repositories
Nexus Professional can also be congured to convert a traditional Maven repository into an OSGi Bundle repository using a virtual OBR repository. To congure a virtual OBR repository: 1. Login as an Administrator. 2. Click Repositories in the Left Navigation Menu. 3. Click the Add.. button above the list of Nexus repositories, and choose Virtual repository from the dropdown of repository types. 4. In the New Virtual Repository window, a. Select OBR as the Provider. b. Select another repositorys ID in the Source Nexus Repository ID dropdown c. Supply an id and a repository name. d. Click Save.
Ed. 3.0.2

161 / 241
The next gure provides some sample conguration used to create a virtual OBR repository which transforms the proxy repository for Maven Central into an OBR repository.
Figure 11.3: Creating a Virtual OSGi Bundle Repository from a Maven Repository
11.6
Grouping OSGi Bundle Repositories
Just like Nexus can group Maven repositories, Eclipse update sites, and P2 repositories, Nexus can also be congured to group OSGi Bundle Repositories. To group OSGi bundle repositories: 1. Login as an Administrator. 2. Click Repositories in the Left Navigation Menu. 3. Click the Add.. button above the list of Nexus repositories, and choose Repository Group from the dropdown of repository types. 4. In the New Repository Group window, a. Select OBR Group as the Provider. b. Drag and drop one or more hosted, proxy, or virtual OSGi Bundle repositories into the new group. c. Supply an id and a repository name. d. Click Save. Figure 11.4 shows an example of the a new repository group which contains a hosted OSGi Bundle repository, a virtual OSGi Bundle repository, and a OSGi Bundle proxy repository.
Ed. 3.0.2

162 / 241
Figure 11.4: Creating a new OSGi Bundle Repository Group
Ed. 3.0.2

163 / 241
Chapter 12
P2 Repositories
12.1 Introduction
Nexus Professional supports the P2 Repository format. The P2 repository format is a provisioning platform for Eclipse components. For more information about the P2 repository format, see the Equinox P2 documentation on the Eclipse Wiki.
12.1.1
Managing P2 Repositories
The following sections detail the procedures for creating and managing P2 repositories.
12.1.1.1 Proxy P2 Repositories
Nexus can proxy a P2 Repository. To create a new proxy P2 repository: 1. Login as an Administrator. 2. Click Repositories in the Left Navigation Menu. 3. Click the Add.. button above the list of Nexus repositories, and choose Proxy repository from the dropdown of repository types. 4. In the New Proxy Repository window, a. Select Eclipse P2 Repository as the Provider. b. Supply an id and a repository name. c. Enter the URL to the remote P2 repository as the Remote Storage location. i. Click Save. Figure 12.1 provides some sample conguration used to create a proxy of the Apache Felix P2 repository.
Ed. 3.0.2

164 / 241
Figure 12.1: Creating a P2 Proxy Repository
12.1.2
Grouping P2 Repositories
Just like Nexus can group Maven repositories and OBR repositories, Nexus can also be congured to group P2 Repositories. To group P2 repositories: 1. Login as an Administrator. 2. Click Repositories in the Left Navigation Menu. 3. Click the Add.. button above the list of Nexus repositories, and choose Repository Group from the dropdown of repository types. 4. In the New Repository Group window, a. Select Eclipse P2 Artifacts as the Group Provider. b. Drag and drop one or more P2 repositories into the new group. c. Supply an id and a repository name. d. Click Save. Figure 12.2 shows an example of the a new repository group which contains two P2 proxy repositories.
Ed. 3.0.2

165 / 241
Figure 12.2: Creating a new P2 Repository Group
Ed. 3.0.2

166 / 241
Chapter 13
Deploying Sites to Nexus

13.1 Introduction
Nexus Professional provides a new hosted repository type: a Maven Site repository. This repository can be used to hold a Maven-generated web site. This chapter details the process of conguring a Maven Site repository and conguring a simple Maven project to publish a Maven-generated project site to an instance of Nexus Professional.
13.1.1
Creating a New Maven Project
In this chapter, you will be creating a simple Maven project with a simple web site that will be published to a Nexus Professional Maven Site repository. To create a new Maven project, use the archetype plugins archetype:generatemvn archetype:generate on the command line, and supply the following identiers: groupId: org.sonatype.books.nexus artifactId: sample-site version: 1.0-SNAPSHOT package: org.sonatype.books.nexus
~/examples$ mvn archetype:generate [INFO] [archetype:generate {execution: default-cli}] [INFO] Generating project in Interactive mode Choose archetype: 1: internal -> appfuse-basic-jsf ... 13: internal -> maven-archetype-portlet (A simple portlet application) 14: internal -> maven-archetype-profiles () 15: internal -> maven-archetype-quickstart () ... Choose a number: (...14/15/16...) 15: : 15 Define value for groupId: : org.sonatype.books.nexus Define value for artifactId: : sample-site Define value for version: 1.0-SNAPSHOT: : 1.0-SNAPSHOT Define value for package: org.sonatype.books.nexus: : org.sonatype.books.nexus Confirm properties configuration: groupId: org.sonatype.books.nexus artifactId: sample-site version: 1.0-SNAPSHOT package: org.sonatype.books.nexus Y: :
Ed. 3.0.2

167 / 241
[INFO] [INFO] [INFO] [INFO] [INFO] [INFO] [INFO] [INFO] [INFO] [INFO] [INFO] [INFO] [INFO] [INFO]
Parameter: groupId, Value: org.sonatype.books.nexus Parameter: packageName, Value: org.sonatype.books.nexus Parameter: package, Value: org.sonatype.books.nexus Parameter: artifactId, Value: sample-site Parameter: basedir, Value: /private/tmp Parameter: version, Value: 1.0-SNAPSHOT OldArchetype created in dir: /private/tmp/sample-site -----------------------------------------------------------------------BUILD SUCCESSFUL -----------------------------------------------------------------------Total time: 23 seconds Finished at: Sat Oct 03 07:09:49 CDT 2009 Final Memory: 13M/80M ------------------------------------------------------------------------
After running the archetype:generate command you will have a new project in a sample-site/ subdirectory.
13.1.2
Conguring Maven for Site Deployment
To deploy a site to a Nexus Professional Maven Site repository, you will need to congure the projects distribution management settings, add site deployment information, and then update your Maven settings to include the appropriate credentials for Nexus.
~/examples$ cd sample-site ~/examples/sample-site$ more pom.xml <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>org.sonatype.books.nexus</groupId> <artifactId>sample-site</artifactId> <packaging>jar</packaging> <version>1.0-SNAPSHOT</version> <name>sample-site</name> <url>http://maven.apache.org</url> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> </dependencies> </project>
Add the following section to sample-site/pom.xml after the dependencies element. This section will tell Maven where to publish the Maven-generated project web site: Distribution Management for Site Deployment to Nexus
<distributionManagement> <site> <id>nexus-site</id> <url>dav:http://localhost:8081/nexus/content/sites/site/</url> </site> </distributionManagement>
Note In Distribution Management for Site Deployment to Nexus, there is a Nexus Professional installation running on localhost port 8081. In your environment you will need to customize this URL to point to your own Nexus instance.
Ed. 3.0.2

168 / 241
In addition to the distributionManagement element, you will want to add the following build element that will congure Maven to use version 2.0.1 of the Maven Site plugin. Conguring the Maven Site Plugin for Nexus Site Deployment
<build> <plugins> <plugin> <artifactId>maven-site-plugin</artifactId> <version>2.0.1</version> </plugin> </plugins> </build>
Note Site deployment to Nexus Professional requires version 2.0.1 or higher of the Maven Site Plugin.
13.1.3
Adding Credentials to Your Maven Settings
When the Maven Site plugin deploys a site to Nexus, it will need to supply the appropriate deployment credentials to Nexus. To congure this, you will need to add credentials to your Maven Settings. Open up your ~/.m2/settings.xml and add the following server conguration to the servers element. If you already have a servers element, just add a new server element with the appropriate id, and password Conguring Deployment Credentials for Nexus Site Deployment
<settings> <servers> <server> <id>nexus-site</id> <username>deployment</username> <password>deployment123</password> </server> </servers> </settings>
Note Conguring Deployment Credentials for Nexus Site Deployment, uses the default deployment user and the default deployment user password. You will need to congure the username and password to match the values expected by your Nexus installation.
13.1.4
Creating a Maven Site Repository
To create a Maven Site Repository, log in as a user with Administrative privileges, and click on "Repositories" under Views/Repositories in the Nexus menu. Under the Repositories tab, click on the Add. . . dropdown and choose "Hosted Repository" as shown in Figure 13.1.
Ed. 3.0.2

169 / 241
Figure 13.1: Adding a Hosted Repository In the New Hosted Repository form, click on the Repository Type dropdown and chose the Maven Site Repository format as shown in Figure 13.2. Although you can use any arbitrary name and identier for your own Nexus repository, for the chapters example, use a Repository ID of "site" and a Repository Name of "Maven Site".
Figure 13.2: Creating a New Maven Site Repository After creating a new Maven Site repository, it should appear in the list of Nexus repositories as shown in Figure 13.3. Note that the Repository Path shown in Figure 13.3, is the same as the repository path referenced in Distribution Management for Site Deployment to Nexus.
Figure 13.3: Newly Created Maven Site Repository
Ed. 3.0.2

170 / 241
13.1.5
Add the Site Deployment Role
In the Maven Settings shown in Conguring Deployment Credentials for Nexus Site Deployment, you congured your Maven instance to use the default deployment user and password. To successfully deploy a site to Nexus, you will need to make sure that the deployment user has the appropriate role and permissions. To add the site deployment role to the deployment user, click on Users under the Security section of the Nexus menu, and then highlight the deployment user as shown in Figure 13.4.
Figure 13.4: Adding the Site Deployment Role to the Deployment User Locate the "Repo: All Maven Site Repositories (Full Control)" role in the Available Roles list, click this role, and drag it over to the Selected Roles list. Once the role is in the Selected Roles list, click on the Save button to update the roles for the deployment user. The deployment user will now have the ability to publish sites to a Maven Site repository.
13.1.6
Publishing a Maven Site to Nexus
To publish a site to a Maven Site repository in Nexus Professional, run mvn site site:deploy from the sample-site/ project created earlier in this chapter. The Maven Site plugin will deploy this site to Nexus using the credentials stored in your Maven Settings.
~/examples/sample-site$ mvn site site:deploy [INFO] Scanning for projects... [INFO] -----------------------------------------------------------------------[INFO] Building sample-site [INFO] task-segment: [site, site:deploy] [INFO] -----------------------------------------------------------------------[INFO] [site:site {execution: default-site}] [INFO] Generating "About" report. [INFO] Generating "Issue Tracking" report. [INFO] Generating "Project Team" report. [INFO] Generating "Dependencies" report.
Ed. 3.0.2

171 / 241
[INFO] Generating "Project Plugins" report. [INFO] Generating "Continuous Integration" report. [INFO] Generating "Source Repository" report. [INFO] Generating "Project License" report. [INFO] Generating "Mailing Lists" report. [INFO] Generating "Plugin Management" report. [INFO] Generating "Project Summary" report. [INFO] [site:deploy {execution: default-cli}] http://localhost:8081/nexus/content/sites/site/ - Session: Opened Uploading: ./css/maven-base.css to http://localhost:8081/nexus/content/sites/site/ #http://localhost:8081/nexus/content/sites/site//./css/maven-base.css \ - Status code: 201 Transfer finished. 2297 bytes copied in 0.052 seconds Uploading: ./css/maven-theme.css to http://localhost:8081/nexus/content/sites/site/ #http://localhost:8081/nexus/content/sites/site//./css/maven-theme.css \ - Status code: 201 Transfer finished. 2801 bytes copied in 0.017 seconds Transfer finished. 5235 bytes copied in 0.012 seconds http://localhost:8081/nexus/content/sites/site/ - Session: Disconnecting http://localhost:8081/nexus/content/sites/site/ - Session: Disconnected [INFO] -----------------------------------------------------------------------[INFO] BUILD SUCCESSFUL [INFO] -----------------------------------------------------------------------[INFO] Total time: 45 seconds [INFO] Finished at: Sat Oct 03 07:52:35 CDT 2009 [INFO] Final Memory: 35M/80M [INFO] ------------------------
Once the site has been published, you can load the site in a browser by going to http://localhost:8081/nexus/content/sites/site/
Figure 13.5: Sample Site Maven Project Web Site
Ed. 3.0.2

172 / 241
Chapter 14
User Account Plugin

Nexus Professionals User Account Plugin allows anonymous users to sign-up for a Nexus account without administrative intervention. This "self-serve" capability for user account creation is especially important when an open source project is using Nexus as a primary means for distribution. In such an environment, there may be hundreds of Nexus users who all need a basic level of read-only access, and making these users wait for an administrator to create an account makes little sense. In such a setting, anyone can create an account, activate the account via a verication email, and then access a repository with a default, read-only level of access which you can dene.
14.1
Installing the User Account Plugin
When you downloaded Nexus Professional, you also download a few optional plugins including the User Account plugin. This plugin is located in the $NEXUS_HOME/runtime/apps/nexus/optional-plugins directory under nexus-user-account-plugin-1.9.2. To install this plugin in Nexus:
Copy the nexus-user-account-plugin-1.9.2/ directory from $NEXUS_HOME/runtime/apps/nexus/optional-plugins to $SONATYPE_W repository Once the optional User Account plugin has been copied to the plugin-repository/ directory, restart Nexus and the User Account plugin will be installed.
14.2
Conguring the User Account Plugin
To congure the User Account Plugin, click on Server under the Administration section of the Nexus menu, and scroll down to the section named "User Sign Up". The User Sign Up section is shown in Figure 14.1.
Ed. 3.0.2

173 / 241
Figure 14.1: Conguring the User Account Plugin To activate the User Sign Up feature, set the "User Sign Up" feature to "On". This will expose a "Sign Up" link next to the "Log In" link in the Nexus user interface. The Selected Roles in this conguration section are the default roles assigned to users who successfully signed up for an account.
14.3
Signing Up for an Account
Once User Sign Up has been activated via the Server settings as shown in Section 14.2, users will see a Sign Up link next to the Log In link in the Nexus interface. This Sign Up link can be seen in the upper right-hand corner of Figure 14.2.
Ed. 3.0.2

174 / 241
Figure 14.2: Sign Up Link Available for All Nexus Users Clicking on this Sign Up link will display the Nexus Sign Up dialog shown in Figure 14.3. This form accepts a username, password, the full name of the new user, and an email account. It also asks the users to type in some text from a captcha form element. If a user cannot read the text in the captcha, they can click on the captcha to refresh it with new text.
Figure 14.3: Nexus Sign Up Form Once the new user clicks on the Sign Up button, they will receive a conrmation dialog which instructs them to check for an activation email.
Ed. 3.0.2

175 / 241
Figure 14.4: Nexus Sign Up Conrmation The user will then receive an email containing an activation link. When a user signs up for a Nexus account, the newly created account is disabled until they click on the activation link contained in this email. A sample of the activation email is shown in Figure 14.5.
Figure 14.5: Nexus Activation Email

Note The example activation email in Figure 14.5, points to localhost:8081. You can change this URL by changing the Base URL setting in the Application Server Settings section of the Server conguration. To change this setting, click on the Server link under Administration in the Nexus menu.
14.4
Manual Activation of New Users
If a user does not receive the activation email after signing up for a new account, an Administrator may need to manually activate a new user. To do this, go to the list of Nexus users by clicking on the Users link under Security in the Nexus menu. Locate and select the new user in the list of Nexus users, and change the Status from Disabled to Enabled as shown in Figure 14.6.
Ed. 3.0.2

176 / 241
Figure 14.6: Nexus Activation Email
14.5
Modifying Default User Permissions
The default user permissions in the User Sign Up feature only includes "UI: Base UI Privileges". If a user signs up with just this simple permission, the only thing they will be able to do is login, change their password, and logout. Figure 14.7, shows the interface a user would see after logging in with only the base UI privileges.
Figure 14.7: User Interface with only the Base UI Privileges
Ed. 3.0.2

177 / 241
To provide some sensible default permissions, click on the Server under the Administration section of the Nexus menu and scroll down to the User Sign Up section of the Server settings. Make sure that the selected default roles for new users contain some ability to browse, search, and view repositories.
Figure 14.8: Selecting Default Roles for New Users

Warning Figure 14.8 shows a default User Sign Up role containing the Nexus Deployment Role. If your server were available to the public this wouldnt be a wise default role as it would allow anyone to sign up for an account, activate an account, and start publishing artifacts to hosted repositories with little or no oversight. Such a default role may only make sense if you are running an internal, corporate instance of Nexus Professional and you are comfortable granting any developer in the organization deployment permissions.
Ed. 3.0.2

178 / 241
Chapter 15
Nexus Atlassian Crowd Plugin

Atlassians Crowd is a single sign-on and identity management product that many organizations use to consolidate user accounts and control which users and groups have access to which applications. Nexus Professional contains an optional security plugin that allows you to congure Nexus to authenticate against an Atlassian Crowd instance. For more information about Atlassian Crowd, go to http://www.atlassian.com/software/crowd/
15.1
Installing the Crowd Plugin
When you downloaded Nexus Professional, you also download a few optional plugins including the Nexus Crowd plugin. This plugin is located in the $NEXUS_HOME/runtime/apps/nexus/optional-plugins directory under security-crowd-realm-1.9.2. To install this plugin in Nexus:
Copy the security-crowd-realm-1.9.2/ directory from $NEXUS_HOME/runtime/apps/nexus/optional-plugins to $SONATYPE_WORK repository Once the optional User Account plugin has been copied to the plugin-repository/ directory, restart Nexus and the User Account plugin will be installed.
15.2
Conguring the Crowd Plugin
Once the Atlassian Crowd plugin is installed, restart Nexus and login as a user with Administrative privileges. To congure the Crowd plugin, click on the Crowd Conguration in the Security section of the Nexus menu as shown in Figure 15.1.
Figure 15.1: Crowd Menu Link under the Security Section of the Nexus Menu Clicking on the Crowd Conguration link will load the form shown in Figure 15.2. This conguration panel contains all of the options that need to be congured to connect your Nexus instance to Crowd for authorization and authentication.
Ed. 3.0.2

179 / 241
Figure 15.2: Crowd Conguration Panel The following sections outline all of the settings in the Crowd Conguration Pane.
15.3
Crowd Access Settings
The Access Settings section of the Crowd conguration is shown in Figure 15.3. This section contains the following elds: Application Name This eld contains the application name of a Crowd application. This value should match the value in the Name eld of the form shown in Figure 15.8. Application Password This eld contains the application password of a Crowd application. This value should match the value in the Password eld of the form shown in Figure 15.8. Crowd Server URL This is the URL of the Crowd Server, this URL should be accessible to the Nexus process as it is the URL that Nexus will use to connect to Crowds SOAP services. Authentication Interval This is the number of minutes that a Crowd authentication is valid for. This value is in units of minutes, and a value of 30 means that Nexus will only require re-authentication if more than 30 minutes have elapsed since a previously authenticated user has accessed Nexus. Use Groups If clicked, Use Groups allows Nexus to use Crowd Groups when calculating Nexus Roles. When selected, you can map a Nexus Role to a Crowd Group.
Ed. 3.0.2

180 / 241
Figure 15.3: Crowd Access Settings
15.3.1
Crowd HTTP Settings
You can control the concurrency of connections to Crowd in the HTTP Settings section shown in Figure 15.4. If you have a hightrafc instance of Nexus, you will want to limit the number of simultaneous connections to the Crowd server to a reasonable value like 20. The HTTP Timeout species the number of milliseconds Nexus will wait for a response from Crowd. A value of zero for either of these properties indicates that there is no limit to either the number of connections or the timeout.
Figure 15.4: Crowd HTTP Settings
15.3.2
Crowd HTTP Proxy Settings
If your Nexus installation is connecting to Crowd via an HTTP Proxy server, the HTTP Proxy Settings section of the Crowd Conguration allows you to specify the host, port, and credentials for a HTTP Proxy server. The HTTP Proxy Settings section is shown in Figure 15.5.
Figure 15.5: Crowd HTTP Proxy Settings
15.3.3
Miscellaneous Settings
The miscellaneous settings section shown in Figure 15.6, allows you to congure settings that control the name of the Single Signon cookie and the various keys that are used to retrieve values that relate to authentication and the auth token. This dialog is only relevant if you have modied optional Crowd settings in your $CROWD_HOME/etc/crowd.properties. For more information about customizing these options see the Atlassian Crowd documentation
Ed. 3.0.2

181 / 241
Figure 15.6: Crowd Miscellaneous Settings
15.4
Adding the Crowd Authentication Realm
Once you have congured Nexus to connect to Crowd, you must select the Crowd authorization realm from the list of available realms in your Nexus Server settings. Figure 15.7, shows the Security settings section in the Nexus Server conguration. To load the Nexus server conguration panel, click on Server under Administration in the Nexus menu. Drag Crowd from the list of available realms to the list of selected realms and then save the Nexus server conguration.
Figure 15.7: Conguring the Crowd Authentication Realm
15.5
Conguring a Nexus Application in Crowd
To connect Nexus to Atlassians Crowd, you will need to congure Nexus as an application in Crowd. To do this, login to Crowd as a user with Administrative rights, and click on the Applications tab. Once you click on this tab, you should see two options under the Applications tab: Search Applications and Add Application. Click on Add Application to display the form shown in Figure 15.8, and create a new application with the following values in the Details tab of the Add Application form: Application Type: Generic Application Name: nexus Description: Sonatype Nexus Professional Choose a password for this application. Nexus will use this password to authenticate with the Crowd server. Click on the Next button.
Ed. 3.0.2

182 / 241
Figure 15.8: Creating a Nexus Crowd Application Clicking on Next will advance the form to the Connection tab shown in Figure 15.9. In this tab you need to supply the URL Nexus and the remote IP address for Nexus. Figure 15.9, shows the Connection form congured for a local instance of Nexus. If you were conguring Crowd and Nexus in a production environment, you would supply the URL that users would use to load Nexus in a web browser and you would supply the IP address that Nexus will be connecting from. Once you have completed the Connection form, click on Next to advance to the Directories form.
Figure 15.9: Creating a Nexus Crowd Application Connection Clicking on Next advances to the Directories form shown in Figure 15.10. In this example, the Nexus application in Crowd is going to use the default "User Management" directory. Click on the Next button to advance to the "Authorisation" form.
Ed. 3.0.2

183 / 241
Figure 15.10: Creating a Nexus Crowd Application Directories Clicking on the Next button advances to the "Authorisation" form shown in Figure 15.11. If any of the directories selected in the previous form contain groups, each group is displayed on this form next to a checkbox. You can select "Allow all users" for a directory, or you can select specic groups which are allowed to authenticate to Crowd through Nexus. This option would be used if you wanted to limit Nexus access to specic subgroups within a larger Crowd directory. If your entire organization is stored in a single Crowd directory, you may want to limit Nexus access to a group that contains only Developers and Administrators.
Figure 15.11: Creating a Nexus Crowd Application Authorization
15.6
Mapping Crowd Groups to Nexus Roles
To map a Crowd Group to a Nexus Role, open up the Roles panel by clicking on the Roles link under the Security section of the Nexus menu. Click on the Add. . . button and select External Role Mapping as shown in Figure 15.12.
Ed. 3.0.2

184 / 241
Figure 15.12: Adding an External Role Mapping Selecting External Role Mapping will show the Map External Role dialog shown in Figure 15.13.
Figure 15.13: Mapping an External Crowd Group to a Nexus Role Once you have mapped a Crowd Group to a Nexus Role, these Roles will appear in the list of Nexus Roles with a mapping value of "Crowd" as shown in Figure 15.14.
Ed. 3.0.2

185 / 241
Figure 15.14: Two Crowd Groups Mapped to Nexus Roles
15.7
Adding a Crowd Role to a Nexus User
To illustrate this feature, consider the crowd-manager user with an id of "brian". This users groups are shown in Figure 15.15.
Figure 15.15: Crowd Groups for User "brian" To add an external user role mapping, open up the Users panel by clicking on Users in the Security section of the Nexus panel.
Ed. 3.0.2

186 / 241
Click on the Add. . . button and select External User Role Mapping from the drop-down as shown in Figure 15.16.
Figure 15.16: Adding an External User Role Mapping Selecting External User Role Mapping will show the dialog shown in Figure 15.17.
Figure 15.17: Locating a Crowd User in the User Role Mapping Dialog Once you locate the Crowd user that you want to add a Nexus Role to. . . You can use the conguration panel shown in Figure 15.18, to add a Role to the Crowd-managed "brian" user.
Ed. 3.0.2

187 / 241
Figure 15.18: Adding a Nexus Role to a Crowd User
Ed. 3.0.2

188 / 241
Chapter 16
Artifact Bundles
Artifact bundles are groups of related artifacts which are all related by the same groupId, artifactId, and version (GAV) coordinate. They are used by projects that wish to upload artifacts to the Maven Central repository. Bundles must contain the following POM elements: modelVersion groupId artifactId packaging name version description url licenses scm url connection
16.1
Creating an Artifact Bundle from a Maven Project
Artifact bundles are created with the Maven Repository Plugin. For more information about the Maven Repository plugin, see http://maven.apache.org/plugins/maven-repository-plugin/ Sample POM Containing all Required Bundle Elements, lists a projects POM which satises all of the constraints that are checked by the Maven Repository plugin. The following POM contains, a description and a URL, SCM information, and a reference to a license. All of this information is required before an artifact bundle can be published to the Maven Central repository. Sample POM Containing all Required Bundle Elements
Ed. 3.0.2

189 / 241
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.sonatype.sample</groupId> <artifactId>sample-project</artifactId> <packaging>jar</packaging> <version>1.0</version> <name>sample-project</name> <description>A Sample Project for the Nexus Book</description> <url>http://books.sonatype.com</url> <licenses> <license> <name>The Apache Software License, Version 2.0</name> <url>http://www.apache.org/licenses/LICENSE-2.0.txt</url> <distribution>repo</distribution> </license> </licenses> <scm> <connection> scm:git:git://github.com/sonatype/sample-project.git </connection> <url>scm:git:git://github.com/sonatype/sample-project.git</url> <developerConnection> scm:git:git://github.com/sonatype-sample-project.git </developerConnection> </scm> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> </dependencies> </project>
To create a bundle from a Maven project, run the repository:bundle-create goal. This goal will check the POM to see if it complies with the standards for publishing a bundle to a public repository, it will then bundle all of the artifacts are generated by a particular build. To build a bundle that only contains the standard, unclassied artifact from a project, run mvn repository:bundle-create. To generate a bundle which contains more than one artifact, run mvn javadoc:jar source:jar repository:bundle-create
~/examples/sample-project$ mvn javadoc:jar source:jar repository:bundle-create [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: javadoc. [INFO] -----------------------------------------------------------------------[INFO] Building sample-project [INFO] task-segment: [javadoc:jar, source:jar, repository:bundle-create] [INFO] -----------------------------------------------------------------------[INFO] [javadoc:jar {execution: default-cli}] Loading source files for package com.sonatype.sample... Constructing Javadoc information... Standard Doclet version 1.6.0_15 Building tree for all the packages and classes... ... [INFO] Preparing source:jar [INFO] No goals needed for project - skipping [INFO] [source:jar {execution: default-cli}] ...
Ed. 3.0.2

190 / 241
TESTS
Running com.sonatype.sample.AppTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.03 sec Results : Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO] [INFO] [INFO] 0.) 1.) 2.) 3.) [jar:jar {execution: default-jar}] Building jar: ~/temp/sample-project/target/sample-project-1.0.jar [repository:bundle-create {execution: default-cli}] The following files are marked for inclusion in the repository bundle:
Done sample-project-1.0.jar sample-project-1.0-javadoc.jar sample-project-1.0-sources.jar
Please select the number(s) for any files you wish to exclude, or 0 when \ youre done. Separate the numbers for multiple files with a comma (,). Selection: 0 [INFO] Building jar: ~/temp/sample-project/target/sample-project-1.0-bundle.jar [INFO] -----------------------------------------------------------------------[INFO] BUILD SUCCESSFUL [INFO] -----------------------------------------------------------------------[INFO] Total time: 11 seconds [INFO] Finished at: Sat Oct 10 21:24:23 CDT 2009 [INFO] Final Memory: 36M/110M [INFO] ------------------------------------------------------------------------
Once the bundle has been created, there will be a bundle JAR in the target/ directory. As shown in the following command output, the bundle JAR contains: a POM, the projects unclassied artifact, the javadoc artifact, and the sources artifact.
~/examples/sample-project$ cd target ~/examples/sample-project/target$ jar tvf sample-project-1.0-bundle.jar 0 Sat Oct 10 21:24:24 CDT 2009 META-INF/ 98 Sat Oct 10 21:24:22 CDT 2009 META-INF/MANIFEST.MF 1206 Sat Oct 10 21:23:46 CDT 2009 pom.xml 2544 Sat Oct 10 21:24:22 CDT 2009 sample-project-1.0.jar 20779 Sat Oct 10 21:24:18 CDT 2009 sample-project-1.0-javadoc.jar 891 Sat Oct 10 21:24:18 CDT 2009 sample-project-1.0-sources.jar
16.2
Uploading an Artifact Bundle to Nexus
To upload an artifact bundle to Nexus Professional, select Staging Upload from the Enterprise section of the Nexus menu as shown in Figure 16.1.
Ed. 3.0.2

191 / 241
Figure 16.1: Staging Upload Link Selecting the Staging Upload link will load the Staging Upload dialog. Choose Artifact Bundle form the Upload Mode dropdown the Staging Upload panel will switch to the form shown in Figure 16.2. Click on Select Bundle to Upload. . . and then select the JAR that was created with the Maven Repository plugin used in the previous sections. Once a bundle is selected, click on Upload Bundle.
Figure 16.2: Uploading an Artifact Bundle After uploading the Artifact Bundle, click on the Staging link in the Enterprise section of the Nexus menu as shown in Figure 16.1. Click on Staging will load a list of all the dened staging proles. Click on the rst default proles named "Release Staging Prole", and you should see that the Staging Artifact Upload created and closed a new staging repository as shown in Figure 16.3. This repository contains all of the artifacts contained in the uploaded bundle. It allows you to promote or drop the artifacts contained in a bundle as a single unit.
Ed. 3.0.2

192 / 241
Figure 16.3: Staging Repository Created for Artifact Bundle Upload To promote a staging repository, right click on the closed repository shown in Figure 16.3, and select "Promote". Once you select promote, Nexus will present the Promote Staged Repository dialog shown in Figure 16.4. Select the repository that you want to published the staging repository to, and click on the Promote button.
Figure 16.4: Promoting a Staged Repository After promotion, Nexus will then display a conrmation that the promotion was completed successfully as shown in Figure 16.5.
Ed. 3.0.2

193 / 241
Figure 16.5: Conrmation that Staged Repository has been Promoted
Ed. 3.0.2

194 / 241
Chapter 17
Nexus Best Practices

17.1 Introduction
Once you decide to install a Repository Manager, the next decision is how to setup your repositories, particularly if you have multiple teams sharing the same instance. Nexus is very exible in this area and supports a variety of congurations. Ill rst describe the options and then discuss the thought process used to decide what makes sense for your organization.
17.2
Repositories per Project/Team
The rst and most obvious way to support multiple teams is to congure a pair of repositories per team (one release, one snapshot). The team is then given the appropriate C.R.U.D. permissions and they are able to use the system for their artifacts. Our http://oss.sonatype.org instance is for the most part congured in this manner, where each project like Jetty has their own repositories separate from everyone else.
17.3
Partition Shared Repositories
Another option is to have a single (or a few) pair of Release/Snapshot repositories for your entire organization. In this case, the access is controlled by a mechanism we call "Repository Targets." Simply put, a Repository Target is a way to manage a set of artifacts based on their paths. A Repository Target is simply a list of regular expressions and a Name. For example, a Repo Target for Maven would be "./org/apache/maven/. and Nexus OSS would be "./org/sonatype/nexus/."
Note While it is most common to manage artifacts based on the path of their groupId, the Regular Expression is matched against the entire path, and so it is also possible, for example, to dene "Sources" as ".*-sources.jar" . . . its also worth noting that Repository Targets are not mutually exclusive. It is perfectly valid for a given path to be contained by multiple targets.
In this model, you would create a Repo Target for each project in your system. You are then able to take the Repo Target and associate it with one or more Repositories or Groups in your system. When you do this, new, specic, C.R.U.D. privileges are created. For example, I could take the Maven Repo target, associate it with my Release and Snapshot repository, and now I get privileges I can assign to Create, Read, Update, Delete "Maven" (./org/apache/maven/.) artifacts in my Release and Snapshot repositories. This method is used to manage the http://repository.apache.org instance, where we have just one Release and Snapshot repository and each project team gets permissions to their artifacts based on the path.
Ed. 3.0.2

195 / 241
17.3.1
Selecting an Approach
First of all, these choices arent mutually exclusive. In fact, the rst option builds upon the default Repository Target of ".*" which simply gives you access to all artifacts regardless of the path. You still associate the default Repo Target with specic repositories to create the assignable privileges In general, its my opinion that fewer repositories will scale better and are easier to manage. Its also easier to start off with a single pair of repos, with the default "All M2″ (.*) target and simply rene the permissions as you scale. Most things that are congured per repository (Cache, Storage location, Snapshot purging, etc) will generally be applicable for all projects, so this mode avoids the duplication of these tasks. Since everything will be stored together in a single folder on disk, it makes backups easier as well. The reasons why you would want multiple sets of repositories is essentially the opposite of above: If you need different expiration, Snapshot purging or storage folders, then a single shared repo wont work. Replication and failover strategies may also make this method easier to support. If you absolutely must maintain total separation between Project teams, i.e. they cant read each others artifacts, then this solution might be more applicable as well. (but is still possible with Repo Targets. . . just grant Read to only the appropriate targets) In Summary, Nexus allows you to control the security of your artifacts based on the repository and/or the path of the artifact, meaning it is possible to slice and dice the system any way you see t. My default position is to use a few Hosted Repositories as possible and control the permissions by the Repository Target.
Ed. 3.0.2

196 / 241
Chapter 18
Developing Nexus Plugins

Among the many benets of using an technology with an open source core is the ability to customize behavior and create extensions. To this end, Sonatype has spent a great deal of time designing an intuitive Plugin API that will allow you to take Nexus where you need it to go. This chapter summarizes some of these extension points and presents a walk through of how you would start to develop your own Nexus plugins. Our community has already created a number of compelling and useful plugins, some of which have been integrated into the set of plugins that are distributed with both Nexus Open Source and Nexus Professional. Sonatype tried to make the Plugin API as lightweight and extensible as possible with the following goals in mind: Providing a clear set of extension points for plugin developers Providing isolated plugin classpaths to avoid compatibility issues between plugins and to prevent a plugin from disturbing another, unrelated part of Nexus. Giving developers the ability to load and unload Nexus plugins at runtime
18.1
Nexus Plugins
The Nexus API is contained in a module named nexus-api. If you are developing a Nexus plugin, you will need to familiarize yourself with the extension points that are dened in this project.
18.1.1
Nexus Plugin API
Nexus provides an extra module for plugin developers - the "nexus-plugin-api". This module provides some extra annotations for plugins developers, and it allows a plugin developer to implement a plugin without having to know anything about Plexus or Nexus internals. The Plugin API uses the @Inject annotation, an emerging standard for dependency injection which allows Nexus plugins to be developed in a way that is container-neutral. The Nexus Plugin API introduces some annotations to make things easier:
@Managed
When a @Managed annotation is present on an interface, it marks the interface as "component contract" (Plexus role). Any non-abstract classes implementing it will be made managed by current container.
@RepositoryType
Used on interfaces, to mark it as new repository type, and to be registered with other core repository types in Nexus Repository Type Registry. It holds the basic information about the new type (the path where to mount it).
Ed. 3.0.2

197 / 241
@RestResource
Used on classes, to mark them as REST Resources.
18.2
Nexus Extension Points
The simplest Nexus plugin contain a single class, SampleEventInjector, which contributes an EventInspector to Nexus Application. This simple event inspector will do nothing more than print a message every time it accepts and inspects an event. A Simple Event Inspector
package org.sample.plugin; import javax.inject.Inject; import org.sonatype.nexus.proxy.events.EventInspector; import org.sonatype.plexus.appevents.Event; public class SampleEventInspector implements EventInspector { public boolean accepts( Event<?> evt ) { return true; } public void inspect( Event<?> evt ) { System.out.println( "invoked with event: " + evt.toString() + " with sender " + evt.getEventSender().toString() ); } }
During the build of this nexus plugin, this class is compiled and then scanned for concrete classes that implement extension point interfaces dened in the following section. The EventInspector interface in the nexus-api project has been marked with the @ExtensionPoint annotation. The plugin build takes the @ExtensionPoint, @Named, and @Inject annotations that may be present and generates a plugin descriptor which is packaged in the plugins JAR. When the plugin is present in Nexus during startup, the Nexus plugin manager reads the plugin metadata and instantiates the appropriate components. To implement a plugin, you simply implement some of these interfaces.
18.3
Nexus Plugin Extension Points
The following sections outline the available Nexus extension points.
18.4
Nexus Plugin Extension
Interface: org.sonatype.nexus.plugins.NexusPlugin This extension component is meant to be used in Nexus plugins only. If it is found in a plugin, it will be invoked during install/uninstall/init phases of a plugin installation/uninstallation/initialization. Typical usage would be a need to perform some specic tasks on plugin install (ie. it uses native code to do some magic and those needs to be copied somewhere, register them with OS, etc).
Ed. 3.0.2

198 / 241
18.5
Nexus Index HTML Customizer
Interface: org.sonatype.nexus.plugins.rest.NexusIndexHtmlCustomizer This extension is able to customize the "index.html" returned by Nexus. Using this component, a plugin is able to add markup or Javascript to the pages generated by the Nexus web application. Every plugin that has a UI component uses this extension point to add Javascript customizations to the interface.
18.6
Static Plugin Resources
Interface: org.sonatype.nexus.plugins.rest.NexusResourceBundle This extension gathers and publishes static resources over HTTP. These resources are usually JS les, CSS les, images, etc. Plugin developers do not need to use this extension directly since some of the features it exposes are automatic for all plugins. When the Nexus plugin manager discovers resources in plugin JAR under the path "/static", the Plugin Manager will create a special "plugin NexusResourceBundle" component on the y. If you do not want the plugin manager to automatically add a resource bundle you can dene your own resource bundle implementation. The plugin manager will not add a resource bundle if: no resources found on "/static" path within plugin classpath, or a user created component of NexusResourceBundle exists within plugin
The "default plugin" resource bundle component uses MimeUtil from core to select MIME types of resources found within plugin, and will use same path to publish them (ie. in plugin JAR "/static/image.png" will be published on "http://nexushost/nexus/static/image.pn
18.7
Plugin Templates
Interface: org.sonatype.nexus.templates.TemplateProvider Template provider is a component providing repository templates to Nexus. Every plugin which provides a "new" repository type should add a TemplateProvider as it is the only way to instantiate a repository instance. The core of Nexus provides a "default" template provider with templates for all core repository types, and all custom repository plugins (P2, OBR) provide template providers for their types.
18.8
Event Inspectors
Interface: org.sonatype.nexus.proxy.events.EventInspector Event inspectors are used to inspect events in Nexus. One example of where this extension point is used is the index generation. To generate a Nexus index, there is an event inspector which listens for RepositoryItemEvent subclasses and updates the index in response to repository activity.
18.9
Content Generators
Interface: org.sonatype.nexus.proxy.item.ContentGenerator A content generator is a component that is able to generate content dynamically, on the y, instead of just serving a static resource. The content generator is registered to respond to a path that corresponds to a le. When the resource is retrieved, Nexus discards the le content and uses the registered content generator to generate content. The Nexus Archetype plugin uses a content generator to generate the archetype-catalog.xml. Every time a client requests the archetype-catalog.xml, the archetype catalog is generated using information from the index.
Ed. 3.0.2

199 / 241
18.10
Content Classes
Interface: org.sonatype.nexus.proxy.registry.ContentClass Content class controls the compatibility between repository types. It denes the type of content that can be stored in a repository, and it also affects how repositories can be grouped into repository groups. Every plugin contributing a new repository type should provide an instance of this extension point. Nexus has a ContentClass implementation for every core supported repository type, and the P2 and OBR plugins dene custom ContentClass implementations.
18.11
Storage Implementations
Interface: org.sonatype.nexus.proxy.storage.local.LocalRepositoryStorage Interface: org.sonatype.nexus.proxy.storage.remote.RemoteRepositoryStorage A plugin developer can override the default le-based local repository storage and the default remote HTTP repository storage interface. If your plugin needs to stores repository artifacts and information in something other than a lesystem, or if your remote repository isnt accessible via HTTP, your plugin would provide an implementation of one of these interfaces. Nexus provides one of the each: a le-system LocalRepositoryStorage and CommonsHttpClient 3.x based RemoteRepositoryStorage.
18.12
Repository Customization
Interface: org.sonatype.nexus.plugins.RepositoryCustomizer This extension component will be invoked during conguration of every Repository instance, and may be used to add some "extra" conguration to repositories The procurement plugin uses this mechanism to "inject" RequestProcessor that will evaluate rules before allowing execution of request.
18.13
Item and File Inspectors
Interface: org.sonatype.nexus.proxy.attributes.StorageItemInspector Interface: org.sonatype.nexus.proxy.attributes.StorageFileItemInspector Attribute storage ItemInspectors are able to "decorate" items in repositories with custom attributes. Every le stored/cached/uploaded in Nexus will be sent to these components for inspection and potentially decoration. The StorageItemInspector will get all item types for inspection (le, collections, links), while StorageFileItemInspector will get only le items. Currently only one ItemInspector is used in Nexus: the checksumming inspector, that decorates all le items in Nexus with SHA1 checksum and stores it into item attributes.
18.14
Nexus Feeds
Interface: org.sonatype.nexus.rest.feeds.sources.FeedSource To add new RSS feeds, a plugin may provide implementation of this extension point. Nexus provides implementation for all the "core" RSS feeds.
18.15
Nexus Tasks and Task Conguration
Interface: org.sonatype.nexus.scheduling.NexusTask<T> Interface: org.sonatype.nexus.tasks.descriptors.ScheduledTaskDescriptor
Ed. 3.0.2

200 / 241
NexusTask is an extension point to implement new Nexus Scheduled Tasks. If a contributed task needs UI, then the plugin which provides the NexusTask should provide a ScheduledTaskDescriptor which allows the UI customization for the task creation and management interface.
18.16
Application Customization
Interface: org.sonatype.nexus.rest.NexusApplicationCustomizer This extension component is able to intercept URLs routed in the Nexus REST API layer.
18.17
Request Processing
Interface: org.sonatype.nexus.proxy.repository.RequestProcessor This extension point can affect how a repository reacts to an item request.
18.18
Using the Nexus Plugin Archetype
To create a new Nexus Plugin, you can use the Nexus Plugin Archetype by running archetype:generate with the following identiers: archetypeGroupId org.sonatype.nexus.archetypes archetypeArtifactId nexus-plugin-archetype archetypeVersion 1.2 Once you run archetype:generate, you will be prompted for the groupId, artifactId, version, and package name for the generated project.
$ mvn archetype:generate -DarchetypeGroupId=org.sonatype.nexus.archetypes \ -DarchetypeArtifactId=nexus-plugin-archetype \ -DarchetypeVersion=1.2 [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: archetype. [INFO] -----------------------------------------------------------------------[INFO] Building Maven Default Project [INFO] task-segment: [archetype:generate] (aggregator-style) [INFO] -----------------------------------------------------------------------[INFO] Preparing archetype:generate [INFO] No goals needed for project - skipping [INFO] Setting property: resource.loader => classpath. [INFO] Setting property: resource.manager.logwhenfound => false. [INFO] [archetype:generate {execution: default-cli}] [INFO] Generating project in Interactive mode Define value for groupId: : org.sonatype.book.nexus Define value for artifactId: : sample-plugin Define value for version: 1.0-SNAPSHOT: : Define value for package: org.sonatype.book.nexus: : Confirm properties configuration: nexus-version: 1.4.0-SNAPSHOT groupId: org.sonatype.book.nexus
Ed. 3.0.2

201 / 241
artifactId: sample-plugin version: 1.0-SNAPSHOT package: org.sonatype.book.nexus Y: : [INFO] -----------------------------------------------------------------------[INFO] BUILD SUCCESSFUL [INFO] -----------------------------------------------------------------------[INFO] Total time: 25 seconds [INFO] Finished at: Wed Oct 21 14:39:03 CDT 2009 [INFO] Final Memory: 13M/80M [INFO] ------------------------------------------------------------------------
Once the Archetype plugin has created the project, you will have a project with the layout shown in Figure 18.1.
Figure 18.1: Layout of a Nexus Plugin Project The generated project contains the following classes: org.sonatype.book.nexus.XYVirusScanner An implementation of the VirusScanner Interface org.sonatype.book.nexus.VirusScannerRequestProcessor A class which customizes the request handling process in Nexus org.sonatype.book.nexus.VirusScannerRepositoryCustomizer A class which customizes the repositories affected by the VirusScanner org.sonatype.book.nexus.VirusScanner A VirusScanner interface described in Section 18.21. org.sonatype.book.nexus.events.InfectedItemFoundEvent A simple event which is red by the VirusScanner
18.19
Set the Target Nexus Version
To set the target Nexus version of the new Nexus Plugin project, you will need to edit this new projects POM. Open up the POM of your Nexus Plugin and nd the section that denes properties. You will need to change the nexus-version property to target a Nexus version. After creating a project with the Nexus Plugin archetype, you will see a properties section of the POM that contains a "nexusVersion".
Ed. 3.0.2

202 / 241
<project> ... <properties>  <nexus-version>${nexusVersion}</nexus-version> </properties> ... </project>
To target a version of Nexus, change "nexusVersion" to a Nexus version number. The following program listing shows a properties section in the generated POM which targets version 1.4.1 of Nexus.
<project> ... <properties>  <nexus-version>1.4.1</nexus-version> </properties> ... </project>
18.20
Building a Nexus Plugin Project
To build your Nexus plugin project, just run mvn install in the newly generated project directory. Once the build is completed, your plugins JAR will be available in the projects target/ The Nexus Plugin project, as created by the Nexus Plugin archetype, depends on a number of artifacts which may not be available from the Maven Central repository. If you experience missing artifacts during your Nexus plugin project build, you should make sure that the following repositories are added to your environment: The Sonatype Forge Repository: http://repository.sonatype.org/content/groups/forge The Codehaus Snapshot Repository: http://snapshots.repository.codehaus.org If you experience any difculty with the build, you may also want to remove the section of the generated POM that is labeled with the #ITSet label. If you are using Nexus, and you have congured your build to work against a public group, you will want to make sure that you have added both of the repositories listed above to your public group. You will also want to make sure that the Repository Policy setting for the Sonatype Forge Repository is set to "Release".
18.21
Creating a Complex Plugin
In this section, we will step through a skeletal, sample project that implements a virus scanner plugin for Nexus. This plugin will consist of: A managed "virus scanner" component A RequestProcessor that sends all "incoming" artifacts for scanning A repository customizer to inject a RequestProcessor to all proxy repositories We start with creating a @Managed component contract for the VirusScanner. While this class could just as easily be a nonmanaged component, this example uses the @Managed and @Singleton annotations to demonstrate dependency injection. VirusScanner Interface
Ed. 3.0.2

203 / 241
package org.sonatype.book.nexus; import javax.inject.Singleton; import org.sonatype.nexus.proxy.item.StorageFileItem; import org.sonatype.plugin.Managed; @Managed @Singleton public interface VirusScanner { boolean hasVirus( StorageFileItem file ); }
Once we have the interface for VirusScanner, we need to dene a named instance XYVirusScanner which implements the interface. The following example shows how the @Named annotation is used to assign a name of "XY" to this implementation. XYVirusScanner Implementation
package org.sonatype.book.nexus; import javax.inject.Named; import org.sonatype.nexus.proxy.item.StorageFileItem; @Named( "XY" ) public class XYVirusScanner implements VirusScanner { public boolean hasVirus( StorageFileItem file ) { // DO THE JOB HERE System.out.println( "Kung fu VirusScanner --- " + "scanning for viruses on item: " + file.getPath() ); // simulating virus hit by having the filename // contain the "infected" string return file.getName().contains( "infected" ); } }
The next class is a request processor which virus scans an artifact before it is cached locally. If a virus is found in an artifact, this plugin will refuse to cache the artifact and trigger an event which will signal that a virus was found in a le item. Note the use of @Named which assigns the name "virusScanner" to this component. Also note the two uses of @Inject. The rst use of @Inject will fetch the default implementation of ApplicationEventMulticaster, and the second use of @Inject will fetch the "XY" virus scanner. Virus Scanning Request Processor
package org.sonatype.book.nexus; import javax.inject.Inject; import javax.inject.Named; import import import import import import import import org.sonatype.book.nexus.events.InfectedItemFoundEvent; org.sonatype.nexus.proxy.ResourceStoreRequest; org.sonatype.nexus.proxy.access.Action; org.sonatype.nexus.proxy.item.AbstractStorageItem; org.sonatype.nexus.proxy.item.StorageFileItem; org.sonatype.nexus.proxy.repository.ProxyRepository; org.sonatype.nexus.proxy.repository.Repository; org.sonatype.nexus.proxy.repository.RequestProcessor;
Ed. 3.0.2

204 / 241
import org.sonatype.plexus.appevents.ApplicationEventMulticaster; @Named( "virusScanner" ) public class VirusScannerRequestProcessor implements RequestProcessor { @Inject private ApplicationEventMulticaster applicationEventMulticaster; @Inject private @Named( "XY" ) VirusScanner virusScanner; // @Inject // private @Named("A") CommonDependency commonDependency; public boolean process( Repository repository, ResourceStoreRequest request, Action action ) { // Check dependency // System.out.println( "VirusScannerRequestProcessor " + "--- CommonDependency data: " + commonDependency.getData() // ); // dont decide until have content return true; } public boolean shouldProxy( ProxyRepository repository, ResourceStoreRequest request ) { // dont decide until have content return true; } public boolean shouldCache( ProxyRepository repository, AbstractStorageItem item ) { if ( item instanceof StorageFileItem ) { StorageFileItem file = (StorageFileItem) item; // do a virus scan boolean hasVirus = virusScanner.hasVirus( file ); if ( hasVirus ) { applicationEventMulticaster .notifyEventListeners( new InfectedItemFoundEvent( item .getRepositoryItemUid().getRepository(), file ) ); } return !hasVirus; } else { return true; } } }
Ed. 3.0.2

205 / 241
The last extension is RepositoryCustomizer, that simply injects our virus scanner RequestProcessor into proxy repositories only (the only way to get an artifact into Nexus from uncontrolled Internet. Local uploads are considered "safe" for this example). Note how the request processor is injected into this repository customizer with @Inject and @Named. The Virus Scanner Repository Customizer
package org.sonatype.book.nexus; import javax.inject.Inject; import javax.inject.Named; import import import import import org.sonatype.configuration.ConfigurationException; org.sonatype.nexus.plugins.RepositoryCustomizer; org.sonatype.nexus.proxy.repository.ProxyRepository; org.sonatype.nexus.proxy.repository.Repository; org.sonatype.nexus.proxy.repository.RequestProcessor;
public class VirusScannerRepositoryCustomizer implements RepositoryCustomizer { @Inject private @Named( "virusScanner" ) RequestProcessor virusScannerRequestProcessor; public boolean isHandledRepository( Repository repository ) { // handle proxy reposes only return repository.getRepositoryKind() .isFacetAvailable( ProxyRepository.class ); } public void configureRepository( Repository repository ) throws ConfigurationException { repository.getRequestProcessors() .put( "virusScanner", virusScannerRequestProcessor ); } }
18.22
Nexus Plugin Descriptor Maven Plugin
Nexus plugins have a custom packaging "nexus-plugin" which is introduced by the NexusPD Maven Plugin. A "nexus-plugin" packaged plugin: is a plain JAR has a META-INF/nexus/plugin.xml embedded Nexus Plugin Metadata embedded has static resources embedded into the plugin JAR The NexusPD Maven plugin introduces a new project path (ie. src/main/static-resources). Static resources such as JS les, images, and CSS which are referenced in
18.23
The Nexus Plugin Descriptor
Every Nexus plugin has a plugin descriptor which is generated during the build process for a plugin. This plugin descriptor is packaged with the plugin JAR and can be found in $basedir/target/classes/META-INF/nexus/plugin.xml A Nexus Plugin Descriptor
Ed. 3.0.2

206 / 241
<plugin> <modelVersion>1.0.0</modelVersion> <groupId>org.sonatype.sample</groupId> <artifactId>sample-plugin</artifactId> <version>1.0-SNAPSHOT</version> <name>Nexus Plugin Archetype</name> <applicationId>nexus</applicationId> <applicationEdition>OSS</applicationEdition> <applicationMinVersion>1.4.0</applicationMinVersion> </plugin>
If your Nexus plugin has any dependencies, they will be included in this plugin descriptor automatically. For example, if the Nexus plugin you were developing had a dependency on commons-beanutils version 1.8.2, your plugin descriptor will incude the following classpathDependency
<plugin> <modelVersion>1.0.0</modelVersion> <groupId>org.sonatype.book.nexus</groupId> <artifactId>sample-plugin</artifactId> <version>1.0-SNAPSHOT</version> <name>Nexus Plugin Archetype</name> <applicationId>nexus</applicationId> <applicationEdition>OSS</applicationEdition> <applicationMinVersion>1.4.0</applicationMinVersion> <classpathDependencies> <classpathDependency> <groupId>commons-beanutils</groupId> <artifactId>commons-beanutils</artifactId> <version>1.8.2</version> <type>jar</type> </classpathDependency> </classpathDependencies> </plugin>
18.24
Dening Custom Repository Types
When you need to introduce a custom repository type, you should implement the Repository interface. The following example extends the HostedRepository class and adds a repository type with the path prex "sample". Creating a Custom Repository Type Interface
package org.sample.plugin; import org.sonatype.nexus.plugins.RepositoryType; import org.sonatype.nexus.proxy.repository.HostedRepository; @RepositoryType( pathPrefix="sample" ) public interface SampleRepository extends HostedRepository { String boo(); }
If you want to implement a custom repository type, you should reference the nexus-proxy module as dependency which contains the AbstractRepository class which is a useful superclass for repository implementations. To implement the SampleRepository interface, you can then extend the AbstractRepository as shown in the following example. Creating a Custom Repository Type Implementation
package org.sample.plugin;
Ed. 3.0.2

207 / 241
public class DefaultSampleRepository extends AbstractRepository implements SampleRepository { .... implement it }
Your newly introduced repository type will appear under http://localhost:8081/nexus/content/sample/.
Ed. 3.0.2

208 / 241
Appendix A
Migrating to Nexus from Artifactory

A.1 Introduction
This appendix walks you through the process of using the Nexus Migration Plugin to migrate an existing Artifactory installation to a new Nexus installation. The Nexus Migration Plugin can read an Artifactory System Export archive and recreate groups and repositories based on your existing Artifactory installation. Once the migration is completed, the Nexus Artifactory Bridge will then serve repository artifacts to clients using a web application, exposing the same artifacts to clients using the same URLs and repository identier that they referenced in your legacy Artifactory installation. This Nexus Migration plugin offers an easy, drop-in replacement for Artifactory.
A.2
Creating an Artifactory Backup
The Nexus Migration Plugin relies on the Artifactory System Export which is an ZIP archive containing all of the conguration and data for an Artifactory installation. To generate this export, log in as an administrative user in Artifactory, and click on the SystemImport & Export in the left navigation menu. Clicking on this link will show the Entire System Export & Import screen as shown in Figure A.1.
Ed. 3.0.2

209 / 241
Figure A.1: Creating an Artifactory System Export This appendix assumes that Artifactory has been installed in the directory /usr/local/artifactory-2.2.5. To create a backup ZIP archive in that same directory: Enter /usr/local/artifactory-2.2.5 into the Target export dir eld. If you are on a Windows platform, or if you have installed Artifactory in a different path, enter the path at which Artifactory is installed. Check the Create a zip archive (slow!) checkbox as shown in Figure A.1. Click the Export When you click the Export button, Artifactory is going to create a timestamped ZIP archive in the specied directory. In this example, Artifactory creates a le named /usr/local/artifactory-2.2.5/20100222.154349.zip. Once this step is completed, you will no longer need to run Artifactory, and you can safely shut it down. In the next section you will learn how to install the Nexus Migration Plugin.
A.3
Installation of the Migration Plugin and Artifactory Bridge
The migration plugin is a free, open-source plugin that can be downloaded by visiting http://nexus.sonatype.org/downloads/ and downloading nexus-migration-plugin-packaging-1.5-webapp.zip.
Note This section assumes that you have just downloaded and installed Nexus Open Source or Nexus Professional. If you havent installed Nexus, you should make a bookmark for this section and jump to Chapter 3. Once you have installed Nexus, return to this section and install the Nexus Migration Plugin.
The following screen listing shows a series of commands which can be used to install the Nexus Migration plugin into an existing Nexus installation. This listing assumes that the environment variable $NEXUS_HOME points to an existing Nexus installation. Download the Nexus Migration plugin, copy the distribution archive to the Nexus installation folder, and unpack it. This archive will install the necessary applications and plugins to enable a smooth migration from Artifactory to Nexus.
Ed. 3.0.2

210 / 241
$ wget http://nexus.sonatype.org/downloads/\ nexus-migration-plugin-packaging-1.5-webapp.zip ... Resolving repository.sonatype.org... 63.246.20.88 Connecting to repository.sonatype.org|63.246.20.88|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 280179 (274K) Saving to: nexus-migration-plugin-packaging-1.5-webapp.zip 100%[======================================>] 280,179 406K/s in 0.7s
2009-03-14 15:03:52 (406 KB/s) - \ nexus-migration-plugin-packaging-1.5-webapp.zip saved [280179/280179] $ cp nexus-migration-plugin-packaging-1.5-webapp.zip ${NEXUS_HOME} $ cd ${NEXUS_HOME} $ unzip nexus-migration-plugin-packaging-1.5-webapp.zip Archive: nexus-migration-plugin-packaging-1.5-webapp.zip creating: runtime/ creating: runtime/apps/ creating: runtime/apps/artifactory-bridge/ creating: runtime/apps/artifactory-bridge/webapp/ creating: runtime/apps/artifactory-bridge/webapp/WEB-INF/ inflating: runtime/apps/artifactory-bridge/webapp/WEB-INF/web.xml creating: conf/ inflating: conf/jetty.xml creating: runtime/apps/nexus/ creating: runtime/apps/nexus/plugin-repository/ creating: .../nexus-migration-plugin-artifactory-1.2/ ... creating: runtime/apps/nexus/lib/ inflating: .../nexus-migration-plugin-configuration-1.2.jar inflating: .../nexus-migration-plugin-artifactory-bridge-1.2.jar
Warning The Nexus Migration plugin archive contains a copy of conf/jetty.xml. If you have customized jetty.xml you will want to make a backup of your customized jetty.xml before you install this Migration plugin. Most people using the Nexus Migration plugin are going to be setting up a new instance of Nexus so this shouldnt be an issue.
Once the Nexus Migration plugin has been installed, start up Nexus and go to the Nexus URL. If you are just setting up Nexus, and youve skipped the installation chapter, the default Nexus URL is http://localhost:8081/nexus and the default administrative username/password combination is "admin" and "admin123". If the Nexus Migration Plugin is installed properly, you should see the Artifactory Import link under Administration in the Nexus application menu as shown in Figure A.2.
Ed. 3.0.2

211 / 241
Figure A.2: Artifactory Import Panel from the Nexus Migration Plugin
A.4
Importing an Artifactory System Backup
To import the backup created in Section A.2, enter the path to the Artifactory system backup archive in the Artifactory Import panel as shown in Figure A.3. This path references a lesystem path on the same server that is running Nexus.
Note Please note that the lesystem path in Step 1 of the Artifactory Import process references a path on the same server that is running Nexus. This eld is not a le upload eld, and you are not uploading the Artifactory System Backup archive from your local machine to the server. The Artifactory system export archive can be rather large, and the assumption of the Nexus Migration plugin is that you are installing Nexus on the same server that had previously run Artifactory. If you are not installing Nexus on the same server, you must upload the Artifactory System Backup ZIP le to the Nexus server prior to typing in the lesystem path shown in Figure A.3.
Ed. 3.0.2

212 / 241
Figure A.3: Specifying the Artifactory System Backup Path Click the Import button, and Nexus will then examine the Artifactory System Backup archive and populate elds in Step 2 of the Artifactory Import panel.
A.5
Conguring the Artifactory Import
Once the System Backup has been imported, the Nexus Migration plugin will populate the Groups, Repositories, and Users tables in Step 2 of the Artifactory Import panel as shown in Figure A.4. These tables and form elements allow you to customize which repositories and groups are going to be imported into Nexus and how Nexus will congure corresponding repositories. The following sections describe each of these conguration tables in detail.
Ed. 3.0.2

213 / 241
Figure A.4: Conguring the Artifactory Import
A.6
Conguring Artifactory Group Imports
The groups table displays all of the groups contained in the Artifactory system backup. By default, all groups are selected. If you wish to omit an Artifactory group from the import process, deselect the checkbox for that group in the Import column. Each groups content type resolution is shown in the Content Type Resolution column. Changing the content type resolution will control how Nexus congures the Nexus Group that corresponds to each Artifactory Group.
Ed. 3.0.2

214 / 241
Figure A.5: Conguring Artifactory Group Imports
A.7
Conguring Artifactory Repository Imports
The second table in Step 2 of the Artifactory Import panel is the Repositories panel. In this panel you can select repositories to import and also congure how Artifactory proxy repositories would be mapped to Nexus proxy repository with matching canonical URLs. Each row in the Repositories table contains the following columns: Import This column contains a simple checkbox. If the checkbox is checked, the repository will be imported into Nexus. If the checkbox is not check, the Nexus Migration plugin will omit the repository from the import process. Repository ID This is the repository identier from Artifactory. This column cannot be edited. Type This is the type of the repository being imported. Hosted repositories in Artifactory will be imported as hosted repositories in Nexus. Proxy repositories in Artifactory will be imported as proxy repositories in Nexus unless they are merged with an existing proxy repository. Map URLs Since Nexus is a drop-in replacement for Artifactory, the Nexus Migration Plugin gives you the option to Map the legacy Artifactory URLs to the newer Nexus URLs. Checking this box will tell the Nexus Migration plugin to create the appropriate URL mappings to allow clients to interact with the newly created Nexus repositories via the legacy Artifactory URLs. Copy Cached Artifacts Checking this box will tell the Nexus Migration plugin to copy the cache contents of a proxy repository to the newly created Nexus repository. Leaving this box unchecked will tell the Nexus Migration plugin to only copy the conguration for a proxy repository. Releases/Snapshots This allows you to customize the Repository Policy in a newly created Nexus repository. If you want a hosted or proxy repository to serve only release or snapshot versions, select the corresponding value in the dropdown. If you want a host or proxy repository to serve both release and snapshot versions, select both in this dropdown list. If you want Nexus to use the type implied by the Artifactory repository, dont select a value in this dropdown. Merge With If an Artifactory proxy repository has a canonical URL which matches the canonical URL of an existing Nexus repository, you can merge this proxy repository into the existing Nexus proxy repository. Most people running the Artifactory Import process will likely have a repo1 proxy repository in Artifactory for the Maven Central Repository and a central proxy repository in Nexus for the Maven Central Repository. As both of these repositories have the same URL, the Nexus Migration plugin will show a checkbox in the Merge With column as shown in Figure A.6. Checking this box will instruct
Ed. 3.0.2

215 / 241
the Nexus Migration plugin to merge the contents and conguration of the repo1 repository with the existing central repository. In other words, if this box is checked, the Nexus Migration plugin will not create a new proxy repository for repo1, and if the box isnt checked, the Nexus Migration plugin will create new proxy repository for repo1
Figure A.6: Merging a Proxy Repository During Artifactory Import
A.8
Conguring Users and Privileges in the Artifactory Import
The Users table shown in Figure A.7 allows you to select which users are imported into Nexus from the Artifactory system backup archive. The columns in the User table are: Import If the checkbox in this column is selected, the Artifactory user will be imported into Nexus, if the box is not selected this user will not be imported into Nexus. User ID This is the User identier from Artifactory, this eld cannot be edited. Email This is the email of a User, this eld cannot be edited. Admin If this checkbox is selected, Nexus will associate the newly imported user with the Nexus Administrator role.
Figure A.7: Conguring Users During Artifactory Import Just below the Users table is the Import Permissions checkbox. If this checkbox is selected, Nexus will attempt to import Artifactory privileges into Nexus and map the corresponding roles and privileges to the imported users.
Ed. 3.0.2

216 / 241
A.9
Performing the Artifactory Import
Once the Artifactory import has been congured, click on the Start Import button at the bottom of the Artifactory Import panel. Clicking on the Start Import button will show you the warning dialog shown in Figure A.8.
Figure A.8: Loading Artifactory Conguration Warning If you are migrating a large Artifactory installation, the loading process could take a signicant amount of time. If you are comfortable with your import conguration, click on the Yes button. Clicking on the Yes button will then cause Nexus to display the dialog shown in Figure A.9.
Figure A.9: Artifactory Import Scheduled Dialog This dialog informs you that the import is scheduled to start as soon as possible using the Nexus scheduled Job execution infrastructure. You can check on the progress of the import process by clicking on the Show Log button at the bottom of the Artifactory Import panel or by clicking on Logs and Cong Files under the <guimenu>Views/Repositories menu and selecting the migration.log le from the "Select a document. . . " dropdown. The migration log is shown in Figure A.10.
Ed. 3.0.2

217 / 241
Figure A.10: Viewing the Migration Logs
A.10
Conguring Artifactory Clients to Use Nexus
Nexus is a drop-in replacement for Artifactory, this means that you dont need to recongure your projects settings.xml and repository elements throughout your POMs to start using Nexus. When you installed the Nexus Migration plugin, you also installed a web application called the Artifactory Bridge which should be running under the context path /artifactory next to the /nexus application. If you run Nexus at the default http://localhost:8081/nexus/ URL, the artifactory bridge will be running at http://localhost:8081/artifactory/ This Artifactory Bridge will serve repository metadata and artifacts from Nexus under the same URLs that your existing Artifactory clients expect. When you were conguring your repositories during the Artifactory Import in Section A.7, youll remember that there was a column named Map URL check box for a repository instructed the Nexus Migration plugin to congure a mapping between the old Artifactory URL and repository identier and the new Nexus URL and repository identier. To see this mapping in action, take a look at the Central repository through three different URLs. This example assumes that you mapped your old repo1 Artifactory proxy repository to the Nexus central proxy repository. Lets take a quick look at the URL for metadata.xml for the nexus-index artifact which is under the group identier org.sonatype.nexus. To retrieve this directly from the Maven Central repository, you would use the following URL:
http://repo1.maven.org/maven2/\ org/sonatype/nexus/nexus-indexer/maven-metadata.xml
To retrieve the same le from the Nexus central proxy of the Maven Central repository, you would use the following URL which contains the new Nexus repository identier "central":
http://localhost:8081/nexus/content/repositories/central/\ org/sonatype/nexus/nexus-indexer/maven-metadata.xml
To retrieve the same le from the Artifactory Bridge, you would use the following URL which contains the old Artifactory repository identier "repo1":
http://localhost:8081/artifactory/repo1/\ org/sonatype/nexus/nexus-indexer/maven-metadata.xml
Ed. 3.0.2

218 / 241
The conguration for these mappings is stored in sonatype-work/nexus/conf/mapping.xml. This is an XML le which was congured during the import that maps the old Artifactory repository identiers to the new Nexus repository identiers. The Artifactory Bridge web application is congured in $NEXUS_HOME/conf/plexus.xml contains a reference to the web application and also congures the context-path /artifactory
Ed. 3.0.2

219 / 241
Appendix B
Migrating to Nexus from Archiva

B.1 Introduction
This appendix walks you through the process of migrating an existing Archiva installation to a new Nexus installation.
B.2
Migrating Archiva Repositories
Archive uses the lesystem to store hosted repositories and proxied repositories, because of this migrating from Archiva to Nexus couldnt be simpler. The following sections outline the process for migrating existing Archiva repositories to a new Nexus instance.
B.3
Migrating an Archiva Managed Repository
Archiva Managed Repositories are the equivalent of Nexus Hosted repositories. To migrate a Managed Repository from Archiva to Nexus, all you need to do is: Create a New Hosted Repository in Nexus Copy the Contents of the Archiva Managed Repository to the Storage Directory of the newly-created Nexus Hosted Repository Rebuild the Index for the New Nexus Hosted Repository The following example will walk through the process of migrating the Archiva repository named "internal" to a new Nexus Hosted repository named "internal". To view your managed repositories in Archiva, login to Archiva as an administrative user and click on the "Repositories" link in the left-hand navigation menu. Clicking on "Repositories" will list all of your Archiva Managed repositories as shown in Figure B.1.
Ed. 3.0.2

220 / 241
Figure B.1: Archiva Managed Repositories To migrate this Managed repository to a Nexus Hosted repository, you will need to nd the directory in which Archiva stores all of the repository artifacts. to do this, click on the Edit link listed next to the name of the repository you want to migrate as shown in Figure B.1. Click on Edit should load the form shown in Figure B.2.
Figure B.2: Editing an Archiva Managed Repository Take note of the le path for Directory. The le path shown in Figure B.2 is ./data/repositories/internal. If Archiva is installed in /usr/local/archiva-1.2.1, this would correspond to the directory /usr/local/archiva-1.2.1/data/repositories/internal. You will use this path later in this section to copy the contents of your old Archiva Managed Repository to your new Nexus Hosted Repository.
Ed. 3.0.2

221 / 241
Next, create a new Nexus repository with the same identier and Name as the old Archiva Managed Repository. To do this, log into Nexus as an administrative user, click on Repositories in the left-hand Nexus navigation menu, and then click on the Add dropdown as shown in Figure B.3. Select "Hosted Repository" and then ll out the Repository ID and Repository Name to match the name of the old Archiva repository. If you are migrating a Snapshot repository, select a Repository Policy of Snapshot, and if you are migrating a Release repository select a Snapshot Policy of Release.
Figure B.3: Creating a Nexus Hosted Repository Now, youll need to copy the Archiva repository to the Nexus repository. You can do this, by copying the contents of the Archiva repository directory to the Nexus repository storage directory. If we assume that Archiva is install in /usr/local/archiva1.2.1, Nexus is install in /usr/local/nexus-1.3.6, and the Sonatype Work directory is /usr/local/sonatype-work. You can copy the contents of the Archiva managed repository to the new Nexus hosted repository by executing the following command:
$ cp -r /usr/local/archiva-1.2.1/data/repositories/internal/* \ /usr/local/sonatype-work/nexus/storage/internal/
If you are migrating to a Nexus instance which is on a different server, you can simply create an archive of the /usr/local/archiva1.2.1/data/repositories/internal directory, copy it to the new server, and then uncompress your repository archive in the appropriate directory.
Warning Archiva stores artifacts from proxied remote repositories in the same directory as artifacts in a managed repository. If you have been proxying a remote repository, you might want to remove artifacts that have been proxied from a remote repository. For example, if your organization uses a groupId of org.company for internal project, you can make sure to only copy the artifacts under the corresponding org/company/
Once the contents of the repository have been copied to the Nexus Hosted repository, you must rebuild the repository index as shown in Figure B.4. Right-clicking on the repository in the list of Nexus repositories will display the context menu shown in the following gure.
Ed. 3.0.2

222 / 241
Figure B.4: Rebuilding the Index of a Nexus Hosted Repository Once the migration is complete, you will be able to search and browse the contents of your newly migrated Nexus Hosted repository.
B.4
Migrating an Archiva Proxy Connector
Archiva allows you to dene remote repositories and repository connectors to proxy remote repositories and cache remote artifacts from remote repositories in Archiva Managed Repositories. While Nexus also provides Proxy repositories, there is one major difference between Nexus and Archiva. Where Nexus maintains a separate local storage directory for each proxy repository, Archiva combines cached remote artifacts into a single lesystem with the contents of a managed repository. In other words, there is no good way to transfer an existing local cache of artifacts between Archiva and Nexus without manually manipulating the contents of Archivas Managed Repository directory. To recreate an Archiva repository connector in Nexus as a Proxy repository and to preserve the local cache of artifacts from this repository. Youll need to create a Proxy repository in Nexus, copy the contents of the existing proxy repository to the Nexus storage location for you new Proxy repository, and then rebuild the metadata of your new Nexus Proxy repository. First step is to take a look at the Remote Repositories in your Archiva installation: log in as an administrative user and then click on "Repositories" under the Administration menu in the left-hand Archiva navigation menu. Once youve clicked this link and loaded the list of repositories, scroll to the bottom of the page to see the list of remote repositories as shown in Figure B.5.
Ed. 3.0.2

223 / 241
Figure B.5: Browsing Archiva Remote Repositories Dening a proxy repository in Archiva involves associating one of the remote repositories dened in Figure B.5 with one of the Managed Repositories dened in Figure B.1. Once you do this, requests for artifacts from the managed repository will also query the remote repository. If an artifact is found in the remote repository, it will be retrieved and stored in the managed repositorys storage directory. To see a list of proxy connectors and the managed repositories they are associated with, click on "Proxy Connectors" in the left-hand Archiva menu, you will see a list similar to that shown in Figure B.6.
Figure B.6: Archiva Proxy Connectors Click on the Edit Icon (or Pencil) next to second Proxy Connector listed in Figure B.6, this will then load the settings form for this proxy connector shown in Figure B.7. You should use the settings for this proxy connect to congure your new Nexus Proxy repository.
Ed. 3.0.2

224 / 241
Figure B.7: Archiva Proxy Connector Settings To create a Proxy repository that will correspond to the Proxy Connector in Archiva, log into Nexus as an administrative user, and click on Repositories in the left-hand Nexus menu. Once you can see a list of Nexus repositories, click on Add. . . and select Proxy Repository from the dropdown of repository types. In the New Proxy Repository form (shown in Figure B.8) populate the repository ID, repository Name, and use the remote URL that was displayed in Figure B.5. You will need to create a remote repository for every proxy connector that was dened in Archiva.
Ed. 3.0.2

225 / 241
Figure B.8: Creating a Nexus Proxy Repository To expose this new Proxy repository in a Repository Group, create a new Nexus Repository group or select an existing group by clicking on Repositories in the left-hand Nexus menu. Click on a repository group and then select the Conguration tab to display the form shown in Figure B.9. In the Conguration tab you will see a list of Order Group Repositories and Available Repositories. Click and drag your new Nexus Proxy repository to the list of Ordered Group Repositories, and click Save.
Ed. 3.0.2

226 / 241
Figure B.9: Adding a Proxy Repository to a Repository Group Next, you will need to dene repository groups that will tell Nexus to only locate certain artifacts in the newly created proxy repository. In , Archiva dened three patterns that were used to lter artifacts available from the proxy connector. These three patterns were "javax/", "com/sun/", and "org/jvnet/**". To recreate this behavior in Nexus, dene three Routes which will be applied to the group you congured in Figure B.9. To create a route, log in as an administrative user, and click on Routes under the Administration menu in the left-hand Nexus menu. Click on Add.. and add three inclusive routes that will apply to the repository group you congured in Figure B.9.
Ed. 3.0.2

227 / 241
Figure B.10: Dening Nexus Repository Groups
Ed. 3.0.2

228 / 241
Appendix C
Conguring Nexus for SSL

C.1 Introduction
This chapter contains two sections: the rst section details a procedure for connecting Nexus to a remote repository which requires client-side SSL certicates and the second section details the conguration for serving SSL directly from Nexus. When you set up a repository manager for a team of developers spread out over a variety of locations both internal and external to a corporate network, you will likely want to secure your repository using SSL. The instructions in this chapter assume that you are running Nexus embedded in Jetty.
C.2
Importing a SSL Client Certicate
If you need to congure Nexus to proxy a remote repository which requires a SSL Client Certicate, youll need to import the certicate included with your Nexus license into the JVM used to run your Nexus instance. To make this process simpler, you can use our import-ssl tool. Weve created a simple command-line utility which automates the process of loading the Server SSL Chain and the client certicate into a JVM.
C.2.1
Downloading the SSL Import Tool
The import-ssl tool can be downloaded from: http://central.sonatype.com/help/import-ssl.jar
C.2.2
Importing a Client Certicate
Importing a client certicate involves two steps: importing the servers SSL chain and importing the client SSL key/certicate pair. Some notes about the location of the key-store and default key-store passwords: If you are using the default JSSE key-store locations on either a GNU/Linux or OS X platform, you must run the commands below as the root user. You can do this either by changing to the root user (su -), or by using the sudo command: sudo [command]. The default password used by Java for the built-in key-stores is changeit. If your key-store uses a different password, youll need to specify that password as the last parameter on the command lines above. If you want to specify your own key-store location, provide that in place of <keystore_dir> in the examples below. If youre using a password other than changeit for your keystore, you should supply it immediately following the keystore path in the commands below. If you specify a keystore location that doesnt exist, the import-ssl utility will create it on-demand.
Ed. 3.0.2

229 / 241
Before you begin the process of importing a Server SSL Chain and a client certicate you will need three things: Network access to the SSL server you are connecting to, An SSL client certicate, and a certicate password.
C.2.3
Import the Server SSL Chain
The rst command imports the entire self-signed SSL certicate chain for central.sonatype.com into your JSSE keystore:
$ java -jar import-ssl.jar server central.sonatype.com \ <keystore_dir>
You would substitute the server name used in the previous listing with the server name you are attempting to connect to. This particular command will connect to https://central.sonatype.com, retrieve, and import the servers SSL certicate chain.
C.2.4
Import the Client SSL Key/Certicate Pair
The second command imports your client-side SSL certicate into the JSSE keystore, so Nexus can send it along to the server for authentication:
$ java -jar import-ssl.jar client <your-certificate.p12> \ <your-certificate-password> <keystore_dir>
When the client command completes, you should see a line containing the keystore path, like the one that follows. This path is important; you will use it in your Nexus conguration below, so make a note of it!
... Writing keystore: /System/Library/Frameworks/JavaVM.framework/\ Versions/1.6.0/Home/lib/security/jssecacerts
C.2.5
Conguring Nexus Startup
Once both sets of SSL certicates are imported to your keystore, you can modify the Nexus $NEXUS_HOME/conf/wrapper.conf le to inject the JSSE system properties necessary to use these certicates, as seen below.
Note In the following example, line prexes like wrapper.java.additional.4 are meant to be appended to the existing wrapper.java.additional.* lines in the wrapper.conf le. In future versions of Nexus, new JVM command-line arguments may be specied in this le. In such a case, where the specic numbers 4 and 5 may be taken, simply increment and use the next two unused numbers.
wrapper.java.additional.4=-Djavax.net.ssl.keyStore=<keystore_dir> wrapper.java.additional.5=-Djavax.net.ssl.keyStorePassword=<keystore_password>
Once you have congured the Nexus startup option shown above, restart Nexus and attempt to proxy a remote repository which requires an SSL client certicate. Nexus will use the keystore location and keystore password to congure the SSL interaction to accept the servers SSL certicate and send the appropriate client SSL certicate.
Ed. 3.0.2

230 / 241
C.3
Conguring Nexus to Serve SSL
If you need to serve repository content using SSL, you can always proxy Nexus with a server like Apache httpd. Apache httpd can easily be congured to serve SSL content using mod_ssl, and there is a large amount of reference material available for conguring httpd to serve secure content. Jetty can also be congured to serve SSL content directly, and if you would like to avoid the extra work of putting a web server like Apache httpd in front of Nexus, this section shows you how to do that. To congure Nexus to serve SSL directly to clients, youll need to perform the following steps.
Note All examples given here can be found Nexus Subversion, or in the Nexus distribution under \$(NEXUS_HOME)/conf/examples. Before you customize your Nexus conguration to serve SSL, keep in mind the following:
Customizations in this Appendix assume that your are running Nexus 1.9.2. Any custom Jetty conguration must be contained in the \$(NEXUS_HOME)/conf/jetty.xml le, or else in the location referenced by the jetty.xml property in \$(NEXUS_HOME)/conf/plexus.properties (in case youve customized this location). While the instructions below will work with Nexus Open Source, these instructions assume the lesystem of Nexus Professional. If you are missing Jetty JAR les, you should obtain them from the Jetty project page: http://www.mortbay.org/jetty/
C.3.1
Congure the Java Keystore
Follow the instructions on the How to congure SSL on the Jetty Wiki to setup the appropriate keys and certicates in a form that Jetty can use. Pay particular attention to steps 1-3, and the section at the bottom called Password Issues. The jetty-util jar and the main Jetty jar can be found in $NEXUS_HOME/runtime/apps/lib/nexus. The command line used to import an OpenSSL key+cert in PKCS12 format is:
$ java -classpath jetty-util-6.1.12.jar:jetty-6.1.12.jar \ org.mortbay.jetty.security.PKCS12Import <pkcs12-file> <keystore>
The command line used to generate an obfuscated password hash is:

$ java -classpath jetty-util-6.1.12.jar:jetty-6.1.12.jar \ org.mortbay.jetty.security.Password <your-password> <your-password> OBF:1t2x1toq1to41t39 MD5:6f1ed002ab5595859014ebf0951522d9
The OBF line in the previous output will be used in the jetty.xml three times. Youll need to run the previous command three times to generate the obfuscated hashcodes for three passwords: The Key Password The Trust Store Password The Key Store Password In the next section, the key store and trust store are the same le, with the same password.
C.3.2
Congure Nexus/Jetty to Use the New Keystore
Note A jetty.xml with the modications in this section can be found in $NEXUS_HOME/conf/examples/jetty-ssl.xml, inside your Nexus distribution.
Ed. 3.0.2

231 / 241
Modify the nexus-equivalent jetty.xml

<Call name="addConnector"> <Arg> <New class="org.mortbay.jetty.nio.SelectChannelConnector"> <Set name="host">${application-host}</Set> <Set name="port">${application-port}</Set> </New> </Arg> </Call>
with this:
<Call name="addConnector"> <Arg> <New class="org.mortbay.jetty.security.SslSelectChannelConnector"> <Set name="host">${application-host}</Set> <Set name="port">${application-port}</Set> <Set name="maxIdleTime">30000</Set> <Set name="keystore">/etc/ssl/keystore</Set> <Set name="truststore">/etc/ssl/keystore</Set> <Set name="password">OBF:1v2j1uum1xtv1zej1zer1xtn1uvk1v1v</Set> <Set name="keyPassword">OBF:1v2j1uum1xtv1zej1zer1xtn1uvk1v1v</Set> <Set name="trustPassword">OBF:1v2j1uum1xtv1zej1zer1xtn1uvk1v1v</Set> </New> </Arg> </Call>
C.3.3
Modify the application-port for SSL connections
The application-port property, referenced in the conguration above, has a default conguration that many people would more naturally associate with non-SSL connections. You may wish to modify this port to something like 8443, or even 443 (if you have root access from which to start Nexus). To change this property, modify the \$(basedir)/conf/plexus.properties
Note You may wish to enable both types of connections, with appropriate rewrite rules between them. Such a conguration is beyond the scope of this section; if youre interested, please refer to the Jetty Wiki for some information to get you started. Additionally, you may need to add extra port properties to the plexus.properties conguration le to accommodate both SSL and non-SSL connections.
C.4
Redirecting Non-SSL Connections to SSL
If you want to make it very easy for people to use your Nexus repository, you will want to congure the automatic redirect from the non-SSL port (default 80) to the SSL port (default 443). When this feature is congured, browsers and clients that attempt to interact with the non-SSL port will be seamlessly redirected to the SSL port. If you do not turn on the automatic redirect to SSL, users who attempt to load the Nexus interface via the default port 80 will see a network error. If you are proxying your Nexus instance with a web server like Apache httpd, you could congure mod_rewrite to automatically redirect browsers to the SSL port, or you can congure Jetty to perform this redirection. To do this in Jetty you use a custom rewrite rule for Jetty that is bundled with Nexus, inside the plexus-jetty6 library found in $NEXUS_HOME/runtime/apps/nexus/lib To enable this feature, congure Jetty to serve SSL directly as demonstrated in Section C.3. After you having congured Jetty to serve SSL directly, open your jetty.xml and replace the existing handler/context-collection declaration with a stand-alone context-collection declaration, by replacing this section:
Ed. 3.0.2

232 / 241
<Set name="handler"> <New id="Contexts" class="org.mortbay.jetty.handler.ContextHandlerCollection">  <Call name="addLifeCycleListener"> <Arg> <New class="org.sonatype.plexus.jetty.custom.InjectExistingPlexusListener" /> </Arg> </Call>  <Call name="addLifeCycleListener"> <Arg> <New class="org.sonatype.plexus.jetty.custom.DisableTagLibsListener" /> </Arg> </Call> </New> </Set>
with this one:

<New id="Contexts" class="org.mortbay.jetty.handler.ContextHandlerCollection">  <Call name="addLifeCycleListener"> <Arg> <New class="org.sonatype.plexus.jetty.custom.InjectExistingPlexusListener" /> </Arg> </Call>  <Call name="addLifeCycleListener"> <Arg> <New class="org.sonatype.plexus.jetty.custom.DisableTagLibsListener" /> </Arg> </Call> </New>
Now, congure the rewrite handler for Jetty by adding the following section just above the line with stopAtShutdown in it:
<Set name="handler"> <New id="Handlers" class="org.mortbay.jetty.handler.rewrite.RewriteHandler"> <Set name="rules"> <Array type="org.mortbay.jetty.handler.rewrite.Rule"> <Item> <New id="redirecedHttps" class="org.sonatype.plexus.jetty.custom.RedirectToHttpsRule"> <Set name="httpsPort">${application-port-ssl}</Set> </New> </Item> </Array> </Set> <Set name="handler"> <New id="Handlers" class="org.mortbay.jetty.handler.HandlerCollection"> <Set name="handlers"> <Array type="org.mortbay.jetty.Handler"> <Item><Ref id="Contexts"/></Item>
Ed. 3.0.2

233 / 241
<Item> <New id="DefaultHandler" class="org.mortbay.jetty.handler.DefaultHandler"/></Item> <Item> <New id="RequestLog" class="org.mortbay.jetty.handler.RequestLogHandler"/></Item> </Array> </Set> </New> </Set> </New> </Set>
Modify $NEXUS_HOME/conf/plexus.properties and add a new property, application-port-ssl. This will allow you to customize both the SSL and non-SSL ports independently:
application-port-ssl=8443
Ed. 3.0.2

234 / 241
Appendix D
Contributing to the Nexus Book

This appendix covers the basics of contributing to the book you are currently reading. This book is an open source project, you can participate in the writing effort if you have an idea for documentation. Sonatypes books are different: they are open writing efforts and we see documentation contributions as having equal value to code contributions. If you are interested in our technology, wed welcome your contribution.
D.1
Contributor License Agreement (CLA)
In order to contribute to the Nexus book, you will rst need to ll out a contributor license agreement. This is a legal agreement between you and Sonatype which ensures that your contributions are not covered by any other legal requirements. Sonatype requires contributors to sign this agreement for all major contributions which are larger than a single section. If your contribution consists of nding and xing simple typos or suggesting minor changes to the wording or sequence of a particular section, you can contribute these changes via the Sonatype JIRA instance. If you contribution involves direct contribution of a number of sections or chapters you will rst need to sign our Contributor License Agreement (CLA). To download the CLA from the following URL: http://www.sonatype.org/SonatypeCLA.pdf Once you have completed and signed this document, you can fax it to: (650) 472-9197
D.2
Contributors, Authors, and Editors
As with any open source effort, the contributors to the Nexus book are grouped into a simple hierarchy. Sonatypes writing efforts are loosely structured, but we have found it necessary to dene some formal categories for contributors. Reviewers Many individuals have read the book and taken the time to report typos and bugs. Reviewers are always credited in the Foreword of the book and they make an important contribution to the quality of the book. Contributors Contributors are individuals who have contributed one or more sections to the book. Many contributors make a one time contribution to a particular section or collection of sections. Contributors are always credited in the Foreword of the book, and if a contributor sustains a constant level of contribution which adds up to the equivalent of an entire chapter, a contributors name will be added to the list of contributing authors. Authors Authors have made a signicant contribution to the book equal to the equivalent of one or more chapters. A long-time contributor can also be transitioned to the status of Author at the discretion of an Editor. Authors are often given editorial control over specic chapters or sections of a book, working with Contributors to review, accept, and rene contributions to dened sections of the book.
Ed. 3.0.2

235 / 241
Editors An Author can also be an Editor. Each book has at least one editor (and ideally no more than two Editors at any time). On Sonatype Open book projects, Editors are the arbiters of content, they review content submissions and make nal decisions about content direction. For each of these levels, the adjective "Active" can be used if a contributor, author, or editor has been active during the previous 12 months. If you have any questions about contributor status, send any inquiries to [email protected]
D.3
Tools Used to Build and Write this Book
The following tools are used to write this book. If you are interested in contributing to this book, you will need to download the following software: Asciidoc A very lightweight markup format with a strong community and a collection of solid tools. For more information, see http://www.methods.co.nz/asciidoc/ A Text Editor Emacs, vi, TextMate, Notepad - it doesnt matter. All you need to contribute to this book is a text editor. Git Sonatype stores the source code for all books in Github so you will need to download Git. In addition to downloading Git, if you need read/write access to the repository you will also need to sign up for an account on GitHub - http://www.github.com Download the latest version of Git from http://git-scm.com/ This next set of tools are optional, and are only required if you are involved in generating diagrams or formatting the nal PDF for the pre-print production process. In short, there is only one or two people who will need to have access to the following set of tools, and, in a normal publishing house, all of these functions would likely be performed by a separate "Production" team. Omnigrafe Many of the diagrams in this book have been generated using a OSX-specic tool named Omnigrafe. If you are interested in helping us create diagrams dont feel compelled to purchase a copy of Omnigrafe. Send us a rough outline of your diagram, and Sonatype will gladly transform your idea into a diagram if your contributions are accepted into the book. Adobe Photoshop All of the screen shots are generated using simple screen capture tools. The resulting raw images (PNGs) are then processed using a set of very simple Photoshop macros. These macros add a border to each screen shot and apply a standard drop shadow. Once the drop shadow has been applied, these macros then save a 72 dpi PNG image for the HTML version of the book in addition to a 150 dpi PDF image for the printed version of the book, While Adobe Photoshop is a capable (and somewhat formidable) graphics manipulation tool, Sonatype is exploring alternatives to using this commercial utility in the content generation process. Alternatives currently being investigated are open source packages such as GIMP or systems which can rely on ImageMagick for scripted conversion of raw screen shots to multiple web and print image formats. If you are interested in contributing, but you do not want to bother with the process of formatting images for both web and print, Sonatype welcomes contributions which include raw screen captures. We can take care of the formatting. Adobe Illustrator The book cover, the promotional material insert, and the print binder for Lulu are all generated with Adobe Illustrator. Adobe Illustrator can open and edit PDFs natively, and can be used to generate the static PDFs which are concatenated together to produce the nal book output.
Ed. 3.0.2

236 / 241
D.4
How to Build the Book
You know what, this book doesnt really have a "build" as much as it has a collection of light-weight bash scripts which are used to invoke Asciidoc and a2x. If you are interested in building the book, weve had good success on Mac OSX and Ubuntu. Any other operation system and you are on your own. Clone the books Git repository. To clone this books repository execute the following command at a command-line:
$ git clone [email protected]:sonatype/nexus-book.git ...a bunch of Git output...
Running this command will create a subdirectory named nexus-book which is a copy of this books source. ./build.sh This will create a single-page HTML version, a chunked HTML version, and a PDF version of the book.
D.5
Subscribing to the Book Developers List
Sonatype maintains a Book Developers mailing list as a single mailing list for contributors, authors, and editors working on any of our Sonatype Open Books. This is a high volume list which contains both discussion and automated emails from GitHub and our Sonatype Matrix continuous integration server. To subscribe to this mailing list, send and email to: [email protected]
Ed. 3.0.2

237 / 241
Appendix E
Copyright
Copyright 2011 Sonatype, Inc. All rights reserved. Online version published by Sonatype, Inc, Nexus, Nexus Professional, and all Nexus-related logos are trademarks or registered trademarks of Sonatype, Inc., in the United States and other countries. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc., in the United States and other countries. IBM and WebSphere are trademarks or registered trademarks of International Business Machines, Inc., in the United States and other countries. Eclipse is a trademark of the Eclipse Foundation, Inc., in the United States and other countries. Apache and the Apache feather logo are trademarks of The Apache Software Foundation. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and Sonatype, Inc. was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.
Ed. 3.0.2

238 / 241
Appendix F
Creative Commons License

This work is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 United States license. For more information about this license, see http://creativecommons.org/licenses/by-nc-nd/3.0/us/. You are free to share, copy, distribute, display, and perform the work under the following conditions: You must attribute the work to Sonatype, Inc. with a link to http://www.sonatype.com You may not use this work for commercial purposes. You may not alter, transform, or build upon this work. If you redistribute this work on a web page, you must include the following link with the URL in the about attribute listed on a single line (remove the backslashes and join all URL parameters):
<div xmlns:cc="http://creativecommons.org/ns#" about="http://creativecommons.org/license/results-one?q_1=2&q_1=1\ &field_commercial=n&field_derivatives=n&field_jurisdiction=us\ &field_format=StillImage&field_worktitle=Repository%3A+\Management\ &field_attribute_to_name=Sonatype%2C+Inc.\ &field_attribute_to_url=http%3A%2F%2Fwww.sonatype.com\ &field_sourceurl=http%3A%2F%2Fwww.sonatype.com%2Fbook\ &lang=en_US&language=en_US&n_questions=3"> <a rel="cc:attributionURL" property="cc:attributionName" href="http://www.sonatype.com">Sonatype, Inc.</a> / <a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/us/"> CC BY-NC-ND 3.0</a> </div>
When downloaded or distributed in a jurisdiction other than the United States of America, this work shall be covered by the appropriate ported version of Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 license for the specic jurisdiction. If the Creative Commons Attribution-Noncommercial-No Derivative Works version 3.0 license is not available for a specic jurisdiction, this work shall be covered under the Creative Commons Attribution-Noncommercial-No Derivate Works version 2.5 license for the jurisdiction in which the work was downloaded or distributed. A comprehensive list of jurisdictions for which a Creative Commons license is available can be found on the Creative Commons International web site at http://creativecommons.org/international
If no ported version of the Creative Commons license exists for a particular jurisdiction, this work shall be covered by the generic, unported Creative Commons Attribution-Noncommercial-No Derivative Works version 3.0 license available from http://creativecommons licenses/by-nc-nd/3.0/
Ed. 3.0.2

239 / 241
F.1
Creative Commons BY-NC-ND 3.0 US License
Creative Commons Attribution-NonCommercial-NoDerivs 3.0 United States THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE COMMONS PUBLIC LICENSE ("CCPL" OR "LICENSE"). THE WORK IS PROTECTED BY COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED. BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE TO BE BOUND BY THE TERMS OF THIS LICENSE. TO THE EXTENT THIS LICENSE MAY BE CONSIDERED TO BE A CONTRACT, THE LICENSOR GRANTS YOU THE RIGHTS CONTAINED HERE IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND CONDITIONS. 1. Denitions a. "Collective Work" means a work, such as a periodical issue, anthology or encyclopedia, in which the Work in its entirety in unmodied form, along with one or more other contributions, constituting separate and independent works in themselves, are assembled into a collective whole. A work that constitutes a Collective Work will not be considered a Derivative Work (as dened below) for the purposes of this License. b. "Derivative Work" means a work based upon the Work or upon the Work and other pre-existing works, such as a translation, musical arrangement, dramatization, ctionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which the Work may be recast, transformed, or adapted, except that a work that constitutes a Collective Work will not be considered a Derivative Work for the purpose of this License. For the avoidance of doubt, where the Work is a musical composition or sound recording, the synchronization of the Work in timed-relation with a moving image ("synching") will be considered a Derivative Work for the purpose of this License. c. "Licensor" means the individual, individuals, entity or entities that offers the Work under the terms of this License. d. "Original Author" means the individual, individuals, entity or entities who created the Work. e. "Work" means the copyrightable work of authorship offered under the terms of this License. f. "You" means an individual or entity exercising rights under this License who has not previously violated the terms of this License with respect to the Work, or who has received express permission from the Licensor to exercise rights under this License despite a previous violation. 2. Fair Use Rights. Nothing in this license is intended to reduce, limit, or restrict any rights arising from fair use, rst sale or other limitations on the exclusive rights of the copyright owner under copyright law or other applicable laws. 3. License Grant. Subject to the terms and conditions of this License, Licensor hereby grants You a worldwide, royalty-free, non-exclusive, perpetual (for the duration of the applicable copyright) license to exercise the rights in the Work as stated below: a. to reproduce the Work, to incorporate the Work into one or more Collective Works, and to reproduce the Work as incorporated in the Collective Works; and, b. to distribute copies or phonorecords of, display publicly, perform publicly, and perform publicly by means of a digital audio transmission the Work including as incorporated in Collective Works. The above rights may be exercised in all media and formats whether now known or hereafter devised. The above rights include the right to make such modications as are technically necessary to exercise the rights in other media and formats, but otherwise you have no rights to make Derivative Works. All rights not expressly granted by Licensor are hereby reserved, including but not limited to the rights set forth in Sections 4(d) and 4(e). 1. Restrictions.The license granted in Section 3 above is expressly made subject to and limited by the following restrictions: a. You may distribute, publicly display, publicly perform, or publicly digitally perform the Work only under the terms of this License, and You must include a copy of, or the Uniform Resource Identier for, this License with every copy or phonorecord of the Work You distribute, publicly display, publicly perform, or publicly digitally perform. You
Ed. 3.0.2

240 / 241
may not offer or impose any terms on the Work that restrict the terms of this License or the ability of a recipient of the Work to exercise the rights granted to that recipient under the terms of the License. You may not sublicense the Work. You must keep intact all notices that refer to this License and to the disclaimer of warranties. When You distribute, publicly display, publicly perform, or publicly digitally perform the Work, You may not impose any technological measures on the Work that restrict the ability of a recipient of the Work from You to exercise the rights granted to that recipient under the terms of the License. This Section 4(a) applies to the Work as incorporated in a Collective Work, but this does not require the Collective Work apart from the Work itself to be made subject to the terms of this License. If You create a Collective Work, upon notice from any Licensor You must, to the extent practicable, remove from the Collective Work any credit as required by Section 4(c), as requested. b. You may not exercise any of the rights granted to You in Section 3 above in any manner that is primarily intended for or directed toward commercial advantage or private monetary compensation. The exchange of the Work for other copyrighted works by means of digital le-sharing or otherwise shall not be considered to be intended for or directed toward commercial advantage or private monetary compensation, provided there is no payment of any monetary compensation in connection with the exchange of copyrighted works. c. If You distribute, publicly display, publicly perform, or publicly digitally perform the Work (as dened in Section 1 above) or Collective Works (as dened in Section 1 above), You must, unless a request has been made pursuant to Section 4(a), keep intact all copyright notices for the Work and provide, reasonable to the medium or means You are utilizing: (i) the name of the Original Author (or pseudonym, if applicable) if supplied, and/or (ii) if the Original Author and/or Licensor designate another party or parties (e.g. a sponsor institute, publishing entity, journal) for attribution ("Attribution Parties") in Licensors copyright notice, terms of service or by other reasonable means, the name of such party or parties; the title of the Work if supplied; to the extent reasonably practicable, the Uniform Resource Identier, if any, that Licensor species to be associated with the Work, unless such URI does not refer to the copyright notice or licensing information for the Work. The credit required by this Section 4(c) may be implemented in any reasonable manner; provided, however, that in the case of a Collective Work, at a minimum such credit will appear, if a credit for all contributing authors of the Collective Work appears, then as part of these credits and in a manner at least as prominent as the credits for the other contributing authors. For the avoidance of doubt, You may only use the credit required by this clause for the purpose of attribution in the manner set out above and, by exercising Your rights under this License, You may not implicitly or explicitly assert or imply any connection with, sponsorship or endorsement by the Original Author, Licensor and/or Attribution Parties, as appropriate, of You or Your use of the Work, without the separate, express prior written permission of the Original Author, Licensor and/or Attribution Parties. 2. Representations, Warranties and Disclaimer UNLESS OTHERWISE MUTUALLY AGREED TO BY THE PARTIES IN WRITING, LICENSOR OFFERS THE WORK AS-IS AND ONLY TO THE EXTENT OF ANY RIGHTS HELD IN THE LICENSED WORK BY THE LICENSOR. THE LICENSOR MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND CONCERNING THE WORK, EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, INCLUDING, WITHOUT LIMITATION, WARRANTIES OF TITLE, MARKETABILITY, MERCHANTIBILITY, FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR THE ABSENCE OF LATENT OR OTHER DEFECTS, ACCURACY, OR THE PRESENCE OF ABSENCE OF ERRORS, WHETHER OR NOT DISCOVERABLE. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO SUCH EXCLUSION MAY NOT APPLY TO YOU. 1. Limitation on Liability. EXCEPT TO THE EXTENT REQUIRED BY APPLICABLE LAW, IN NO EVENT WILL LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY FOR ANY SPECIAL, INCIDENTAL, CONSEQUENTIAL, PUNITIVE OR EXEMPLARY DAMAGES ARISING OUT OF THIS LICENSE OR THE USE OF THE WORK, EVEN IF LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. 2. Termination a. This License and the rights granted hereunder will terminate automatically upon any breach by You of the terms of this License. Individuals or entities who have received Collective Works (as dened in Section 1 above) from You under this License, however, will not have their licenses terminated provided such individuals or entities remain in full compliance with those licenses. Sections 1, 2, 5, 6, 7, and 8 will survive any termination of this License. b. Subject to the above terms and conditions, the license granted here is perpetual (for the duration of the applicable copyright in the Work). Notwithstanding the above, Licensor reserves the right to release the Work under different
Ed. 3.0.2

241 / 241
license terms or to stop distributing the Work at any time; provided, however that any such election will not serve to withdraw this License (or any other license that has been, or is required to be, granted under the terms of this License), and this License will continue in full force and effect unless terminated as stated above. 3. Miscellaneous a. Each time You distribute or publicly digitally perform the Work (as dened in Section 1 above) or a Collective Work (as dened in Section 1 above), the Licensor offers to the recipient a license to the Work on the same terms and conditions as the license granted to You under this License. b. If any provision of this License is invalid or unenforceable under applicable law, it shall not affect the validity or enforceability of the remainder of the terms of this License, and without further action by the parties to this agreement, such provision shall be reformed to the minimum extent necessary to make such provision valid and enforceable. c. No term or provision of this License shall be deemed waived and no breach consented to unless such waiver or consent shall be in writing and signed by the party to be charged with such waiver or consent. d. This License constitutes the entire agreement between the parties with respect to the Work licensed here. There are no understandings, agreements or representations with respect to the Work not specied here. Licensor shall not be bound by any additional provisions that may appear in any communication from You. This License may not be modied without the mutual written agreement of the Licensor and You.
F.2
Creative Commons Notice
Creative Commons is not a party to this License, and makes no warranty whatsoever in connection with the Work. Creative Commons will not be liable to You or any party on any legal theory for any damages whatsoever, including without limitation any general, special, incidental or consequential damages arising in connection to this license. Notwithstanding the foregoing two (2) sentences, if Creative Commons has expressly identied itself as the Licensor hereunder, it shall have all rights and obligations of Licensor. Except for the limited purpose of indicating to the public that the Work is licensed under the CCPL, Creative Commons does not authorize the use by either party of the trademark "Creative Commons" or any related trademark or logo of Creative Commons without the prior written consent of Creative Commons. Any permitted use will be in compliance with Creative Commons then-current trademark usage guidelines, as may be published on its website or otherwise made available upon request from time to time. For the avoidance of doubt, this trademark restriction does not form part of this License. Creative Commons may be contacted at http://creativecommons.org/. /* Local Variables: / / ispell-personal-dictionary: "ispell.dict" / / End: */

Repository Management With Nexus

Uploaded by

Copyright:

Available Formats

Repository Management With Nexus

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Repository Management With Nexus

Uploaded by

Copyright:

Available Formats

Ed. 3.0.

Repository Management with Nexus

Repository Management with Nexus

Repository Management with Nexus

Copyright 2011 Sonatype, Inc.

Repository Management with Nexus

Addressing Resources in a Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 The Maven Central Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Reasons to Use a Repository Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.4.1 Speed Up Your Builds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Repository Management with Nexus

2.4.2 2.4.3 2.4.4 2.4.5 2.4.6 2.4.7 2.4.8 2.5

Installing and Running Nexus 3.1

3.3 3.4 3.5 3.6

Installing a Nexus Professional License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.9.1 Evaluation Expiration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Repository Management with Nexus

Conguring Maven to Use Nexus 4.1 4.2 4.3 4.4 4.5

Using Nexus 5.1 5.2

5.5 5.6 5.7 5.8 5.9 6

Conguring Nexus 6.1 6.2 6.3 6.4 6.5

6.6 6.7 6.8

6.10 Managing Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Repository Management with Nexus

Repository Management with Nexus

Repository Management with Nexus

11 OSGi Bundle Repositories

Repository Management with Nexus

Repository Management with Nexus

A Migrating to Nexus from Artifactory

C.3 Conguring Nexus to Serve SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

Repository Management with Nexus

Introducing Sonatype Nexus

Nexus Open Source

Nexus Open Source Features

Repository Management with Nexus

Nexus Open Source License

Repository Management with Nexus

Nexus Professional Features

Repository Management with Nexus

Nexus Professional License

Choosing a Nexus Edition

Use Nexus Open Source. . .

Repository Management with Nexus

Use Nexus Professional. . .

Comparing Nexus Open Source and Nexus Professional Features

Repository Management with Nexus

Repository Management with Nexus

Proxying Public Repositories

Managing Releases and Snapshots

Repository Management with Nexus

Getting Control of Dependencies

A Nexus for Collaboration

Repository Management with Nexus

Release and Snapshot Repositories

Repository Management with Nexus

Addressing Resources in a Repository

The Maven Central Repository

Repository Management with Nexus

What is a Repository Manager

Core Capabilities of a Repository Manager

Repository Management with Nexus

Additional Features of a Repository Manager