Re: When builds are done in multi-module projects ?

2007-10-19 Thread Emmanuel Venisse



Alex Tanaev a écrit :

I have a different problem (continuum 1.0.3):

Changes in a project trigger its rebuild, but then another project that
depends on the first one is NOT rebuilt.


dependant projects are rebuilt in Continuum 1.1 not in 1.0.3

Emmanuel


Why is that?

Alex


Emmanuel Venisse wrote:

Continuum look at scm changes, if it contains some sources updates, it
build the project.
Then, it looks at dependencies list, if a dependency (that is a continuum
project too) is updated (new build result in success), continuum build the
project

With no SCM changes and no dependencies, if the build definition is marked
as "always build" and the build isn't forced, continuum won't build the
project.

Emmanuel







Re: When builds are done in multi-module projects ?

2007-10-19 Thread Alex Tanaev

I have a different problem (continuum 1.0.3):

Changes in a project trigger its rebuild, but then another project that
depends on the first one is NOT rebuilt.

Why is that?

Alex


Emmanuel Venisse wrote:
> 
> Continuum look at scm changes, if it contains some sources updates, it
> build the project.
> Then, it looks at dependencies list, if a dependency (that is a continuum
> project too) is updated (new build result in success), continuum build the
> project
> 
> With no SCM changes and no dependencies, if the build definition is marked
> as "always build" and the build isn't forced, continuum won't build the
> project.
> 
> Emmanuel
> 

-- 
View this message in context: 
http://www.nabble.com/When-builds-are-done-in-multi-module-projects---tf4508232.html#a13293989
Sent from the Continuum - Users mailing list archive at Nabble.com.



Re: When builds are done in multi-module projects ?

2007-10-02 Thread Emmanuel Venisse



Damien Lecan a écrit :

Can you look at logs the "enqueuing" lines to see if projects are in the right 
order?


It seems.
They are always in the same order for each build definition
executions, but not exactly as the same as it is this displayed by
Reactor when builing from parent pom.
Subprojects with "pom" packaging are build earlier by Continuum than
by Reactor, but nothing depends on them.


Do you have scm changes between each build?


Of course not, otherwise the number of builds on the second continuum
instance would have been greater than 1.

The 2 configurations were running together last night.


I'll try to reproduce it.


After few try, I can't reproduce your issue. I have always the same number (1) 
of build result on each project



Are you working on a fast machine ? Because my server is slow, maybe
some processes begin before the end of other processes.


Yes, it's a fast machine.



Eg :

...
[defaultScheduler_Worker-13] INFO  Continuum:default  - Enqueuing 'RUS
Server Project' (Build definition id=4).
[defaultScheduler_Worker-13] INFO  Continuum:default  - Enqueuing 'RUS
commons' (Build definition id=4).
[defaultScheduler_Worker-13] INFO  Continuum:default  - Enqueuing
'Domain Parent' (Build definition id=4).
[defaultScheduler_Worker-13] INFO  Continuum:default  - Enqueuing
'Persistance Parent' (Build definition id=4).
[pool-1-thread-1] INFO  buildcontroller.BuildController:default  -
Initializing build
[defaultScheduler_Worker-13] INFO  Continuum:default  - Enqueuing
'Persistance Data' (Build definition id=4).
[defaultScheduler_Worker-13] INFO  Continuum:default  - Enqueuing
'Persistance API' (Build definition id=4).
[defaultScheduler_Worker-13] INFO  Continuum:default  - Enqueuing
'Domain API' (Build definition id=4).
[defaultScheduler_Worker-13] INFO  Continuum:default  - Enqueuing
'Persistance Mock' (Build definition id=4).
[pool-1-thread-1] INFO  BuildController:default  - Starting build of
RUS Server Project
[defaultScheduler_Worker-13] INFO  Continuum:default  - Enqueuing
'Domain Test Framework' (Build definition id).
... enqueuing continues by 16 modules more

As we can see, build begins before the end enqueuing.
I don't know if it is normal or not.


Yes, it can be normal and it isn't a problem. When the task manager have 
something in the queue, it start the process.

Emmanuel



Re: When builds are done in multi-module projects ?

2007-09-28 Thread Damien Lecan
> Can you look at logs the "enqueuing" lines to see if projects are in the 
> right order?

It seems.
They are always in the same order for each build definition
executions, but not exactly as the same as it is this displayed by
Reactor when builing from parent pom.
Subprojects with "pom" packaging are build earlier by Continuum than
by Reactor, but nothing depends on them.

> Do you have scm changes between each build?

Of course not, otherwise the number of builds on the second continuum
instance would have been greater than 1.

The 2 configurations were running together last night.

> I'll try to reproduce it.

Are you working on a fast machine ? Because my server is slow, maybe
some processes begin before the end of other processes.

Eg :

...
[defaultScheduler_Worker-13] INFO  Continuum:default  - Enqueuing 'RUS
Server Project' (Build definition id=4).
[defaultScheduler_Worker-13] INFO  Continuum:default  - Enqueuing 'RUS
commons' (Build definition id=4).
[defaultScheduler_Worker-13] INFO  Continuum:default  - Enqueuing
'Domain Parent' (Build definition id=4).
[defaultScheduler_Worker-13] INFO  Continuum:default  - Enqueuing
'Persistance Parent' (Build definition id=4).
[pool-1-thread-1] INFO  buildcontroller.BuildController:default  -
Initializing build
[defaultScheduler_Worker-13] INFO  Continuum:default  - Enqueuing
'Persistance Data' (Build definition id=4).
[defaultScheduler_Worker-13] INFO  Continuum:default  - Enqueuing
'Persistance API' (Build definition id=4).
[defaultScheduler_Worker-13] INFO  Continuum:default  - Enqueuing
'Domain API' (Build definition id=4).
[defaultScheduler_Worker-13] INFO  Continuum:default  - Enqueuing
'Persistance Mock' (Build definition id=4).
[pool-1-thread-1] INFO  BuildController:default  - Starting build of
RUS Server Project
[defaultScheduler_Worker-13] INFO  Continuum:default  - Enqueuing
'Domain Test Framework' (Build definition id).
... enqueuing continues by 16 modules more

As we can see, build begins before the end enqueuing.
I don't know if it is normal or not.

Damien Lecan


Re: When builds are done in multi-module projects ?

2007-09-28 Thread Emmanuel Venisse

I'll try to reproduce it.

Can you look at logs the "enqueuing" lines to see if projects are in the right 
order?

Do you have scm changes between each build?

Emmanuel

Damien Lecan a écrit :

It isn't recommended to have the same source tree twice in continuum if pom 
files have the same version.
With this configuration, continuum can't resolve correctly the build order so a 
project B that must be built after an other project A is built before, then 
when A is built, Continuum detect a change
on it and build B


I set up another Continuum instance last night.
I reset both installations : fresh database, fresh project checkouts

I used exactly same configuration described before, but each project
copy was checked out on its own continuum instance.
I reduced time between to executions from 1h to 30min to have enough
results for this morning

Here are test results after 11h of tests

 GP1GP2
build status   all success  all success
nb of BD exec 2222
number of builds   2 to 18 1


Will you consider these tests results ? Or something else is wrong ?

 => 1 build definition : projects are built once, the first time
 => 2 build definitions : projects are built many times more

I used to use several build definitions with Continuum 1.0.3 for the
same project and it used to work fine.

Damien






Re: When builds are done in multi-module projects ?

2007-09-28 Thread Damien Lecan
> It isn't recommended to have the same source tree twice in continuum if pom 
> files have the same version.
> With this configuration, continuum can't resolve correctly the build order so 
> a project B that must be built after an other project A is built before, then 
> when A is built, Continuum detect a change
> on it and build B

I set up another Continuum instance last night.
I reset both installations : fresh database, fresh project checkouts

I used exactly same configuration described before, but each project
copy was checked out on its own continuum instance.
I reduced time between to executions from 1h to 30min to have enough
results for this morning

Here are test results after 11h of tests

 GP1GP2
build status   all success  all success
nb of BD exec 2222
number of builds   2 to 18 1


Will you consider these tests results ? Or something else is wrong ?

 => 1 build definition : projects are built once, the first time
 => 2 build definitions : projects are built many times more

I used to use several build definitions with Continuum 1.0.3 for the
same project and it used to work fine.

Damien


Re: When builds are done in multi-module projects ?

2007-09-27 Thread Emmanuel Venisse

It isn't recommended to have the same source tree twice in continuum if pom 
files have the same version.
With this configuration, continuum can't resolve correctly the build order so a project B that must be built after an other project A is built before, then when A is built, Continuum detect a change 
on it and build B


Emmanuel

Damien Lecan a écrit :

I will reinit all my Continuum instance (fresh database, fresh
checkout), activate scm debug and see what happen later.

I will plan 2 build definitions :
 1. run clean deploy every even hours
 2. run clean deploy site-deploy every odd hours


Ok, here are the results.
I ran concurrently another checkout of my project, but this one built
by only one build definition.

To summarize :

Group Project 1
 1. every even hours : clean deploy
 2. every odd hours : clean deploy site-deploy

Group Project 2 (same project as above = same sources)
 1. every hours : clean deploy site-deploy

After 21 hours, results :

  GP1GP2
build status  all success  all success
nb of BD exec   21*  21
number of build   2->18**1

* : BP1 for GP1 was executed 11 times when BP2 was executed 10 times
(=21 executions)

** : the 25 modules of my project where not built all together for each build.
Parent project was built twice, when the final module (depends on each
other modules) was built 18 times. All other modules ware built
between 3 and 17 times, depending on their dependency configurations.

What can be deducted from theses tests ?
 - Several build definitions for the same project group produces
unnecessary builds, without any source modification

 => Maybe build execution doesn't check previous executions of all
other build definitions for the same project group

What do you think ?

Thanks

Damien Lecan






Re: When builds are done in multi-module projects ?

2007-09-27 Thread Damien Lecan
> I will reinit all my Continuum instance (fresh database, fresh
> checkout), activate scm debug and see what happen later.
>
> I will plan 2 build definitions :
>  1. run clean deploy every even hours
>  2. run clean deploy site-deploy every odd hours

Ok, here are the results.
I ran concurrently another checkout of my project, but this one built
by only one build definition.

To summarize :

Group Project 1
 1. every even hours : clean deploy
 2. every odd hours : clean deploy site-deploy

Group Project 2 (same project as above = same sources)
 1. every hours : clean deploy site-deploy

After 21 hours, results :

  GP1GP2
build status  all success  all success
nb of BD exec   21*  21
number of build   2->18**1

* : BP1 for GP1 was executed 11 times when BP2 was executed 10 times
(=21 executions)

** : the 25 modules of my project where not built all together for each build.
Parent project was built twice, when the final module (depends on each
other modules) was built 18 times. All other modules ware built
between 3 and 17 times, depending on their dependency configurations.

What can be deducted from theses tests ?
 - Several build definitions for the same project group produces
unnecessary builds, without any source modification

 => Maybe build execution doesn't check previous executions of all
other build definitions for the same project group

What do you think ?

Thanks

Damien Lecan


Re: When builds are done in multi-module projects ?

2007-09-26 Thread Damien Lecan
> > Strange empty line after update
>
> the cvs provider doesn't analyze lines with less than 3 characters.
>
> when you run cvs with the continuum user, what is the output language? 
> english, french...

[EMAIL PROTECTED] 1]$ cvs --help
Usage: cvs [cvs-options] command [command-options-and-arguments]
  where cvs-options are -q, -n, etc.

tomcat is system account which launches Tomcat app server.

I will reinit all my Continuum instance (fresh database, fresh
checkout), activate scm debug and see what happen later.

I will plan 2 build definitions :
 1. run clean deploy every even hours
 2. run clean deploy site-deploy every odd hours

Damien


Re: When builds are done in multi-module projects ?

2007-09-25 Thread Damien Lecan
> Can you send your logs when a projects is building without changes in SCM and 
> dependencies (scheduled mode)?

Here are logs filtered by thread "pool-1-thread-1".

2007-09-22 13:00:00,648 [pool-1-thread-1] INFO
BuildController:default- Initializing build
2007-09-22 13:00:00,673 [pool-1-thread-1] INFO
BuildController:default- Starting build of RUS Server Parent
Project
2007-09-22 13:00:01,176 [pool-1-thread-1] INFO
BuildController:default- Updating working dir
2007-09-22 13:00:01,176 [pool-1-thread-1] INFO
BuildController:default- Performing action
check-working-directory
2007-09-22 13:00:01,201 [pool-1-thread-1] INFO
BuildController:default- Performing action
update-working-directory-from-scm
2007-09-22 13:00:01,710 [pool-1-thread-1] INFO  ContinuumScm:default
- Updating project: id: '71', name 'RUS Server Parent
Project'.
2007-09-22 13:00:01,743 [pool-1-thread-1] INFO  ScmManager:default
- Executing: /bin/sh -c "cd
/home/tomcat/continuum/working-directory/71 && cvs
 -z3 -f -q update -d"
2007-09-22 13:00:01,743 [pool-1-thread-1] INFO  ScmManager:default
- Working directory:
/home/tomcat/continuum/working-directory/71
2007-09-22 13:00:20,477 [pool-1-thread-1] INFO
BuildController:default- Merging SCM results
2007-09-22 13:00:20,477 [pool-1-thread-1] INFO
BuildController:default- Changes found, building
2007-09-22 13:00:20,477 [pool-1-thread-1] INFO
BuildController:default- Performing action
update-project-from-working-directory
2007-09-22 13:00:20,512 [pool-1-thread-1] INFO
Action:update-project-from-working-directory - Updating project 'RUS
Server Parent Project' from checkout.
2007-09-22 13:00:21,417 [pool-1-thread-1] INFO
BuildController:default- Performing action execute-builder
2007-09-22 13:00:21,996 [pool-1-thread-1] WARN
ContinuumBuildExecutor:maven2  - Could not find the executable 'mvn'
in this path:
2007-09-22 13:00:22,041 [pool-1-thread-1] INFO
ShellCommandHelper:default - Executing: /bin/sh -c 'cd
/home/tomcat/continuum/working-directory/71 && mvn
 --batch-mode --non-recursive -Dcontinuum.project.lastBuild.state=2
-Dcontinuum.project.nextBuild.number=6
"-Dcontinuum.project.group.name=RUS Server Parent
Project" -Dcontinuum.project.lastBuild.number=5 clean deploy'
2007-09-22 13:00:22,042 [pool-1-thread-1] INFO
ShellCommandHelper:default - Working directory:
/home/tomcat/continuum/working-directory/71
2007-09-22 13:00:53,989 [pool-1-thread-1] INFO
ContinuumBuildExecutor:maven2  - Exit code: 0
2007-09-22 13:00:55,680 [pool-1-thread-1] INFO
BuildController:default- Performing action deploy-artifact
2007-09-22 13:00:56,222 [pool-1-thread-1] INFO  Notifier:mail
- Same state, not sending message.
2007-09-22 13:00:56,260 [pool-1-thread-1] INFO  Notifier:mail
- Same state, not sending message.

We can see that changes seem to be detected, but that's wrong, nothing
has been commited at all since previous build of this module.


Corresponding build result :

Start Time:  sept. 22, 2007 01:00:21 PM CEST
End Time:   sept. 22, 2007 01:00:53 PM CEST
Duration:   32 sec
Build Trigger:  Scheduled

SCM Changes : No SCM changes   <-- contradiction with log trace
Dependencies Changes : No dependencies changes

Build Definition Used
POM filename : pom.xml
Goals : clean deploy
Arguments : --batch-mode --non-recursive
Build Fresh : false
Always Build : false
Is it default ? true
Schedule : Midi


Do you need extra information ?

Damien Lecan


Re: When builds are done in multi-module projects ?

2007-09-24 Thread Damien Lecan
2007/9/24, Emmanuel Venisse <[EMAIL PROTECTED]>:
> Continuum look at scm changes, if it contains some sources updates, it build 
> the project.
> Then, it looks at dependencies list, if a dependency (that is a continuum 
> project too) is updated (new build result in success), continuum build the 
> project
> With no SCM changes and no dependencies, if the build definition is marked as 
> "always build" and the build isn't forced, continuum won't build the project.

For theses projects, always build is set to false :(
Copy/paste for project build summary :

SCM Changes : No SCM changes
Dependencies Changes : No dependencies changes

Build Definition Used
POM filename : pom.xml
Goals : clean deploy
Arguments : --batch-mode --non-recursive
Build Fresh : false
Always Build : false
Is it default ? : true
Schedule : Midi

And this project was built this noon !

Damien


Re: When builds are done in multi-module projects ?

2007-09-24 Thread Damien Lecan
Hum, I'm working with Continuum 1.1-beta-3

Damien

2007/9/24, Damien Lecan <[EMAIL PROTECTED]>:
> Hello,
>
> I would like to understand how Continuum knows which sub-projects of a
> multi-module project have to be built.
>
> All sub-projects are in eparate projects under a main project group.
>
> it seems that build of a project is done when :
>  - sources are updated
>  - dependency projects have been "updated" (= built or sources updated ?)
>  - ...
>
> I would like to know all the rules in order to understand why some
> projects are built whereas I can read for theses projects :
>
> SCM Changes : No SCM changes
> Dependencies Changes : No dependencies changes
>
> Thanks
>
> Damien Lecan
>