maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: How to readl with maintenance branches?
Date Sat, 11 Feb 2012 21:36:48 GMT
On Sat, Feb 11, 2012 at 1:47 PM, Markus KARG <markus@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:rwheeler@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 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: rwheeler@artifact-software.com
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message