Re: How to readl with maintenance branches?
We would work SNAPSHOTS until the patch was ready for release and then release a full 1.1.1 release with all components included in the release. Our portals do not have a single release for all the components. We treat our own modules like 3rd party modules and are no more bothered by a version 1.1.1 calling a version 1.1 component any more that we are bothered by out 1.1.1 version of our code calling a 1.1.12 version of log4j from Apache. This takes a bit of organization when planning a new maintenance release but the 15 minutes is not a big deal for us if it means not having to rebuild about 60 modules that did not change in a typical maintenance release. This may not be a best practice but it served us well for several years of intense development and maintenance. Ron On 11/02/2012 4:36 PM, Benson Margulies wrote: On Sat, Feb 11, 2012 at 1:47 PM, Markus KARGmar...@headcrashing.eu 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:rwhee...@artifact-software.com] 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
How to readl with maintenance branches?
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
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: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: How to readl with maintenance branches?
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. :-) Regards Markus -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] 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
Re: How to readl with maintenance branches?
On Sat, Feb 11, 2012 at 1:47 PM, Markus KARG mar...@headcrashing.eu 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:rwhee...@artifact-software.com] 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
