Brian Demers

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.

A migration story from Subversion to Git.

The goal of this blog is to show an updated and more involved example then what is currently located on the plexus site. This will cover creating a couple of components and explain the different ways to inject your dependencies. This example assumes you are using maven 2 to make your life easier.

For a number of reasons you might want to require your developers to use a staging repository. Staged software releases in Nexus Professional are the best way to enable your development team to push a release to an artifact repository such as Nexus while providing management and quality assurance with a way to test and approve a release before “burning” it to production. If you want to learn how to make a staged release, you can watch this video. or read the remainder of this blog post.