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.
This is a big release. We’re announcing the immediate availability of Nexus 2.1, the first minor version update since the Nexus 2.0 release earlier this year. This simultaneous release of both Nexus Open Source and Nexus Professional caps off months of effort to implement two major features in Nexus Professional:
User Tokens – Developers who need to authenticate against a Nexus server can now make use of user tokens. This is a pair of authentication keys which can be used in your settings in lieu of storing a plaintext password. Storing a plaintext password in a build has always been a bad idea, and this new version of Nexus lets you access Nexus securely.
Advanced Staging Capabilities – Our Engineering team upgraded one of the most popular features of Nexus, the Staging capability. With this newly improved staging subsystem your staged releases now benefit from a range of advanced features, such as atomic deployments and closer integration with Nexus REST services. This feature is an implement in Nexus Professional as a Maven Staging plugin.
Evaluating Nexus Professional just got a whole lot easier
If you are evaluating Nexus Pro, you’ll benefit from an easy to use installer, which was designed to automate the installation, configuration and set of Nexus on Windows, OSX and Linux. With this new installer, users are able to customize where Nexus will be installed and what port Nexus will be configured to listen on. This installer will even automate the setup and configuration of a set of simple evaluation projects. It has never been easier to get started with your Nexus Professional evaluation. Download a Nexus Professional trial and get started.
Nexus OSS 2.1 – Security and Bug Fixes You Need
Nexus OSS 2.1 has approximately 102 bug fixes – everything from an upgrade to Jetty 8 to security fixes. Nexus OSS 2.1 is faster, more secure, and more stable thanks in large part to our Insight product. Engineering ran the Insight report against our own software and identified some critical security bugs. If you are using a previous version of Nexus 2.0 (or if you are using an earlier version of Nexus 1.x) there is no good reason not to upgrade immediately.
When you use Nexus, it is more than a UI. It is a collection of services available for you to automate. With these services you can integrate Nexus in whatever workflow makes sense for you. As a developer, this is what I look for in a product: something beyond the UI, something I can automate, and, most importantly, something that is documented. In Nexus, we’ve made it easy to start integrating Nexus REST services into your workflow by providing extensive documentation.
Yesterday’s post was all about automating Nexus with REST services, and today’s post is focused on giving you the tools you need to access the hundreds of REST endpoints you have access to with Nexus. If you are trying to automate anything in Nexus, you should know that there are two ways to “read” the Nexus REST API. You can access plugin documentation via the Nexus UI, or you can use a tool like Firebug in Firefox or Chrome’s Developer Tools and inspect the requests generated by the Nexus UI.
I recently had a request from a customer for some guidance on how to automate Staging in Nexus Professional from Gradle. Here was his core problem: he had a series of builds that needed to deploy to a staging URL and he was wondering if it was possible to automate the closing of a repository from Gradle. It is. While we’ve made it easy to do this in Maven with the Nexus Maven Plugin we didn’t have the equivalent example in Groovy. This post gives some guidance to anyone who needs to call out to our REST services from Groovy.
As Nexus Professional exposes every feature as a REST endpoint it is very easy to automate these interactions in just about any language. This sample demonstrates who to incorporate calls to Nexus REST APIs directly from your build. It also provides a model for parsing JSON responses from Nexus and posting JSON requests. If you are interested in more of these examples, please let us know in the comments of this post. (One thing is sure, this particular example could use some improvement, please be harsh.)
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.