It's better to keep modules in continuum for build order resolution.

Later, we'll add the possibility to add new dependencies on projects, so 
modules will can be removed.

Emmanuel

Shaun Barriball a écrit :
Hi Emmanual et al,
After a few hours migrating our 15 plus projects to Continuum 1.1 we now
have everything up and running. I've been impressed with 1.1 (great work).

2 issues thus far:

Issue 1 - Do we delete Project sub-modules?
--------------------------------------------
Consider the scenario:

Project Group "MyBigProject" Project A
                pom.xml
                Module 1
                        pom.xml
                
                Module 2
                        pom.xml
                        
        Project B
                ...
        Project C

 * in Continuum 1.0.3 if you had a project of the above format when adding
each Maven 2 project you would have to delete "Module 1" and "Module 2" to
leave a single "Project A". You then delete the "-no-recurse" option on the
Maven build line so it builds the whole project.

In Continuum 1.1 it uses the dependencies to determine the build order.
Given that the root pom of each projects do not have any of their 'own'
dependencies (they just define dependencies used by sub-modules) should we
still be deleting "Module 1", "Module 2" etc?
Issue 2 - Performance
----------------------
Out of the box Continuum 1.1 appears much, much slower than 1.0.3. For
example, it takes 30 secs+ after I click "MyBigProject" to display the
contents of the Project Group which has 10 Projects.

Are there any logging settings/go faster buttons that would help improve
performance?

Regards,
Shaun.







-----Original Message-----
From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] Sent: 21 May 2007 18:00
To: [email protected]
Subject: Re: Project build order for multiple Maven 2 projects -
Alphabetical by Project Name?

You must readd all projects

Emmanuel

Shaun Barriball a écrit :
We're just trying the upgrade to 1.1 now from 1.0.3.
Is there an upgrade path for this which preserves the database or do we have to re-install all projects from scratch? 1.1 isn't mentioned on http://maven.apache.org/continuum/upgrade.html.

Regards,
Shaun.
-----Original Message-----
From: Jeffery, Mark [mailto:[EMAIL PROTECTED]
Sent: 21 May 2007 11:38
To: [email protected]
Subject: RE: Project build order for multiple Maven 2 projects - Alphabetical by Project Name?

Yeah.....I am battling with the same thing

http://jira.codehaus.org/browse/CONTINUUM-998


Should be fixed in 1.1-alpha-#

Jeff

-----Original Message-----
From: Shaun Barriball [mailto:[EMAIL PROTECTED]
Sent: 21 May 2007 11:41
To: [email protected]
Subject: Project build order for multiple Maven 2 projects - Alphabetical by Project Name?

Hi all,
We've been using Continuum (1.0.3) successfully as part of our automated build and deploy for 6 months or so.
We have one big issue which I'd appreciate input on.

We have a large software system with 15 or so separate Maven 2 projects (assume for simplicity Project A, Project B and Project C) which each have sub-modules. Assume the dependency tree is: A -> depends on C -> depends on B (for example). These dependencies are expressed using Maven 2 dependency hierarchy.

The "Build All" function on Continuum appears to ignore any Maven 2 dependency hierarchy and simply builds them in alphabetical order of the Project Name. This therefore builds the above example out of order - often resulting in build failures.

* Should continuum 'understand' the dependency tree? I've read some material which implies this should potentially be the case (http://jira.codehaus.org/browse/CONTINUUM-39).

* If not, is there a way to organise the build order for "Build All"
above
and beyond altering the project names with "1.", "2." etc (which is obviously undesirable)?


All help appreciated.
Regards,
Shaun.


To read FirstRand Bank's Disclaimer for this email click on the following address or copy into your Internet browser:
https://www.fnb.co.za/disclaimer.html

If you are unable to access the Disclaimer, send a blank e-mail to [EMAIL PROTECTED] and we will send you a copy of the Disclaimer.









Reply via email to