-----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
