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

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 including:

• The Maven lifecycle
• Maven plugins and goals
• Multi-module Maven projects
• The contents of the Project Object Model (POM)

Training course info:

• MVN-101
• February 22, 2011
• 11:00 am – 6:00 pm EST (GMT – 05:00)
• Enroll in MVN-101

Sonatype training is suited for teams of all skill levels. Whether you are just adopting Maven in your development infrastructure or have been using it for a while, you will benefit from having your team trained by Sonatype experts.

Core Maven contributors working at Sonatype carefully design our curriculum to cover topics from Maven basics to advanced development infrastructure design. To learn more about Sonatype training, click here.

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

Available training courses:

• MVN-101: February 7, 2011 at 11:00 am – 6:00 pm EST (GMT – 05:00) Enroll in MVN-101
• MVN-201 February 8 & 9, 2011 at 11:00 am – 4:00 pm EST (GMT – 05:00) Enroll in MVN-201
• MVN-101 February 22, 2011 at 11:00 am – 6:00 pm EST (GMT – 05:00) Enroll in MVN-101

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!

In my own experience teaching, introducing, and implementing Maven, I’ve found that even the brightest engineers among us, the people that don’t need instruction, even these people tend to hold on to one or two quirks from a previous build that should either be abandoned completely or refactored into a build that is more compatible with Maven.   When you move a project to Maven, or when you introduce Maven to a new set of engineers, it is important to make sure that everyone understands and agrees on the basic assumptions.

Without exception, every organization I have seen that just throws a group of developers Maven without giving them the support of training or connecting them with the experts has come away with a build that has some serious problems.   Sonatype’s training offering isn’t just about learning the syntax of a POM or figuring out how to pass the Compiler plugin more options. While POM syntax and plugin configuration are important things to know, this is the sort of information that can be self-taught.  The real value of Maven training and of engaging directly with Sonatype is the intangible experience of understanding why a build was crafted a certain way.

Here are some concrete examples of practices I’ve noticed in companies that have decided to skip Maven training:

• Non-standard Version Number – The pattern that Maven uses for versions isn’t optional, and you shouldn’t get creative when it comes to project versioning.   The version standard in Maven is simple (major).(minor).(point).  Some examples, 1.1.2 or 3.2.    I’ve seen people decide to use alphanumeric identifiers such as “r06″ in place of major versions, and I even had one client argue that, instead of version numbers, project releases should be named after colors on a spectrum.   Feel free to use all of the extra code names or project specific numbers you want to use, but keep them out of the Maven version number for a project.   Creative version numbers complicate Maven tool support and they make your project more difficult for people to approach.
• Putting a SCM Revision into a Version Number – This might be a controversial statement, but I’m going to take sides.  SCM Revision numbers have no business being included in the names of JARs or any other build output.   If you need to put a revision number into a properties file, use resource filtering, but avoid putting a Subversion revision number your dependency.   Doing this almost always adds a nasty runtime dependency on an SCM tool.   If you need to link a release version with a SCM revision number, use a Git or Subversion tag, don’t expose this information to your end-users.
• Creating an Assembly in a Parent Project – Assume that you have a parent project which contains submodules all to related to a single project.   If you haven’t taken the time to understand how the Maven Reactor orders project, you might think that the parent project is a logical place to put an assembly.  It isn’t, Parent projects are always built first in the Reactor.   Again this is something we touch upon in our training.
• Running Multiple Goals on the Command Line – I see this pattern emerge in the self-taught organization more than I would have predicted.    Someone adopts Maven without reading the book or taking training, and they decide that Maven works best when you can string together a collection of Maven goals on the command line.  Instead of “mvn clean install”, you end up with “maven compiler:compile jar:jar install:install”.   In other words, I see people start using Maven all the time without a full appreciation of the lifecycle.   The lifecycle is arguably the most important part of Maven yet a large majority of Maven users never fully grasp its significance.

I could go on and on listing more Maven misunderstandings, but the previous examples make my point.   If you are adopting Maven, you should make sure that your team understands why they are using Maven, why the tool exists, and what problems should and should not be solved with Maven.

If you are heading up the Maven adoption effort, budget some time for rudimentary training.  You can send developers to our focused training classes.   Based on what I’ve seen in the field, a little training can go a long way.

Interested in Maven Training? Find out more about Sonatype’s Virtual Maven Training and upcoming class schedules by clicking here.

Sonatype Training

You’ve completed Maven 101, learned about the Maven lifecycle, Maven plugins, goals and projects, all about the contents of the Project Object Model (POM) – so what’s next?

For those wanting to dive even deeper into Maven, Sonatype is offering an online training course, Maven 201: Development Infrastructure Design.

Maven 201 covers advanced topics such as:

• Advanced multimodule project architecture
• Enforcing standards with the Enforcer plugin
• Installing and configuring a repository manager
• Installing and configuring a continuous integration server

At the end of this training course, you will have advanced familiarity with the structure of a Maven POM and a Maven multi-module project.

Next training course:

• MVN-201
• January 20 & 21, 2011
• 11:00 am – 4:00 pm EST (GMT – 05:00)
• Enroll today

With Sonatype training, developers will learn the know-how directly from Maven experts. Our training materials were developed by well-known members of the Maven community.  Enroll today!

Upcoming Training Courses:

Maven-101

• September 27, 2010
• 8:00 am – 3:00 pm (PST)
• Enroll in MVN-101

Maven-201

• September 28 and 30, 2010
• 8:00 am – 1:00 pm (PST)
• Enroll in MVN-201

The training started well, when Matt mentioned that he thinks deleting a line of code improves the code you are working on. I totally agree and always found refactoring sessions that remove reams of code especially satisfying.

Manfred then goes on to list his impressions of Maven 201, including the points that really stuck out for him.

It is amazing how much you can theoretically configure the build with profiles and then lock things down with plugin/dependency management and the enforcer plugin – for heavy regulated environments or tight requirements this is ideal.

To follow Manfred’s experiences throughout his Maven training courses, go to his blog.