The an upcoming release of Nexus OSS will have full support for Yum repositories. Sebastian Herold, with gracious support from IS24, has developed and contributed his code and time to integrate his Nexus Yum Plugin into the Nexus 2.x line. We have heard from many Nexus users, who are heading down the path of continuous delivery, that Yum support in Nexus to deliver RPMs to production servers is a critical requirement. Several of our customers have been using Sebastian’s plugin for quite some time and have been impressed and so we’re really excited about the integration of Yum functionality into Nexus OSS!
Some of you might be interested in using our Yum support to facilitate application deployment to staging and production networks. A lot of companies that deploy Java and other technologies end up packaging applications as RPMs and deploying them through Yum on Redhat or Centos because it provides a really easy way to manage, deploy, and rollback software packages in production. It is much easier to tell Operations to deploy RPMs than it is to draw up a series of instructions for installing Jetty or Tomcat from a tarball. To support these use cases, we’re going to invest some of our time developing more documentation and training to support developers that need to adapt applications to deployments that depend on this Yum integration.
While Nexus is primarily used to support application development, this Yum support can be used on its own as a way to cache and simplify Yum repository configuration and package data. We’ll also be building out more examples of how Nexus can be integrated with infrastructure management tools such as chef and puppet.
Features of the Nexus Yum Support
As we integrate this feature into Nexus proper, here is the current list of features. We expect this support to evolve over time, but here’s what the plugin provides now.
Expose an existing Maven repository as an RPM repository – Use a Maven repository, hosted in Nexus, containing RPMs as if it is a Yum repository. This leverages the virtual repository mechanism in Nexus which allows you to use Maven tooling to deploy RPMs into a Maven repository but still allow Yum clients to interact with the repository using the protocol it understands.
Automated Refresh of Repository Data – Yum repositories are automatically updated if you upload/deploy/delete a new RPM into Nexus. In a traditional RPM repository you have to run createrepo to refresh repository metadata. With Nexus this is all taken care of automatically.
Full group support so that you can logically group a set of Yum repositories behind a single URL. If your infrastructure relies on a number of remote RPM repositories you can consolidate OS configuration to point to a single Yum repository that can aggregate multiple repositories into one.
Versioned views on repositories: http://your.nexus/nexus/service/local/yum/repos/releases/1.2.3/ gives you a Yum repository with all packages in version 1.2.3 in repository releases. This particular feature is a game-changer for companies that release software using RPM as a delivery mechanism.
Alias Definitions for Specific Versions eg. production=1.2 and testing=2.0 and access them via the alias: http://your.nexus/nexus/service/local/yum/repos/releases/testing/ and http://your.nexus/nexus/service/local/yum/repos/releases/production/ to get constant repository URLs for your servers. A new release is then applied to the server by setting the alias to a new version.
createrepo Nexus Tasks Types – Create Yum createrepo tasks manually via web interface. Multiple createrepo tasks on the same repository are merged.
Full Integration with Nexus Staging – Use Yum group repositories as target of staging repositories (Nexus Pro). Stage RPM artifacts to development environments configured to pull artifact from Nexus repository groups./li>
The way software is being developed has changed over the last ten years, it has shifted from companies developing the vast majority of their own software to a software development approach that depends on open source components that are freely available. Today, the vast majority (upwards of 90%) of Java-based applications are assembled from components. Very little of these applications consist of code that companies build internally. The extent to which open source components are being used is not widely known within companies that have thousands of applications and hundreds of thousands of downloads from the Central repository.
In last week’s webinar I discussed the trends we’ve identified and the tools we’ve developed to address this challenge. Tracking down where components come from, managing your application to account for changes in components, and dealing with security and licensing issues that relate to your application’s dependencies is our focus. If you develop software using open source components, here’s a video of my webinar. If you are interested in learning more about our Insight products and starting to keep track of the components you consume, go to http://www.sonatype.com/insight.
Let’s talk about security. You may have seen that Sonatype released research on the security of some of the most commonly used open source components. To be honest, the results surprised me. However, now that we are aware of the realities, it’s important to be practical about this.
Join me for 30 minutes at 11:00AM EDT (GMT-0400) on Thursday, April 12, when I will be sharing some of our findings and my thoughts on how we can build a more healthy open source ecosystem.
We’re very excited about the proposed move of Hudson to the Eclipse foundation. To get the project off the right start in its new home, Sonatype has committed to donating all our Maven 3.x related work to the Hudson project. This includes the Maven 3.x integration for Hudson itself, our Eclipse integration, and our Maven Shell integration.
To start the process of donating our Maven 3.x related work we are inviting everyone to an informal webinar where we’ll walk through and demonstrate the complete Maven 3.x feature set of the Hudson integration. We’ll field any questions, listen to feedback and record the session so that anyone may use the recording as a reference for the Maven 3.x feature set. Everyone is welcome!
The specific features of the Maven 3.x builder for Hudson we’ll be talking about at this webinar is as follows:
Global configuration templates
Settings and toolchains configuration upload and builder selection
Maven 3.x builder configuration
Build Comprehension Features
Basic summary: goals, module list with status, name, duration
Module details: active profiles, produced artifacts, consumed artifacts
Artifact details for the entire build
Auto archiving of artifacts
Auto fingerprinting of artifacts
We will also talk about how we integrated GWT, some of the benefits and drawbacks, and whether we think it’s a viable technology for Hudson. We have also created 10 new plugins and we’ll talk about some of those. Again, the webinar is going to be very informal, we really want feedback and questions from users in the Hudson community.
At Sonatype, we’re very excited about the Hudson proposal that has been posted to the Eclipse Foundation website today. We believe Hudson moving to the Eclipse Foundation is the best way forward for both the Hudson and Jenkins projects. Having Hudson at a mature OSS foundation like Eclipse gives enterprise users the confidence that Hudson will remain vibrant and will continue to grow, and provides an opportunity to reconnect the Jenkins and Hudson communities back into a single focused community. Sonatype supports Eclipse as a Strategic Member because we’ve been impressed by the infrastructure, process, and approach to project oversight. It’s an ideal place for Hudson to mature.
Looking at the interested parties in the Hudson proposal it’s apparent that more resources than ever will be poured into the Hudson project. Oracle and Sonatype have been working diligently to add fundamental architectural improvements to Hudson — which has paved the way for a new stream of innovation. VMWare and Tasktop have also indicated that they will be providing additional development resources, and we’re keen to start collaborating with them.
Sonatype also hopes to attract more enterprise-class contributors by taking the lead and contributing our core Hudson innovations to Eclipse. This includes all of the Maven 3.x integration that we have created to date. We were originally only going to provide a portion of our Maven 3.x integration to the OSS community, but we are so excited about Hudson moving to Eclipse we want to stimulate community adoption and wider participation by providing the best Maven integration possible.
The Hudson proposal still needs to go through the 30-day review period within the Eclipse community, but we really think Hudson has found its new home. The Eclipse Foundation is a highly respected organization, has proven to be a vendor neutral, and has fostered many successful projects. Eclipse would be a great place for Hudson and Jenkins to reunite and now would be an ideal time. It can only be a good thing for users and I sincerely hope that the Jenkins team will seriously consider this option.
Hudson plays a key role in Sonatype’s commercial product portfolio so we’re committed to making the project succeed at Eclipse. We will offer commercial support and value added functionality in our ‘Professional’ version of Hudson. We are planning to contribute all commercial work we’ve invested in thus far to the Hudson project but we have more commercial features in the pipeline. Our customers tell us that along with Apache Maven, Nexus, and m2eclipse, Hudson is a critical part of their software development infrastructure. Hudson will be successful at the Eclipse Foundation and Sonatype plans to take an active part in that success.