<iframe src="//www.googletagmanager.com/ns.html?id=GTM-TT8R4P" height="0" width="0" style="display:none;visibility:hidden">

Sonatype Blog

Stay updated on the latest news from the makers of Nexus

Using Your Repository Manager to Optimize Component Usage

We constantly receive inquiries about how organizations can get the most out of their repository manager. We thought it would be good to address this topic in a series of webinars. While preparing for the webinars, we looked at problems that afflicted organizations who aren't using a repository manager.

Nexus Tips: Disable Redeployment in Nexus

It's a fundamental tenet of Maven that release artifacts never change once they are released. This is enforced in Maven by the fact that once a release artifact or POM is located in the local repository, Maven will never check for an updated artifact in a remote repository. Once an artifact is released, it is considered a static, unchanging artifact. If you release an artifact and then subsequently change it (intentionally or otherwise), you're in for some fun as people will have different versions based on when they first retrieved it... that's a situation not exactly conducive to a repeatable, standard build. This blog post discusses a feature in Nexus 1.4 which can enforce this rule and help you avoid problems caused by the redeployment of release artifacts.

Summary of Maven How-Tos

We have a handful of Maven best practice and How-Tos documented in the blogs. Over time they get buried by newer posts, but the content is still just as relevant. Here is a summary of what exists:

Why Putting Repositories in your POMs is a Bad Idea

I get this question frequently so it is time to write down my thoughts on the answer so I can stop repeating myself. Here's the question:

Should I put the urls to my repositories in my poms or in my settings?

The short answer is: settings.

The long answer is: it depends.

There are two scenarios to consider here. Enterprise software (generally not published externally) and public software. Lets take Enterprise software first. Continue reading this post for a full explanation of both scenarios.

Best Practices for releasing with 3rd party SNAPSHOT dependencies

The Maven Release plugin enforces best practices for releasing Maven artifacts. In summary, the release plugin performs the following steps:

  1. Validate no local changes against your SCM
  2. Validate that there are no SNAPSHOT dependencies
  3. Convert the modules to the to-be released version
  4. Ensure the build and Unit/Integration tests succeed
  5. Commit the changes to SCM, then Tag the release
  6. Checkout the tag to a clean location and build/deploy the artifacts

Dealing with failures on Step #2 is where I want to focus today.

Maven Continuous Integration Best Practices

Continuous Integration is a development best practice that you need to be using in your process; it is an essential part of an efficient Software Development Lifecycle (SLDC). If you aren't using it already, then you should start, now. The main benefit of Continuous Integration is the ability to flag errors as they are introduced into a system instead of waiting multiple days for test failures and critical errors to be identified during the QA cycle. This post isn't about the virtues of using CI, it's about how to setup an optimal environment in a Maven shop. Here are seven tips for running Maven builds in a CI system such as Hudson.

Maven code: How to detect if you have a SNAPSHOT version

I answer this question often enough that I decided to burn it to a blog so I don't have to dig it out of the source anymore...and maybe save someone else the time along the way.

Here is the relevant code that Maven uses to determine if an artifact is a snapshot or not: