The Nexus team has been hard at work producing a new plugin model for Nexus that allows us to create some new and exciting Professional features on top of the OSS core. The first release of Nexus Pro will contain 4 new plugins:
Staging and Promotion
Staging
and promotion is designed to allow projects to be deployed to independent, temporary repositories. The contents of this repository is then evaluated and eventually either promoted or deleted. When
promoted, it is merged in with a target repository and all appropriate metadata is updated. This implementation of Staging and Promotion requires no changes on the Maven side other than updating your distributionManagementUrl.
Staging works by defining a new url that is used for all deployments. Profiles can be created in Nexus to determine how artifacts are staged. The profile specifies name and id templates for the temporary staging repo, which groups will automatically contain the repository, and who to notify when the staging is complete.
When a new deployment occurs, Nexus selects the profile based on the artifact type (snapshot or release) and the repository target (regex on the artifact path). Nexus then notes the user and ip doing the deployment and makes a new staging repository instance to hold the artifacts from this build. This allows multiple parallel deployments to occur simultaneously and the artifacts are placed in independent repositories. When the staging is finished, the user goes to the Nexus UI and closes the repository to new artifacts. An authorized user can then later decide to promote or drop this repository. When the promotion is selected, the user selects a destination repository, and Nexus then merges the contents automatically, updating the metadata along the way.
Future enhancements include a maven side plugin to automatically start and stop staging based on a unique build id, workflow extensions for automatic handling of staging promotion and verification (ie tie into CI and other metrics), and vote based decisions on promotion.
Procurement
Procurement is designed to create a secured, hosted repository that contains all artifacts needed for a build that is controlled to allow only approved artifacts. Enterprises currently typically operate in one
of two modes:
1) Developers have free access to repositories, but QA, CI and official builds are performed against a manually populated hosted repository.
2) Developers are completely blocked from external repos and only have access to a manually populated hosted repository. We'll call this "Ask First"
In either mode, the artifacts must be manually loaded into the sanctioned repository. This is tedious and error prone. Many of the artifacts are required only for the build itself (org.apache.maven.*) yet they must still be manually populated.
The Procurement repository is a new type of repository. The repository is associated with another internal target, either a repository or a group. An authorized user is able to browse the internal target and selectively approve artifacts. They may be approved by groupId with wildcard, group and artifact, and group, artifact and version. When a request is made against the repository the current
contents are served. If the requested artifact doesn't exist, it will be retrieved from the target only if the rules explicitly allow it. Allowing the wildcard solves the problem of constantly having to approve build only artifacts like org.apache.maven.*
In a normal scenario, the developers may be configured to build against a group containing their required repositories. The qa and/or the CI system would be configured against a Procurement repo using the developer repository group as the internal target. This would allow developers easy access to the artifacts required, but still provide control over the artifacts used in official builds. If desired, the developers may also be shielded by the Procurement repository, which would put them in "Ask first" mode where things must be pre-approved before they can use them.
The Procurement repository is treated like a hosted repository in a way that excludes it from scheduled tasks that may remove artifacts accidentally. This is done to maintain a higher level of integrity and reproducibility.
Future enhancements include the ability to automatically approve based one license, the ability to approve an artifact and all transitive dependencies in a single operation, and taking a physical snapshot of the state of a Procurement repo for later reproducibility and tracing.
LDAP Authentication & Authorization
The LDAP functionality supports two modes:
1) User/Pass is stored in LDAP only. This means that the normal user to role association is preserved and we only hit ldap for authentication.
2)User/Pass and group is stored in LDAP. The groups are automatically to a Nexus role by id.
P2 Repository Proxying
Nexus has the ability to host P2 proxy repositories. This allows traditional caching and proxying of P2 artifacts to save bandwidth and provide internal stability when provisioning P2 based artifacts such as Eclipse.
Future enhancements include P2 Repository grouping and Hosting.
We are wrapping up the testing of these new Pro plugins along with Nexus 1.2. The Professional plugins will be released to a handful of selected Beta clients first for testing and user story validation. Once that is successful, we will begin a much wider Beta program prior to the GA release, which we anticipate would occur in the Nexus 1.3 timeframe of Mid-January '09.
.jpg)
