On 10 February 2012 18:58, Markus Karg <[email protected]> wrote: > 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.
$ svn co release-tag-uri somedir $ cd somedir $ mvn release:branch -DbranchName=my-branch -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false $ cd .. $ rm -rvf somedir done. > > > > 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): That is a problem you will have anyway. If the customer reports a bug and you ask them what version are they running and the tell you that it's the one with foo-1.1.0.jar so it must be version 1.1.0 how are you going to explain to them that it could be any one of 50 different patch versions of that jar that you gave them. Your sanity *requires* that you do one of the following: 1. strip the version from the .jar files and thereby sidestep the problem. 2. bump all the jar files to keep the version number references correctly, and thereby remove the problem. 3. use a patch utility to modify the existing unmodified jar files to point to the new jar files... can be problematic... but if you have already give the customer 1.1.0 and you need to support that customer, well it's kind-of your only solution... the wise prince will pick option 3 initially and have the patch utility strip the version numbers from all the jar files so that option 1 can be applied going forwards, OR just go with option 2. > 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? > I never rely on a classpath in a .jar file anyway, I write my scripts for setting up the classpath such that either the classpath is pulled from a text file (now patching is easy, just add in the replacement jar files and update the text file) or I use a shell script to build the classpath one jar at a time picking the latest version of each jar... But at the end of the day, when I was doing patch fixes in a tightly controlled environment, I just resorted to replacing all the jars with the newer jars... that way we could say that we had tested all the 1.1.3 version jar files together and knew they worked and the customer just had to check that they only had 1.1.3 version jar files to know the patch had been applied. > > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
