What is Maven 3's best practice to deal with "Maintenance Branches" (non-feature, bug-fix-only line of development)?
Our company needs to maintain a second development line besides "trunk", which we call " The Maintenance Branch", for those customers having signed a maintenance contract for one particular version (e. g. when signed for "1.1.0" he will receive bug fixes "1.1.*" but not features "1.2.*"). This means, besides "trunk" (which always contains the latest features), we have "branches/1.1-maintenance" (with "1.1" being the version number that this branch was forked from to further get bug fixed but not feature-extended). Due to the rules of the contracts, in that branches, all bug fixes must go in, but no new features. Before using maven this was simple, as it was completely manual work. But now we start using Maven, and get into some CI and dependency trouble. In "trunk" we always have SNAPSHOT versions, obviously, as we add features daily til we reach the release day. Just when we do a release (1.0, 2.0, etc.) we use the maven release plugin to get tagged branches (non-SNAPSHOT). >From those tagged branches, we copy our maintenance branches (using "svn cp" directly as we do not know how to tell maven to do so, BTW). So, the maintenance branch is NOT a SNAPSHOT version, as the release obviously is never a SNAPSHOT version. Now we like to use CruiseControl to do CI. We expect no problems in "trunk" as all are SNAPSHOT versions, so a change to a dependency will trigger "<maven2snapshotdependency>" to effectively compile and test the dependent project each time the dependency changes (as the name says: it detects snapshot changes of dependencies). Great! But what to do with the "Maintenance Branch"? As soon as we merge a fix for a dependency into that svn branch, we want CruiseControl to do CI. But we do not expect that "<maven2snapshotdependency>" will recognize the modified dependency -- as the maintenance branch is not SNAPSHOT (as it was created by copying the release tag in svn). We need a solution for THAT and have NO CLUE! We had the idea that we could just manually increase the version's "z" (from "x.y.z") of the product with each merged fix to express that this is a bug fix, and add "-SNAPSHOT" to all projects in the "Maintenance Branch" to activate the "<maven2snapshotdependency>" again. I assume that would work. But, besides a LOT of manual work (we have nearly one hundred projects), we would break the possibility to replace a JAR inside a customer's installation (i. e. to actually provide the fix to the requesting customer): As Maven's best practice is to add the version to the name, increasing the minor version to express the bug fix level would result in dependencies getting not found by the JVM's classloader anymore, as Java's "META-INF" dependency resolution technology cannot deal with "partially changed names" but insists on the exact same JAR name (and such the version number) of the last major release (i. e. abc-x.y.0-JAR instead of abc-x.y.1-JAR). We could provide a custom artifact name to the pom enforcing "abc-x.y.0.jar" always, but as it seems, this is not Maven's best practice (otherwise maven would do it automatically), so we assume there is a totally different solution we just do no see. So please, Maven Experts in this forum, enlight us! What is "The Maven Way" of dealing with "Maintenance Branches"? What is the big trick that we just do not see to get CI and dependency JAR loading running on bug-fix-only branches? Many, many thanks in advance. We know this is a very specific question, but everything else is solved and this one blocks us. :-) Regards Markus
