Since its release four years ago, Sonatype Nexus has grown to support many repository formats. And most users of build tools including Gradle, Leiningen, SBT and Ant/Ivy have started to realize the numerous benefits of using a repository manager.

Using an MRM has become accepted best practice for Maven users.

The benefits of proxying external repositories and deploying third party artifacts are only the beginning. Things really take off when you start deploying your internal components to Nexus, making them immediately available to everyone.

Nexus: More Than Basic Repository Management

Nexus is evolving to help you manage the security and licensing aspects of your components.  In order to show you how, we have made this a focus of the latest release of the book Repository Management with Nexus.

The book now shows you how to access Insight information for a particular artifact. There are concrete examples on how to inspect and fix security issues, thanks to the information available in your Nexus search results and the linked information on the public security databases.

Note: When you read this, don’t forget to configure your Routing correctly to ensure that aspect of your Component Lifecycle Management (CLM) efforts is covered and no information about internal artifacts leaks to the public.

Part of your effort to get control over your component usage is to secure your sources. Part of that effort is to start using the Central Repository via secured access.

If you are using Nexus Professional this is as easy as upgrading to 2.2 and changing the Remote Storage Location URL. It is also available now for Nexus OSS by getting a $10 token here and making the same changes. Other repository managers will be supported soon.

Nexus 2.2 Now Included in Nexus Book

We have also made improvements and general updates to cover the latest Nexus 2.2 release. Among the topics changed are settings.xml setup explanations, documentation for capabilities, updates to the plugin creation chapter and many more.

Still, with all these improvements we realize that nothing is perfect and you might have questions or ideas for enhancing the book. If that’s the case, we encourage you to file issues with your wishes or attend one of our Nexus training classes. Also, don’t forget that the book is open source and we do take fixes as pull requests.

Component Lifecycle Management is Key

These improvements to Nexus are part of a larger Component Lifecycle Management solution that is provided by Sonatype. CLM helps you ensure the integrity of component-based software by analyzing usage and providing governance and policy enforcement during development.

As demonstrated by these Nexus improvements, CLM is integrated directly into your development infrastructure – including IDE, CI and repository manager tool of choice.

The answer to the “Why?” is often a mumbling about not enough time to upgrade and upon closer inspection,  I find that it was never honestly tried. It seems there is still a perception out there that Maven 3 is a new major version and is largely incompatible. However – that is completely false! It was true way back when Maven 1 was replaced by Maven 2, but is not true for the move to Maven 3. In fact, apart from a few minor edge cases, Maven 3 will work as a complete drop in replacement for Maven 2 with improved performance, better error reporting and many more enhancements.

One of the main goals for Maven 3 was to make it more suitable for embedding Maven in tools like an IDE or a CI server. This brings me to the second question “Are you sure?”. When asking about the IDE used for development on the project in question, the most frequent answer is Eclipse. I then find that a stock install of Eclipse with the m2Eclipse plugin, as provided in the last two Eclipse releases, is used. These integrations embed Maven 3 and therefore any work you do with your project in the IDE is actually using Maven 3. Assuming that it works, you are ready to move to Maven 3 on the command line. That is pretty much always the case since how would the developers otherwise do any work?

Now some people object that they have in fact configured Eclipse to use an external install of Maven 2. While that is correct and works for any execution of Maven from Eclipse that uses the “Run/Debug as Maven” features you are still using Maven 3 in many cases. In fact, compilation of your source on the fly, any POM editor work as well as “Run As – junit-tests” and “Run As – Java Application” is still being done by the embedded Maven 3. So whatever you do…you will most likely have Maven 3 in the mix. And realistically a mixed use case like that will be more complex and troublesome than an outright upgrade to Maven 3. Try it!

Writing extensions for sophisticated integrations and plugins like Tycho used for Eclipse and OSGi related development with Maven OS is in fact only possible with Maven 3 and therefore you may already be using Maven 3 for use cases like this.

With this knowledge and understanding you should now be ready to install Maven 3 and benefit from its increased performance and maybe fix some of the errors in your pom that it will find. While you’re at it, you should probably start creating a company POM and controlling your plugin versions used in your Maven builds. Then you could upgrade e.g. to the new Maven Compiler Plugin 2.5.1 and get another performance boost for your builds. To make sure that nobody sneaks in the creaky Maven 2, you could introduce a Maven Enforcer Plugin usage …

If you would like to learn more about Maven usage tips and tricks, you can join me in one of our upcoming virtual Maven training classes. — Or join me in our upcoming Nexus virtual training class to find out why and how you should really be using a repository manager with any build system that has built in dependency management (and they all do today).

See you then,

manfred

I don’t often teach our training classes in Maven or Nexus, but when I do, I always tend to get interesting classes. I’m halfway through a on site training class today that, so far, has stood out as a unique experience for me as a trainer. Usually you set up your slides, hand out the materials, and start running through the content. It often takes a class and an instructor an hour to find a good cadence for teaching and answering questions. One metric I keep track of is the amount of time spent delivering content from slides vs. the amount of time spent answering questions. I strive for 75/25 – 3/4 of the class is focusing on content, 1/4 of the class is focused on answer student questions.

The first thing I do in my classes is implore (literally plead) with the students to interrupt me. “Ask questions. If you don’t this class won’t be valuable to you.” I do this because all too often I have a class of students that seems reticent to ask question or interrupt. Who knows why, maybe they don’t want to ask a dumb question (those don’t exist), maybe they are taking the class with a manager and they don’t want to look bad? Whatever the case, silence is the worst thing an instructor can get in response to the question: “Are there any questions?….. no?….. anyone? Ok. Anyone want to make a statement?…. no? alright, let’s move on…”

The worst classes for an instructor are the classes that sit, silently listening to the slide content. Maybe they nod every once in a while, but it is impossible to read them. 8 out of 10 times you’ll get some feedback from some in these classes that the class didn’t meet their needs because it didn’t focus on X, Y, or Z. (My first response to this is always, “did they ask questions?”) In these classes, the instructor doesn’t learn anything from the experience, and reading slides for 7-8 hours is torture. I like questions, and I thrive on difficult questions and people that need convincing. The best Maven training classes have at least one or two students that want to talk about some difficult topic like Ant Migration or how to use Gradle.

What I’m trying to say is that I hate “teaching” a training class, I’d much prefer to engage a in back-an-forth because this is what I think training should be I don’t go as far as using the Socratic method to elicit participation because there’s just too much content to cover, but I want someone to stop me midsentence and ask a question like: “Why? Justify that statement about dependencies. I don’t agree with that.” Our content is purposefully designed to get a response from the students, and our trainers are trained not to deliver the content but to know everything there is to know about the topic. This is the only way to teach a topic.

On Tuesday I started our training class, as I normally do. I asked every student to introduce themselves and talk about what they wanted to gain from the class. After 10 seconds of this I could tell this wasn’t going to be a normal Maven 101 experience.

Me: “Ok, so introduce your self and tell me what you are trying to get from the class?”

Typical response from this class: “We running a Jenkins build with over five thousand builds and we’re having specific problems with the -U flag. We need to find a way to write both a custom Nexus plugin and a custom Maven plugin to change the way the CI server works with the respository. Also we’ve tested Smart Proxy and we have some feedback…….

This continued for about ten students, and this is the moment in time where the instructor stands there, blinking, and wonders why any of them are in a Maven 101 class. While I do think that everyone *can* benefit from a return to the basics, I was teaching a room full of developers that were likely more qualified than some of the people on the Maven committer list to discuss Maven internals.

In these cases, our trainers, myself included, are taught to adapt quickly. I wasn’t going to dwell on the 101 content, I was going to run through it, but skip the sections that made no sense for this audience. For example, if everyone in the room has had experience writing a custom Maven plugin, I’m fairly certain they know what an artifact coordinate is, and I’m also sure they understand how to install Maven. Because our training material is modular, our instructors have the ability to mix and match content if they find themselves standing in front of a class that is way too smart to train .

When all your students understand Maven basics and even most advanced Maven topics, the class turns into a seminar on best practices and a discussion. Instead of talking about what a dependency is, you end up getting realtime feedback about how Maven works – “You know it would be much easier if we could change how the updatePolicy worked, how do we do that” or “m2eclipse lifecycle mapping is a real pain in the neck” (an observation I agree with BTW). The class I was about to teach turns into a conversation, and I’m detailing best practices about deployment.

Now this doesn’t work for all training classes. Especially our virtual training, on our virtual training it is difficult to change the flow of the class because we do have people who approach us who have never used Maven, and we’re usually teaching to multiple companies. This “seminar” approach isn’t appropriate if members of your team need to drill into the basic of Maven, it only really works well when everyone in the class has demonstrated a solid baseline.

Generally, I’m noticing this more and more. Nexus and Maven are so widespread and so well regarded that people understand the concepts already. This wasn’t the case when we started five years ago. These days I walk into a place and several of the students are already sold on the imperative to run a repository manager. They used our online documentation to bring themselves up to the point where they are often too smart to train.

The newsletter includes the following stories:

• Sonatype Insight: Get the Back Story on Our New Product
• New Nexus Training Available Now
• Webinar: Increase Benefits and Reduce Risk of Open Source
• Recently on Our Blog: Why You Need to Monitor Your Components
• Maven Training Dates

If you would like to get on our mailing list so you’ll receive the newsletter automatically, please subscribe here.

Nexus Best Practices will give you the knowledge and practical instruction to get the most from your Nexus repository. Take this class to get up to speed quickly, gain better control over your component usage, and see faster build times.

This virtual class is ideal for individuals and teams who are looking to get up to speed with Nexus quickly. It is also appropriate for existing Nexus users who are interested in gaining a greater understanding of the fundamentals, as well as advanced techniques and tips and tricks.

After this course, you will:

• Understand all of the benefits of using a repository manager
• Be proficient with installation and maintenance of your Nexus instance
• Use the Nexus user interface effectively as both a user and an administrator
• Support Nexus as a key component of your enterprise development infrastructure
• Gain control over the artifacts that can be proxied from external Maven repositories
• Understand how to use Nexus to support staged releases

Our first class is scheduled for Thursday, October 20 from 11:00AM-5PM EDT (GMT-0400).

Enroll today

Learn more

In this post, I answer some of the questions that came up in our last training session.

Q: Is there a flag to echo the md5/sha1 checksum during deployment?

Not directly via the deploy plugin flags, but with a separate plugin: http://code.google.com/p/maven-checksum-plugin/. Checksums can be created during install if desired, click here to read the Maven documentation about this method. Checksums can be calculated using typical POSIX tooling (md5sum) and shell scripts as well.

Q: How do I select a SSH Private Key to use for SCP file transfers?

This is answered in the Maven Documentation here. Also, Pascal Thivent, a very active Maven expert on Stackoverflow, has a great answer for this on StackOverflow here. The answer is that you can specify which private SSH key to use in the server element of your Maven settings as follows:

<server>
        <id>myserver</id>
        <username>matthewmccullough</username>
        <privateKey>~/mykeys/id_rsa</privateKey>
        <passphrase>myphrase</passphrase>
</server>

Q: For an Ivy repository, how can an artifact be retrieved from Maven?

If the canonical repository format is Maven, then Ivy is really acting in compatibility mode with Maven and all is well. However, if the repository is in Ivy format (no pom.xml files), the story is a bit more rough: http://markmail.org/message/ohmlv5mk7j7i4smf. My observation is that even when folks are using other build tools like Ivy, Ant, Gradle, Buildr and Leiningen, they typically all agree on the Maven repository format. Most if not all of the build tools recognize and thus have a “Maven repo reading” compatibility.

Note: as the community moves forward on the Aether library, you should see tools start to either converge on best practices when it comes to repository access or get left behind it they decide to interact with repositories in a non-standard way. Tools that interact with Maven repositories should all be using Aether.

Q: Are there any tutorials about writing maven plugins?

Yes, here are two good sources of information:

• The Apache guide: click here
• The Sonatype book: click here

On February 22, 2011 we will be holding an extra session of Maven 101: Maven Mechanics. This course is the premier Java developer training course. It covers Maven installation and configuration, explains the motivation behind Maven and gives an overview of related development tools. You will leave this Maven tutorial equipped with a full understanding of the Maven Project Object Model (POM) and a firm grasp of the underlying fundamentals of this development kit.

Enroll in MVN-101 today before spaces fill up!

Sonatype has leveraged AWS’s great set of command line APIs and written scripts on top of them. We just invoke “instantiate-lab-machines-small.sh 10″ and poof, we have a set of pristine machines for the students, all running VNC as a service (for remote desktop access) and pre-setup with the latest version of Maven, Eclipse, and the m2eclipse plugin. No teardown. No hardware maintenance. No hassle. We even have a subsequent script that lists out the machines hostnames for each copy-and-paste into the email that goes out to the students.

While our overhead for training infrastructure is smaller than it has ever been, our use of AWS is about much more than just the reduction in cost associated with cloud-based hardware, we’re much more agile because it takes us 10 minutes to create infrastructure. I don’t even want to imagine owning these lab machines. As our training offerings expand, we’ll be using more and more of these lab machines. I can foresee a day when we’ll literally have a set of AWS machines up around the clock to serve our training offerings. Until then, it’s pay by the hour — the raison d’etre for cloud based offerings.

Click here for more information about Sonatype Training.