You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by thisguy <bo...@yahoo.com> on 2010/10/19 16:40:01 UTC

project structure with per-project trunks and svn

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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


RE: project structure with per-project trunks and svn

Posted by "Yanko, Curtis" <cu...@uhc.com>.
 If the parent is deployed internally then you don't need to worry about
the structure.

Alternatively, if you are using a Build Management s Server like AHP or
Hudson, tey can alter the layout on-the-fly at checkout/update time.


________________________________

Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time

-----Original Message-----
From: thisguy [mailto:bobsmith30332@yahoo.com] 
Sent: Tuesday, October 19, 2010 10:40 AM
To: users@maven.apache.org
Subject: project structure with per-project trunks and svn


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-trun
ks-and-svn-tp3219163p3219163.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: project structure with per-project trunks and svn

Posted by Paul Benedict <pb...@apache.org>.
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 <bo...@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-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: project structure with per-project trunks and svn

Posted by Ron Wheeler <rw...@artifact-software.com>.
  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<bo...@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-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
>>
>>
>
>
> 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-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: project structure with per-project trunks and svn

Posted by Nicola Musatti <Ni...@ObjectWay.it>.
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<bo...@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-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
>
>
>    


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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org