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.
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: Continue reading
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. Continue reading
- Validate no local changes against your SCM
- Validate that there are no SNAPSHOT dependencies
- Convert the modules to the to-be released version
- Ensure the build and Unit/Integration tests succeed
- Commit the changes to SCM, then Tag the release
- 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. Continue reading
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. Continue reading