Our Philadelphia Breakfast Meetup is next Tuesday, September 25 from 8:30AM-10:30AM and only a few seats remain. Don’t miss out!
Jason van Zyl, Sonatype CTO and creator of Maven will be teaming up with Joel Confino, a Senior Consultant at Chariot Solutions and they’ll be giving informal talks to show you how you can dramatically reduce risk and improve software quality using Apache Maven or another build tool, along with Nexus, Hudson or Jenkins.
We’ve booked a space at The Hub Cira Centre (2929 Arch Street), and we’ve only got a few seats left. Just click on the link below and complete the form and we’ll be sure to save you a space and send you more details.
Reserve Your Seat
If you can’t make it, but know someone who would be interested, please feel free to pass along this invitation.
At Sonatype, the stakes are high, and so our standards must be as well. We toil over every detail of the product, tweaking, refining, until we get things just right.
We’ve cut another Nexus release: version 2.1.2 of both OSS and Pro contains several minor bug fixes.
- To download the newest version of Nexus Professional 2.1.2, click here.
- To download the newest version of Nexus Open Source 2.1.2, click here.
Here is a list of fixes in version 2.1.2 for Nexus Open Source: look at the JIRA release notes for the 2.1.2 release. For professional we fixed a number of minor errors:
- Nexus Professional has been upgraded to work with the latest version of the NuGet Package Explorer
- POST and GET operations in the new Maven Nexus Staging plugin have been updated to account for custom proxy configuration.
- A number of stability fixes have been made to NuGet support in Nexus Professional
“Dogfooding” is such a strange word, and I’m using it as a substitute for “Eating your own dog food”. As we do have a global audience, I worry that the term is somewhat provincial (and maybe a bit strange out of context). So here, here’s the explanation of this idiom on Wikipedia.
Sonatype is “recursive”. We’re a group of developers, creating tools for developers, getting feedback from developers. Logically, we tend to use everything we make. We’re the first customer. We deploy early development releases of Nexus Professional to our own Nexus Professional instance, we use repository.sonatype.org as a test case as the release approaches, and every feature we send out to our customers has been audited and tested internally. By the time you download our software, we’ve already been using it often for a few months or weeks, and we also make heavy use of Sonatype Insight to identify licensing and security risks.
Now, this blog post is a bit risky. I’m about to tell you about the security issues that the Engineering team discovered in Nexus when we ran Nexus through our Insight scanner during the Nexus 2.1 release. By doing this, I’m exposing people that haven’t updated Nexus to 2.1 to some risk. At the same time, I’ve given everyone ample notice to upgrade (I even made a video imploring people to upgrade), and I’m a big believer in transparency. If we know something related to security, you should know it as well after we’ve given people enough time to upgrade.
Whenever I teach a Maven training class someone invariably asks me to give some advice for migrating a large, complex Ant project to Maven. Toward the end of the class, I’ll take questions:
Participant: “Could you give us some guidance for migrating Ant projects to Maven? Is there a process that you recommend to make it easier.”
My (honest) answer: “If it’s a complex project, it won’t be an easy battle. Before you go down this road you need to understand what you are signing up for. It can be very complex, you may end up interrupting an active development cycle, and once you evaluate all of your options you might find it easier to first migrate to a repository manager. Maven’s not the big win, moving a repository is.”
In other words, I often find myself trying to discourage swapping build tools just for the sake of swapping build tools. While I do believe that Maven is preferable to Ant, I think that the build space often suffers from a belief that the grass really is greener on the other side. It might be, but is it greener enough to justify that work stoppage that is involved in taking a big important project and moving it to a different build technology? Often the answer is no. If it isn’t related to making money, switching a build system is often the last thing an enterprise wants to do.
In this post I’m going to talk about the process of migrating build tools starts with a repository manager.