jboss.org Switches to Nexus
jboss.org Switches to Nexus
Join the DZone community and get the full member experience.Join For Free
The CMS developers love. Open Source, API-first and Enterprise-grade. Try BloomReach CMS for free.
2010 has been a busy year for Sonatype and its VP of engineering Brian Fox. Last month they began migrating Java.net projects over to Nexus. This weekend, they helped jboss.org set up a new Maven repository using the Nexus Pro repository manager. DZone spoke with Brian Fox about the jboss.org migration project and the progress with Java.net.
What jboss.org Users Need to Know
Nexus will provide a new interface for the Maven repositories on jboss.org. It will make jboss.org project artifacts more searchable and provide better release staging and automatic proxying from third-party repositories along with many other features. Projects will be able to use the new Maven repository once they configure their settings.xml. Most projects will require just one URL that refers to a repository group in order to download the project's dependencies.
A simple HTTP call configured in the pom.xml or the altDeploymentRepository Maven deploy plugin option is used for deployment to the repository. Release deployments go through a staging and verification process. Snapshot deployments are deployed immediately to the repository. More info on the settings.xml and deployment configuration can be found here.
Some other important points mentioned by the jboss.org FAQ:
- Artifacts from the central Maven repository or any other third-party repository are automatically saved by Nexus as long as they are retrieved through the repository group's URL. They do not have to be added manually.
- jboss.org artifacts will not be automatically synched to the central Maven repository in this first release, but future releases of the jboss.org repositories will will provide this capability.
- Your Maven settings.xml will have to be updated with the new repository URL and your poms will need to be updated with the new snapshot URL to download and deploy snapshots.
- To release your project using the new Maven repository, you first deploy your project to the staging URL to create a temporary staging repository in Nexus. Using your jboss.org account, you will log in to Nexus and close the staging repository. From the staging repository you can verify the release artifacts and either drop them into the staging repository and restart the release process, or you can promote them to the release repository.
- The current releases repository (repository.jboss.org/maven2) has been split into smaller repositories. Most developers will still be able to use a single repository URL for their builds. This URL refers to a Nexus group of several hosted and proxy Maven repositories.
- Access to the old Subversion repository has been disabled to ensure that all artifacts are transferred correctly to the new repository. jboss.org has created a Nexus plugin that will show you who uploaded a specific artifact. That information will be transferred from the current Subversion repository to the new repository that will indicate the user who last modified an artifact.
Brian Fox gave DZone the details of the jboss.org migration and other projects:
"Historically the jboss.org and Java.net repos have been painful for Maven users. The reasons for this pain differed in each case, but affected a large section of the community because of the popularity of the artifacts they contain.
The jboss.org repo generally had decent metadata and release practices. The major concern in this repo was that the single repository contained artifacts in the following categories:
1) jboss.org original artifacts
2) Copies of artifacts from other repositories
3) Artifacts with the same coordinates as artifacts in another repository, but that had been patched or otherwise altered.
Ideally the repository should have contained only artifacts in category 1. Category 3 is what caused the most pain because as soon as you pulled some artifacts from the jboss.org repo, you potentially got "polluted" with these altered artifacts.
We worked with the jboss.org team to develop tools that could scan the repository and categorize all the artifacts into the categories described above. Using that information, we where able to separate them into unique repositories in the new Nexus Pro repo, meaning now you can select which artifacts you want to include based on the url you use. Nexus' ability to logically group repositories allows jboss.org to merge these now separated repos back into a view that matches the old repo, making the migration transparent for existing users.
The java.net repo was a beast of a different color. In addition to all of the problems described above, this repository suffers from the lack of oversight and quality. We found thousands of artifacts that referred to repositories that no longer existed, contained snapshot dependencies, weren't in the proper folders, etc. This as taken one of our developers almost a month to sort out, but it's finally just about done. These artifacts will be synced into Central and then we are working with Oracle to prepare a Nexus Pro instance that can be the deployment location for these projects going forward.
In addition to the repository cleanup, the jboss.org (and soon java.net) projects are now able to use the Staging and Promotion tools in Nexus Pro that are used in many other OSS forges like Apache, Codehaus, Scala-tools, Terracotta, etc. This allows the developers to stage a release, have automated quality checks occur and then perform their voting and validation phase before promoting the artifacts to the public release repository. This process makes it dead simple for the projects to ensure the basic quality of the releases are maintained, which helps the entire community, which is why we make Nexus Pro available to OSS projects for free.
For projects that are too small or otherwise don't want to host their own instance of Nexus Pro, we maintain an instance at oss.sonatype.org where any OSS project can sign up and gain all the benefits of a managed repository, including dedicated Sonatype assistance with their builds. We have almost 400 projects using this instance, including Amazon Web Tools, Google App Engine, Google Inject, Jetty, and many more. Users of this system are able to get their releases published to Central in less than an hour once they are configured to pass the automated quality checks. It's never been easier or faster for projects to release their artifacts to Central.
Based on the outstanding adoption rate of our tools in the community, It's clear that projects of all sizes really want to provide a quality product for their users in the form of clean artifacts, metadata. This just wasn't easy to do in the past. Sonatype is making it a priority to empower these projects by providing first class tools and
self-serve access (with quality enforcement) to central."
Opinions expressed by DZone contributors are their own.