[ 
http://jira.codehaus.org/browse/CONTINUUM-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brett Porter updated CONTINUUM-1657:
------------------------------------

    Fix Version/s: 1.x

> Split configuration of pom location, when adding new M2 projects, into two 
> parts; optionally specify a workspace into which a (modular-)project should 
> be checked-out.
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CONTINUUM-1657
>                 URL: http://jira.codehaus.org/browse/CONTINUUM-1657
>             Project: Continuum
>          Issue Type: Improvement
>          Components: Core system, SCM, Web - Configuration
>    Affects Versions: 1.1
>         Environment: Windows XP Prof
> Tomcat 5.5.x
> Continuum 1.1-SNAPSHOT
>            Reporter: Darren Bishop
>             Fix For: 1.x
>
>
> Split configuration of the {{pom.xml}} location, when adding new M2 projects. 
> Currently, projects are checked-out from SCM at the directory containing the 
> {{pom.xml}}, which is not always what one wants.
> Also, optionally specify a workspace into which a (modular-)project should be 
> checked-out. Currently, projects are checked-out from SCM into a directory 
> named by that particular build number.
> The following pathology exists when trying to implement CI with flat-modular 
> projects:
> {panel}
> {noformat:title=Project Layout (in SCM/SVN)}
> modproj/
>     |-- trunk/ (part of subversion versioning tree)
>         |-- module-1/
>             |-- pom.xml
>         |-- module-2/
>             |-- pom.xml
>         |-- module-3/
>             |-- pom.xml
>         |-- reactor/
>             |-- pom.xml (this is the parent pom i.e. it contains the list of 
> modules; see next)
> {noformat}
> And the reactor in {{../trunk/reactor/pom.xml}}
> {code:xml|title=The 'Reactor'} 
> <modules>
>     <module>../module-1</module>
>     <module>../module-2</module>
>     <module>../module-3</module>
> </modules>
> {code} 
> Let's assume the Continuum working directory is {{$CONTEXT_WEB_INF/builds}}.
> Let's also assume because we are adding a new project that the build number 
> will be *1*.
> To add a M2 modular/reactor-project, one specifies the SCM URL to the reator 
> {{pom.xml}} e.g. in the case above, something like 
> {{scm:svn:http:/svn/modproj/trunk/reactor/pom.xml}}.
> When the first build is triggered, it checks out 
> {{http:/svn/modproj/trunk/reactor}} into {{$CONTEXT_WEB_INF/builds/1}}.
> Maven will try to resolve the location of the modules, traversing up a 
> directory into {{builds}} and then trying to traverse down into, let's say, 
> {{module-1}} - but a directory of that name does not exist.. Furthermore, 
> {{module-{1,2,3}}} have not even been checked-out.
> And so the build fails.
> {panel}
> What I propose is to add an additional configuration step (hence improvement, 
> not new feature) to the new M2 project page,:
>  * Split the {{POM Url}} field into two:
>  ** The first field specifies the _project_ root i.e. not the project's 
> {{pom.xml}}. For the scenario above one would enter 
> {{scm:svn:http:/svn/modproj/trunk}}
>  ** The new second field specifies the location of the project's {{pom.xml}} 
> relative to the root of the check-out. For example  {{reactor/pom.xml}}
>  *** A sensible default would be just {{pom.xml}} i.e. making the assumption 
> that the file is in the root of the check-out.
> With this approach, Continuum has atleast the same information as the current 
> approach (for backwards compatibility) but also has the intention of the 
> developer/administrator w.r.t. the layout of the project.
> Optionally, a third field can be added that lets you specify a workspace for 
> your project's individual builds and that Continuum checks out into. For the 
> scenario above, if this workspace was {{modproj}} (...hint hint), then 
> Continuum would check-out into {{1/modproj/}} all the modules including 
> {{reactor}}.
> This has better fidelity to what a developer does on their workstation, 
> especially us Eclipse users.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to