Introduction

Sonatype has released a nifty utility called Maven Shell that allows developers to execute maven goals/phases in a pre-loaded shell environment, significantly reducing the build time.  It does this by loading up a JVM, Maven, and any loaded plugin once and leverages that existing load for each subsequent build.  I downloaded the .10 binary and played around with it with a very simple multi-module project.  Here is a quick primer on some of the things you can expect from Maven Shell.

As I've mentioned in previous blogs (Maven Release Woes with Flat Project Structures and Maven Release with Flat Structures Revisited), the support for custom SCM structures is spotty in the release plugin.  It is highly desirable to leverage the release plugin as it provides a lot of functionality we do not want to have to duplicate.  By using profiles and activations, we can still leverage the release plugin with only marginal manual intervention.

You may recall my previous blog on Maven Release Woes with Flat Project Structures where I described in detail how the supposed 2.0-beta-10-SNAPSHOT flat structure release support did not perform as expected.  After some back and forth with one of the Apache developers, it has come to light that this conclusion is partially correct.  The term "flat structure" is contextual and in this particular context, the Apache group's idea of context was SCM.  SCM structure is what needs to be in one of a few known structures for the release plugin to function appropriately.  In the end, another JIRA ticket was created for a different use case, albeit very similar to the previously closed ticket.  I'll review what flat structure does work and some variations that don't.

Introduction

The last two clients I've been on, I was asked to determine how Maven could be leveraged (better) at their site.  One client was not using Maven at all and the second client was already using Maven for two years.  Both clients were using Subversion and both had their own custom repository structure.  The first client had a truly unique setup of how trunk/branches/tags were used and was nothing like I had seen before.  There was only a single trunk, a single branches, and a single tags folder, and ALL projects were in numerous folders based on system functionality under these.  The second client followed a more traditional model, with each project on the root of the Subversion repository with each project having a trunk, branches, and tags subfolders.  However, both employed a "flat" project structure to make lives easier with their chosen IDEs.