On Sat, Feb 11, 2012 at 1:47 PM, Markus KARG <[email protected]> wrote: > Thank you for opening the discussion. :-) > > I see two problems with the idea of lib-1.1.1-SNAPSHOT in the maintenance > branch of what was previously released as lib-1.1: > > (1) The original app-1.1.0.jar was delivered to the customer with > META-INF/MANIFEST.MF containing "Class-Path:" entries for dependency loading > of lib-1.1.0.jar. If we now provide lib-1.1.1.jar, the JVM's original > classloader is unable to find the new jar, obviously. As a solution we could > deliver JARs that have version-free artifact names (so any bug fix JAR would > match), but we noticed that mvn deploy ignores this setting (while mvn > install respects it). So it simply does not work. Another idea would be to > provide virtually unchanged app-1.1.1.jar in turn containing a different > Class-Path entry for the renamed dependency, but I doubt that CruiseControl > is able to provide such logic so it will end up in lots of manual version > upgrading work, which we do not want to perfom manually (but certainly we > expect this to be the most "pure and clean" way to deal with it, as it > clearly expresses that a change in the lib results in a change of the app). > > (2) As we have to provide a tested "hot fix" jar ASAP after fixing a bug, > actually EACH commit to the SCM in the maintenance branch has to force a mvn > deploy on the CI server -- to the RELEASE (!) repository, as it will get > sent away to the customer and is not just "waiting" in the SNAPSHOT > repository for some fine day when we think it is time to assemble and ship a > completely updated maintenance installer bundle. As the project is in > SNAPSHOT state, it will publish to the SNAPSHOT directory. See, ALL commits > to the maintenance branch actually are completed fixes and there are no > commits for "half-done" things. So to make the artifact end up in the > "right" (public, RELEASE) repository, it simply must not be declared as > being a SNAPSHOT (while actually you are right, it in fact IS a SNAPSHOT, > but one that in turn is to be RELEASEd immediately). A workaround would be > to run "mvn scm:checkin release:prepare mvn:perform" by the developer of the > fix (instead of simple svn commit) but this looks a bit scary as we have to > do it for each single fix. In a large company with a second QA contact > having to test first this wouldn't be an issue I think, but as we simply > rely on the CI server to do the tests we in fact do not have a two-step > release approach but the CI server MUST release the fix if the tests are OK. > > So you see, we in fact have ideas for solutions, but we like to know what > the real "Maven Way" is to deal with this questions. :-)
The truth of the matter is that there's isn't aways exactly 'a maven way' for handling the transition of materials from the maven universe to the not-so-maven universe. However, in the case at hand, putting the version number in the name of the file that goes into the MANIFEST.MF classpath seems to pose a dilemma with or without maven. Redistributing a new jar with the old version number seems evil, no matter how you produce it. You might consider not putting version numbers in these jar file names -- or, alternative, distributing the patch via a 'patcher' that modifies that (those?) manifests. > > Regards > Markus > >> -----Original Message----- >> From: Ron Wheeler [mailto:[email protected]] >> Sent: Samstag, 11. Februar 2012 15:53 >> To: Maven Users List >> Subject: Re: How to readl with maintenance branches? >> >> There are better experts in the forum who know more about CI but I can >> make at least 1 contribution that might help. >> >> I am not sure that your situation is that uncommon. >> I am not sure why you would not have SNAPSHOTs on the maintenance >> branch. >> >> We would expect to have versions 1.1, 1.1.0-SNAPSHOT and 1.2-SNAPSHOT >> all in existence at the same time if we had a 1.1 in production and >> were simultaneously developing 1.2 while fixing 1.1 by creating a 1.1.0 >> version to be delivered to the 1.1 clients. >> >> We do not use CI so we would probably have a test environment where >> many of the modules would be quickly moved to 1.1.1 since they are not >> affected by the bug fix while some of the modules would be a 1.1.0- >> SNAPSHOT until they had passed the testing. >> >> I hope that this moves the conversation forward. >> >> Ron >> >> >> >> >> On 11/02/2012 7:11 AM, Markus KARG 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 -- we >> > expect that release:branch could do this in future but we have not >> checked it so far). >> > 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 >> > >> > >> > >> > >> >> >> -- >> Ron Wheeler >> President >> Artifact Software Inc >> email: [email protected] >> skype: ronaldmwheeler >> phone: 866-970-2435, ext 102 >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
