branch by artifact when necessary but I have found that the use of ranges and
api artifacts has almost completely removed the need for traditional
branching. By defining the ranges in the deployables you get a consistent
deliverable and can have parallel development and patching without
necessarily.
e.g.
trunk/
/groupId.a
/artifactid.a
/artifactid.b
/artifactid.c
/reactor (just used for testing and occasionally installing the group)
/groupId.b
/artifactid.a
/artifactid.b
tags/
/groupId.a
/artifactid.a
/1.1
/1.2
/2.1
/2.2
/1.2.1 (tagged from branch)
/artifactid.b
/...
/artifactid.c
/...
branches
/groupId.a
/artifactid.a
/1.2 (when trunk goes to 2+ any changes go on 1.2 branch)
The decision to increment the major version is for a breaking change. We use
very granular artifacts where each artifact serves one function and the pom
hierachy is by function not by module or group. This leads to significant
reuse and most artifacts stabilise very quickly and don't need changing.
Quick often also I have found that when it looks like a change in an artifact
would require a branch to support two different deliverables that splitting
the artifact in two allowed the change to be painlessly integrated into more
than one deliverable with no delayed integration hassle.
There are two things to consider as well what works with maven and what works
in your ide (with maven support). I don't use modules or deployed snapshots
because I have found eclipse support to be very unreliable with all sorts of
indecipherable classpath issues.
for ranges I use the [1,2-!) notation and start numbering from 1.1 so that
1.1-SNAPSHOT through to 1.n where n <2.0.0-SNAPSHOT match the range. If you
start from 1-SNAPSHOT or 1.0.0-SNAPSHOT then a range of [1,2-!) wont match an
installed snapshot which is probably why most people don't use ranges I
suspect. The other gotcha is that [1,2) will match 2-SNAPSHOT and
2.0.0-SNAPSHOT as its < 2.0.0. Another reason I suspect why people don't use
ranges. There were a large number of bugs fixed since 2.0.4 in relation to
ranges that have made them really work.
One day i'll get around to putting something up on the net about how i've
structured my projects and why.
On Thu, 29 May 2008 21:42:14 Bracewell, Robert wrote:
> Hi,
>
> I am trying to get an understanding of how users are using the Maven
> toolset with SCM tools such as Perforce to handle branching strategies.
> Does anyone know of any such white papers or further reading or be
> willing to share current practices?
>
> Do users tend to use a dense hierarchical structure to store the
> structure of the project that Maven builds and as a result branch the
> whole tree when doing a release or use a flat component structure thus
> promoting re-use and only branch the module that changes when doing a
> release.
>
> From my experience to date with Maven I am finding that the Maven
> toolset is geared to the hierarchical structure and does not lend itself
> well to a flat component approach. Are other users running into such
> issues or have you overcome some issues?
>
> --
> Robert
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
