maven
Maven Release Non-supported SCM Structures
February 8, 2010 by Eric MilesAs 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
January 26, 2010 by Eric MilesYou 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
December 21, 2009 by Eric MilesIntroduction
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.