Things are not always so clear cut. For instance, we are developing the
first release of an application which is composed of many projects. They
are all versioned separately, so as to be ready when we'll have to start
shipping updates as opposed to full releases, not to mention that
different customers are likely to require customizations to different
sub-projects.
Still at this point most things are being developed at the same time and
using a global aggregating project is convenient for different reasons.
One is being able to use the same setup within our IDE of choice as we
use for offline building. With Eclipse, Subversive and m2eclipse
projects are automatically setup as externals when they are checked out
in the top level project's directory. This only has to be done once;
afterwards every developer can just checkout the top level project and
materialize its modules and have the whole development environment
correctly setup. This approach also makes it very simple to setup
automated builds with Hudson.
Furthermore, Maven has one advantage over other build systems in
allowing aggregation to be a casual relationship among projects. For
instance in our setup experienced developers may decide to have a
private aggregating project where they only include those modules they
are actually working on and rely on Maven to retrieve the rest from our
Nexus instance.
The only serious drawback is the fact that the Maven release plugin does
not currently handle this setup.
One piece of advice for the OP: Don't confuse inheritance with
aggregation! Use one POM project to aggregate your sub-projects and
another one to hold common configuration. The latter may well be a
module of the former.
Cheers,
Nicola Musatti
Paul Benedict wrote:
If you have "trunks" underneath subprojects, that tells me they have
independent release cycles. If you want them to be versioned
separately, your structure is okay. If you want the master project to
build and control the subprojects as modules, I would re-organize
everything under one trunk.
Paul
On Tue, Oct 19, 2010 at 9:40 AM, thisguy<bobsmith30...@yahoo.com> wrote:
Hello experts, I'm trying to reconcile the standard maven project structure
with the standard svn project structure (with per-project versioning). I'd
like to have a subversion structure like this:
pom.xml
--proj A
----trunk
------pom.xml
------src
--proj B
----trunk
------pom.xml
------src
etc.
How can I get maven to build everything properly?
Should I use svn externals to magically remove the trunk directories so that
this layout would conform to standard maven layout? If I did that, how
would I handle the situation of wanting to build a particular
branch..wouldn't I have to update the externals properties back and forth
(cumbersome)?
Or should I change all project poms to use parent relative paths of
"../../pom.xml" to get to the parent pom? But this technique wouldn't work
if I wanted to build a particular branch because it would be an extra level
deep (i.e. proj->branches->1.0.0->pom.xml).
What is best practice here? Thank you.
--
View this message in context:
http://maven.40175.n5.nabble.com/project-structure-with-per-project-trunks-and-svn-tp3219163p3219163.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Chi riceve il presente messaggio e' tenuto a verificare se lo stesso non gli
sia pervenuto per errore. In tal caso e' pregato di avvisare immediatamente
il mittente e, tenuto conto delle responsabilita' connesse all'indebito
utilizzo e/o divulgazione del messaggio e/o delle informazioni in esso
contenute, voglia cancellare l'originale e distruggere le varie copie o
stampe.
The receiver of this message is required to check if he/she has received it
erroneously. If so, the receiver is requested to immediately inform the
sender and - in consideration of the responsibilities arising from undue use
and/or disclosure of the message and/or the information contained therein -
destroy the original message and any copy or printout thereof.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
