- Hosted - the repo lives on disk
- Proxy - this is a proxy to another repository
- Virtual - this allows you to convert between repository formats, say M1 is hosted, you can create a Virtual proxy that converts M1 to M2
You can schedule tasks like cleaning up snapshots. There are RSS feeds for most of the things Nexus does so you know the state of your repo. It will download remote repo indexes. There is no database required for Nexus. Nexus provides a full set of REST APIs to all its features.
The only time you use a repository URL directly in Nexus is when you want to deploy an artifact. With staging & promotion you don't even need to use a repo URL to deploy your artifacts. Why have a stating & promotion strategy? What if you want to test something before actually release it? Enter Nexus stating & promotion. All release deployments occur against a single REST URL in Nexus. The URL can be set once in the corp-pom for all projects, regardless of repository. With templates you can define how Nexus creates this new stating repo. Currently, you can only stage your binary artifacts but not your site artifacts. If you stage something many times and decide only to keep the last build, you'll need to manually remove all but the last site's you generated (this assumes that you don't overwrite your existing site with each release). Since all of Nexus is controlled by REST URLs, you can build your own work flow to control when a repo is promoted or not.
Next up is procurement, how to control what artifacts are available to your projects. Procurement is effectively a firewall that separates the users from another repository (or repo group) in the system. By default, everything is denied.
Sonatype is planning on multiple versions of Nexus: Nexus (open source version, free), Nexus Pro, Nexus Enterprise (HA, Federation, etc.) and Nexus Compliance (legal, etc.).
No comments:
Post a Comment