You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by "Bracewell, Robert" <rb...@qualcomm.com> on 2008/05/29 11:42:14 UTC
Maven and organization of source tree in SCM toolset
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
Re: Maven and organization of source tree in SCM toolset
Posted by Michael McCallum <gh...@apache.org>.
On Thu, 29 May 2008 23:52:35 Bracewell, Robert wrote:
> 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
One key thing is that my pom hierachy looks like this...
root
-> jar
-> service
-> api
-> model
-> jaxb2
-> webapp
-> abstract webapp
-> assembly
each of these parents contains the plugin configs needed for the particular
artifact. Any given artifact would inherit from one of there functional
parents.
So a model project has standard jar plugins and very basic metrics and checks
as its mostly just basic beans where as a service project would need to pass
at least an 80/60 cobertura report for units tests.
The groupId for me is related to the position in the source control hierarchy
and maven reposititory but nothing else really.
My biggest issue at the moment, although I have not tried to solve it is that
I want the reactor to generate my docs and NOT use inheritance in any way for
it just aggregation. I'm hoping thats what dashboard is for but time has not
permitted research. I think I might need to figure out how to package up and
deploy the xml report outputs so that any site aggregator can accumulate the
site for a deliverable. As the site docs generally should accompany a
released deliverable not the overall source tree, that always seemed
backwards to me.
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Maven and organization of source tree in SCM toolset
Posted by "Bracewell, Robert" <rb...@qualcomm.com>.
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:gholam@apache.org]
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:gholam@apache.org
---------------------------------------------------------------------
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
Re: Maven and organization of source tree in SCM toolset
Posted by Michael McCallum <gh...@apache.org>.
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:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org