On 19/10/2010 11:30 AM, Nicola Musatti wrote:
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.
This is almost exactly the way we have our projects setup. Works very
well and makes it easy to get releases done.
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.
Exactly.
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<[email protected]>
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
