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 can't 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 certified 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 specific versions of artifacts or prevent dependencies on everything contained under a specific 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 fine-grained control of the artifacts that can appear in a repository.
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 configure 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 configured, 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 specified in the procurement settings. If you stop procurement for a Hosted Repository, no additional artifacts will be retrieved from the Proxy repository specified 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 specific 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.
There are two main use cases for the Procurement Suite. In the first 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 upfront control over which artifacts are allowed during the development of a project. The following sections describe these two uses cases in more detail.
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 configured 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.
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.
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-first" model for organizations that want to control which artifacts make it into the development cycle.
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.
