![](https://www.sonatype.com/hubfs/2024%20Blog%20Post%20Images/blog-default.jpg)
After teaching a number of Sonatype's Maven training courses, I've come away with an appreciation for how much knowledge attendees bring to the table and how it can affect the class. I wanted to take some time to talk about each class: Who are these classes designed for? What do they have to offer the beginner or the expert? What is the difference between 101 and 201? In this post, I discuss the goals of our courses: MVN-101 and MVN-201, and some of the philosophy behind the content.
The Essentials, The Fundamentals: MVN-101
In MVN-101, our introduction to Maven, all students walk away with something new, something they didn't know before they attended the class regardless of skill level, and that's a guarantee.
While this class focuses on fundamentals, many people using Maven every single day are still unfamiliar with the Maven Lifecycle. Sure, they've understood that default goals map to the default lifecycle, but maybe they didn't know exactly how packaging affects the lifecycle or what options are available for binding goals to plugins. I've had a number of advanced students start the class skeptical that it had much to offer them, only to come back after class is over talking about the various little details of the POM they had been overlooking.
Don't mistake the 101 in the course number for a signal that this course is designed to be simple. We don't compromise the content, and we move quickly. MVN-101 covers a lot of ground for an eight hour course. It is a survey of the POM, it is an introduction, and it moves quickly.
There is also something to be said for taking a step back to the fundamentals and learning about the history and motivation of the tool. Why are you using Maven? What are the alternatives? What differentiates Maven? What are the core conventions of Maven? Developers are most effective when they understand the core conventions and motivations behind the tool.
I've been asked if more advanced students should skip MVN-101, "If I am already familiar with the POM do I need to take the first class?" It depends, we split these classes up for a reason, we want to give people a chance to select the class (or classes) that are appropriate for them, but every time a students skips the first class and goes directly to the second there are always knowledge gaps about some of the more interesting portions of the POM.
My experience teaching Maven has convinced me that the vast majority of people using Maven could benefit from a quick refresh of the fundamentals. If you don't fully understand the Lifecycle, the finer points of versions, the motivations behind Snapshots and Releases, you are likely missing out on some critical information that could translate to a more efficient, easier-to-maintain build. If you use Maven in your organizations, someone should take a few hours to register, and attend this course.
There are two online MVN-101 classes November 3rd and 5th, and another on December 8th and 10th.
Advanced Enterprise Infrastructure: MVN-201
Our second class is geared toward the advanced developer and build engineer, students who want to learn about repository management and continuous integration as well as build best-practices. The focus of this class is on the who, what, why of repository management, but this focus also leads into continuous integration and how repository managers support workflow and collaboration. You've created software in MVN-101, now let's focus on working together in teams, enforcing standards, and building the infrastructure for collaboration.
In preparing for the upcoming 1.4 release of Nexus, I've tried to take stock of our statistics and my unscientific analysis of the book download stats suggests that only 1 in 10, at best 1 in 5, developers using Maven are learning about repository management. (Source? book PDF download numbers.) I view this as a challenge to try to convince more developers that developing without a repository manager is akin to rock climbing without a rope and harness. You should walk away from MVN-201 convinced that repository management isn't "optional". It isn't something "extra" that you may or may not integrate into your build architecture. It is the difference between a development team that can collaborate, and a development team that is bumbling around at deployment time trying to exchange JARs and support custom build solutions.
This class focuses on Nexus Open Source, starting with the basic installation of Nexus and progressing toward running Nexus as a component in a larger, enterprise deployment of Nexus and Hudson.
In MVN-201 the instructors are given more leeway to address specific student questions. We build more time into MVN-201 for discussion and analysis of course content because we've learned from experience that it is the students that drive more advanced content. If you are taking MVN-201, I'd encourage you to do some reasearch, come armed with questions and try your best to ask our instructors the most difficult, most esoteric questions you can.
We're teaching two online MVN-201 class on November 10th and 12th and December 15th and 17th.
Note: Some of you might be wondering why the 201 classes focuses on Nexus Open Source. If we were going to emphasize Nexus Professional, we'd have to have another two or three hours of instruction time in the class. We decided that it was essential to get the foundations of repository management and focus on the essential, basic elements of repository management. There is an overview of the features, and the instructor has the option of going through a section that demonstrates Nexus Professional.
![Picture of Tim OBrien](https://www.sonatype.com/hubfs/TimOBrien.jpeg)
Written by Tim OBrien
Tim is a Software Architect with experience in all aspects of software development from project inception to developing scaleable production architectures for large-scale systems during critical, high-risk events such as Black Friday. He has helped many organizations ranging from small startups to Fortune 100 companies take a more strategic approach to adopting and evaluating technology and managing the risks associated with change.
Explore All Posts by Tim OBrien