continuum-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Darren Bishop (JIRA)" <j...@codehaus.org>
Subject [jira] Created: (CONTINUUM-1657) 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.
Date Wed, 13 Feb 2008 11:21:31 GMT
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


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

        

Mime
View raw message