This is roughly what I seem to be moving towards. Over the past couple
of days I have been converting a hierarchical project into an approach
similar to what you listed to get a feel for things
I have:
trunk/
/area1 - all dev code located under such
/group1
/artifact1
/artifact2
group.pom - no reactor - settings specific to group
site.pom - reactor - who's parent is group pom
/group2
/artifact1
group.pom
site.pom
/area2 - ancillary code for assemblies, test suites, deployment etc
/group1
//assembly-artifact
//acceptance-test-artifact
pom
I am hoping to separate out the areas we would normally co-locate in one
big structure. This should also allow me to provide clearer metrics,
e.g., metrics for unit tests at the development level and then metrics
for test suites at the other level and so forth.
-----Original Message-----
From: Michael McCallum [mailto:[EMAIL PROTECTED]
Sent: 29 May 2008 12:14
To: Maven Users List
Subject: Re: Maven and organization of source tree in SCM toolset
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
