Disclaimer

The words and opinions expressed here are those of each article's respective author, and do not necessarily represent the views of CapTech Ventures.

maven

Maven Release Non-supported SCM Structures

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.

Maven Release with Flat Project Structures Revisited

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.

Maven Release Woes with Flat Project Structures

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.