You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@buildr.apache.org by Jean-Philippe Caruana <je...@orange-ftgroup.com> on 2010/03/23 15:25:18 UTC

always running test for other project

Hi,

I don't understand how buildr works - I thought i did though.
I have a project made of several subprojects with dependencies between 
each other.

/myProject (that's where my buildfile is)
/---/commons-util
/---/commons-test
/---/artifactToBuild

so my build file looks like something like this :
---------------------------------------------------------------------
define 'myProject' do

   compile.using :target=>'1.5', :other=>['-encoding', 'ISO8859_1'] 
:debug=>true

   desc 'utils for easy testing in the project'
   define 'commons-test' do
     compile.with COMMONS_TEST_DEPENDENCIES
     test.resources
     package :jar
   end

   desc 'utils for the whole project'
   define 'commons-util' do
     compile.with COMMONS_UTIL_DEPENDENCIES
     test.with project('commons-test'), JUNIT_3, MOCKRUNNER, DB_UNIT
     package :jar
   end

   desc 'i want to build it as fast as possible'
     define 'artifactToBuild' do
       compile.with project('commons-util'), 
ARTIFACT_TO_BUILD_UTIL_DEPENDENCIES, COMMONS_UTIL_DEPENDENCIES
       test.with project('commons-test'), JUNIT_3, DB_UNIT
       test.exclude 'Abstract*'
       package :jar
     end
end
---------------------------------------------------------------------

every time i launch "buildr package" in artifactToBuild or "buildr 
test", it launches all the tests in commons-test and commons-util even 
if nothing changed in this projects. These can be pretty long. How can I 
do to change this behaviour ?

(Buildr 1.3.5 )

Thanks

-- Jean-Philippe Caruana
********************************
Ce message et toutes les pieces jointes (ci-apres le "message") sont
confidentiels et etablis a l'attention exclusive de ses destinataires.
Toute utilisation ou diffusion non autorisee est interdite.
Tout message electronique est susceptible d'alteration. CVF decline
toute responsabilite au titre de ce message s'il a ete altere, deforme
ou falsifie.
Si vous n'etes pas destinataire de ce message, merci de le detruire
immediatement et d'avertir l'expediteur.
*********************************
This message and any attachments (the "message") are confidential and
intended solely for the addressees. Any unauthorised use or
dissemination is prohibited.
Messages are susceptible to alteration. CVF shall not be liable for the
message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it
immediately and inform the sender..
********************************

Re: always running test for other project

Posted by Rhett Sutphin <rh...@detailedbalance.net>.
Hi Jean-Phillipe,

On Mar 25, 2010, at 8:40 AM, Jean-Philippe Caruana wrote:

> Le 23/03/2010 23:22, Antoine Toulme a écrit :
>> Sorry for sending the wrong message then.
>>
>> Jen-Philippe, if you can reproduce the problem in an environment on  
>> which we
>> can work (or even better write a spec), I'd be happy to fix the  
>> problem.
>
> I tried to reproduce it in a new project "from scratch", but it  
> worked as expected (no test rerun if all were succesful).
>
> On my project, I detected 2 flaws : one circular dependency (I  
> killed it) and one dirty hack (I desactivated the test involed in  
> that). But still, it launches all tests. I don't know how to isolate  
> my problem, but I'm still working on it.

Something to check is whether a particular module is continuously re- 
compiling anything in addition to continuously retesting.  I had a  
problem like yours once.  The cause turned out to be that the java  
source directory structure did not match the package directories[1]  
which were created by javac, so buildr couldn't tell that the source  
files had up-to-date corresponding binaries.

Rhett

[1]:  The package in question was named something like  
foo.bar.quux.tools.  The (incorrect) source directory structure was  
src/main/java/foo/bar.quux/tools.  javac (correctly) compiled into  
target/classes/foo/bar/quux/tools.

>
>
> -- Jean-Philippe Caruana


Re: always running test for other project

Posted by Jean-Philippe Caruana <je...@orange-ftgroup.com>.
Le 23/03/2010 23:22, Antoine Toulme a écrit :
> Sorry for sending the wrong message then.
>
> Jen-Philippe, if you can reproduce the problem in an environment on which we
> can work (or even better write a spec), I'd be happy to fix the problem.

I tried to reproduce it in a new project "from scratch", but it worked 
as expected (no test rerun if all were succesful).

On my project, I detected 2 flaws : one circular dependency (I killed 
it) and one dirty hack (I desactivated the test involed in that). But 
still, it launches all tests. I don't know how to isolate my problem, 
but I'm still working on it.


-- Jean-Philippe Caruana
********************************
Ce message et toutes les pieces jointes (ci-apres le "message") sont
confidentiels et etablis a l'attention exclusive de ses destinataires.
Toute utilisation ou diffusion non autorisee est interdite.
Tout message electronique est susceptible d'alteration. Multimedia Business Services decline
toute responsabilite au titre de ce message s'il a ete altere, deforme
ou falsifie.
Si vous n'etes pas destinataire de ce message, merci de le detruire
immediatement et d'avertir l'expediteur.
*********************************
This message and any attachments (the "message") are confidential and
intended solely for the addressees. Any unauthorised use or
dissemination is prohibited.
Messages are susceptible to alteration. Multimedia Business Services shall not be liable for the
message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it
immediately and inform the sender..
********************************

Re: always running test for other project

Posted by Jean-Philippe Caruana <je...@orange-ftgroup.com>.
Le 23/03/2010 23:22, Antoine Toulme a écrit :
> Sorry for sending the wrong message then.

No problem : I wasn't clear enough.

> Jen-Philippe, if you can reproduce the problem in an environment on which we
> can work (or even better write a spec), I'd be happy to fix the problem.

I'll try to reproduce with a "from scratch" project, (maybe later today) 
then I'll try to write a spec.

-- Jean-Philippe Caruana
********************************
Ce message et toutes les pieces jointes (ci-apres le "message") sont
confidentiels et etablis a l'attention exclusive de ses destinataires.
Toute utilisation ou diffusion non autorisee est interdite.
Tout message electronique est susceptible d'alteration. Multimedia Business Services decline
toute responsabilite au titre de ce message s'il a ete altere, deforme
ou falsifie.
Si vous n'etes pas destinataire de ce message, merci de le detruire
immediatement et d'avertir l'expediteur.
*********************************
This message and any attachments (the "message") are confidential and
intended solely for the addressees. Any unauthorised use or
dissemination is prohibited.
Messages are susceptible to alteration. Multimedia Business Services shall not be liable for the
message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it
immediately and inform the sender..
********************************

Re: always running test for other project

Posted by Antoine Toulme <an...@lunar-ocean.com>.
Sorry for sending the wrong message then.

Jen-Philippe, if you can reproduce the problem in an environment on which we
can work (or even better write a spec), I'd be happy to fix the problem.

Thanks,

Antoine

On Tue, Mar 23, 2010 at 11:31, lacton <la...@users.sourceforge.net> wrote:

> There's even a spec for this behavior. :-)
>
> <code>
>  describe 'when there was a successful test run already' do
>
>    it 'should not run tests if nothing changed' do
>      lambda { test_task.invoke }.should_not run_task('foo:test')
>    end
> </code>
>
> lacton
>
> On Tue, Mar 23, 2010 at 4:33 PM, Alex Boisvert <al...@gmail.com>
> wrote:
> > Just want to confirm what Rhett said, the tests shouldn't be run twice if
> > you run "buildr package" twice without changing anything.
> >
> > alex
> >
> >
> > On Tue, Mar 23, 2010 at 8:25 AM, Jean-Philippe Caruana <
> > jeanphilippe1.caruana@orange-ftgroup.com> wrote:
> >
> >> Le 23/03/2010 16:19, Rhett Sutphin a écrit :
> >>
> >>> Hi Jean-Phillipe,
> >>>
> >>
> >> Hi Rhett,
> >>
> >>  I don't understand how buildr works - I thought i did though.
> >>>> every time i launch "buildr package" in artifactToBuild or "buildr
> >>>> test", it launches all the tests in commons-test and commons-util even
> >>>> if nothing changed in this projects. These can be pretty long. How can
> >>>> I do to change this behaviour ?
> >>>>
> >>>
> >>> It does this if you just run `buildr package` twice, back-to-back, with
> >>> no changes to anything anywhere? That should not be.
> >>>
> >>
> >> that's what I thought too and that's my question.
> >>
> >>
> >>  If you run with
> >>> --trace, buildr will show you (in great detail) which tasks it is
> >>> deciding to run and why. Try that and see what you find.
> >>> Dependency issues like this can sometimes be hard to track down. I'd
> >>> suggest starting with commons-test and seeing if you can get `buildr
> >>> package` to work properly, then move to the next project in the chain,
> >>> etc.
> >>>
> >>
> >> okay, it was my next step, but I was a little lazy since '--trace' is
> >> really verbose. I will try to find out something in there.
> >>
> >>
> >> ps : sorry for the end of mail crap in french/english : it's
> automatically
> >> added by my company's smtp server and I can't remove it.
> >>
> >>
> >> -- Jean-Philippe Caruana
>

Re: always running test for other project

Posted by lacton <la...@users.sourceforge.net>.
There's even a spec for this behavior. :-)

<code>
  describe 'when there was a successful test run already' do

    it 'should not run tests if nothing changed' do
      lambda { test_task.invoke }.should_not run_task('foo:test')
    end
</code>

lacton

On Tue, Mar 23, 2010 at 4:33 PM, Alex Boisvert <al...@gmail.com> wrote:
> Just want to confirm what Rhett said, the tests shouldn't be run twice if
> you run "buildr package" twice without changing anything.
>
> alex
>
>
> On Tue, Mar 23, 2010 at 8:25 AM, Jean-Philippe Caruana <
> jeanphilippe1.caruana@orange-ftgroup.com> wrote:
>
>> Le 23/03/2010 16:19, Rhett Sutphin a écrit :
>>
>>> Hi Jean-Phillipe,
>>>
>>
>> Hi Rhett,
>>
>>  I don't understand how buildr works - I thought i did though.
>>>> every time i launch "buildr package" in artifactToBuild or "buildr
>>>> test", it launches all the tests in commons-test and commons-util even
>>>> if nothing changed in this projects. These can be pretty long. How can
>>>> I do to change this behaviour ?
>>>>
>>>
>>> It does this if you just run `buildr package` twice, back-to-back, with
>>> no changes to anything anywhere? That should not be.
>>>
>>
>> that's what I thought too and that's my question.
>>
>>
>>  If you run with
>>> --trace, buildr will show you (in great detail) which tasks it is
>>> deciding to run and why. Try that and see what you find.
>>> Dependency issues like this can sometimes be hard to track down. I'd
>>> suggest starting with commons-test and seeing if you can get `buildr
>>> package` to work properly, then move to the next project in the chain,
>>> etc.
>>>
>>
>> okay, it was my next step, but I was a little lazy since '--trace' is
>> really verbose. I will try to find out something in there.
>>
>>
>> ps : sorry for the end of mail crap in french/english : it's automatically
>> added by my company's smtp server and I can't remove it.
>>
>>
>> -- Jean-Philippe Caruana

Re: always running test for other project

Posted by Alex Boisvert <al...@gmail.com>.
Just want to confirm what Rhett said, the tests shouldn't be run twice if
you run "buildr package" twice without changing anything.

alex


On Tue, Mar 23, 2010 at 8:25 AM, Jean-Philippe Caruana <
jeanphilippe1.caruana@orange-ftgroup.com> wrote:

> Le 23/03/2010 16:19, Rhett Sutphin a écrit :
>
>> Hi Jean-Phillipe,
>>
>
> Hi Rhett,
>
>  I don't understand how buildr works - I thought i did though.
>>> every time i launch "buildr package" in artifactToBuild or "buildr
>>> test", it launches all the tests in commons-test and commons-util even
>>> if nothing changed in this projects. These can be pretty long. How can
>>> I do to change this behaviour ?
>>>
>>
>> It does this if you just run `buildr package` twice, back-to-back, with
>> no changes to anything anywhere? That should not be.
>>
>
> that's what I thought too and that's my question.
>
>
>  If you run with
>> --trace, buildr will show you (in great detail) which tasks it is
>> deciding to run and why. Try that and see what you find.
>> Dependency issues like this can sometimes be hard to track down. I'd
>> suggest starting with commons-test and seeing if you can get `buildr
>> package` to work properly, then move to the next project in the chain,
>> etc.
>>
>
> okay, it was my next step, but I was a little lazy since '--trace' is
> really verbose. I will try to find out something in there.
>
>
> ps : sorry for the end of mail crap in french/english : it's automatically
> added by my company's smtp server and I can't remove it.
>
>
> -- Jean-Philippe Caruana
> ********************************
> Ce message et toutes les pieces jointes (ci-apres le "message") sont
> confidentiels et etablis a l'attention exclusive de ses destinataires.
> Toute utilisation ou diffusion non autorisee est interdite.
> Tout message electronique est susceptible d'alteration. CVF decline
> toute responsabilite au titre de ce message s'il a ete altere, deforme
> ou falsifie.
> Si vous n'etes pas destinataire de ce message, merci de le detruire
> immediatement et d'avertir l'expediteur.
> *********************************
> This message and any attachments (the "message") are confidential and
> intended solely for the addressees. Any unauthorised use or
> dissemination is prohibited.
> Messages are susceptible to alteration. CVF shall not be liable for the
> message if altered, changed or falsified.
> If you are not the intended addressee of this message, please cancel it
> immediately and inform the sender..
> ********************************
>

Re: always running test for other project

Posted by Jean-Philippe Caruana <je...@orange-ftgroup.com>.
Le 23/03/2010 16:19, Rhett Sutphin a écrit :
> Hi Jean-Phillipe,

Hi Rhett,

>> I don't understand how buildr works - I thought i did though.
>> every time i launch "buildr package" in artifactToBuild or "buildr
>> test", it launches all the tests in commons-test and commons-util even
>> if nothing changed in this projects. These can be pretty long. How can
>> I do to change this behaviour ?
>
> It does this if you just run `buildr package` twice, back-to-back, with
> no changes to anything anywhere? That should not be.

that's what I thought too and that's my question.

> If you run with
> --trace, buildr will show you (in great detail) which tasks it is
> deciding to run and why. Try that and see what you find.
> Dependency issues like this can sometimes be hard to track down. I'd
> suggest starting with commons-test and seeing if you can get `buildr
> package` to work properly, then move to the next project in the chain, etc.

okay, it was my next step, but I was a little lazy since '--trace' is 
really verbose. I will try to find out something in there.


ps : sorry for the end of mail crap in french/english : it's 
automatically added by my company's smtp server and I can't remove it.

-- Jean-Philippe Caruana
********************************
Ce message et toutes les pieces jointes (ci-apres le "message") sont
confidentiels et etablis a l'attention exclusive de ses destinataires.
Toute utilisation ou diffusion non autorisee est interdite.
Tout message electronique est susceptible d'alteration. CVF decline
toute responsabilite au titre de ce message s'il a ete altere, deforme
ou falsifie.
Si vous n'etes pas destinataire de ce message, merci de le detruire
immediatement et d'avertir l'expediteur.
*********************************
This message and any attachments (the "message") are confidential and
intended solely for the addressees. Any unauthorised use or
dissemination is prohibited.
Messages are susceptible to alteration. CVF shall not be liable for the
message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it
immediately and inform the sender..
********************************

Re: always running test for other project

Posted by Rhett Sutphin <rh...@detailedbalance.net>.
Hi Jean-Phillipe,

On Mar 23, 2010, at 9:25 AM, Jean-Philippe Caruana wrote:

> Hi,
>
> I don't understand how buildr works - I thought i did though.
> I have a project made of several subprojects with dependencies  
> between each other.
>
> /myProject (that's where my buildfile is)
> /---/commons-util
> /---/commons-test
> /---/artifactToBuild
>
> so my build file looks like something like this :
> ---------------------------------------------------------------------
> define 'myProject' do
>
>  compile.using :target=>'1.5', :other=>['-encoding',  
> 'ISO8859_1'] :debug=>true
>
>  desc 'utils for easy testing in the project'
>  define 'commons-test' do
>    compile.with COMMONS_TEST_DEPENDENCIES
>    test.resources
>    package :jar
>  end
>
>  desc 'utils for the whole project'
>  define 'commons-util' do
>    compile.with COMMONS_UTIL_DEPENDENCIES
>    test.with project('commons-test'), JUNIT_3, MOCKRUNNER, DB_UNIT
>    package :jar
>  end
>
>  desc 'i want to build it as fast as possible'
>    define 'artifactToBuild' do
>      compile.with project('commons-util'),  
> ARTIFACT_TO_BUILD_UTIL_DEPENDENCIES, COMMONS_UTIL_DEPENDENCIES
>      test.with project('commons-test'), JUNIT_3, DB_UNIT
>      test.exclude 'Abstract*'
>      package :jar
>    end
> end
> ---------------------------------------------------------------------
>
> every time i launch "buildr package" in artifactToBuild or "buildr  
> test", it launches all the tests in commons-test and commons-util  
> even if nothing changed in this projects. These can be pretty long.  
> How can I do to change this behaviour ?

It does this if you just run `buildr package` twice, back-to-back,  
with no changes to anything anywhere?  That should not be.  If you run  
with --trace, buildr will show you (in great detail) which tasks it is  
deciding to run and why.  Try that and see what you find.

Dependency issues like this can sometimes be hard to track down.  I'd  
suggest starting with commons-test and seeing if you can get `buildr  
package` to work properly, then move to the next project in the chain,  
etc.

Rhett

>
> (Buildr 1.3.5 )
>
> Thanks
>
> -- Jean-Philippe Caruana
> ********************************
> Ce message et toutes les pieces jointes (ci-apres le "message") sont
> confidentiels et etablis a l'attention exclusive de ses destinataires.
> Toute utilisation ou diffusion non autorisee est interdite.
> Tout message electronique est susceptible d'alteration. CVF decline
> toute responsabilite au titre de ce message s'il a ete altere, deforme
> ou falsifie.
> Si vous n'etes pas destinataire de ce message, merci de le detruire
> immediatement et d'avertir l'expediteur.
> *********************************
> This message and any attachments (the "message") are confidential and
> intended solely for the addressees. Any unauthorised use or
> dissemination is prohibited.
> Messages are susceptible to alteration. CVF shall not be liable for  
> the
> message if altered, changed or falsified.
> If you are not the intended addressee of this message, please cancel  
> it
> immediately and inform the sender..
> ********************************


Re: always running test for other project

Posted by Jean-Philippe Caruana <je...@orange-ftgroup.com>.
Le 23/03/2010 16:18, jeanphilippe1.caruana@orange-ftgroup.com a écrit :
> I want everything in the buildfile. -- ntu

I meant "but" instead of "ntu"
sorry

-- Jean-Philippe Caruana
********************************
Ce message et toutes les pieces jointes (ci-apres le "message") sont
confidentiels et etablis a l'attention exclusive de ses destinataires.
Toute utilisation ou diffusion non autorisee est interdite.
Tout message electronique est susceptible d'alteration. CVF decline
toute responsabilite au titre de ce message s'il a ete altere, deforme
ou falsifie.
Si vous n'etes pas destinataire de ce message, merci de le detruire
immediatement et d'avertir l'expediteur.
*********************************
This message and any attachments (the "message") are confidential and
intended solely for the addressees. Any unauthorised use or
dissemination is prohibited.
Messages are susceptible to alteration. CVF shall not be liable for the
message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it
immediately and inform the sender..
********************************

Re: always running test for other project

Posted by Jean-Philippe Caruana <je...@orange-ftgroup.com>.
Le 23/03/2010 16:11, Antoine Toulme a écrit :
>>> You could have changed the version of a dependency in your Buildfile
>>
>> How can I detect a change on my buildfile ?
>> Can I add a file task dependency on the buildfile ?
>
> A Buildfile is a dynamic object - meaning it can fetch the dependency
> numbers from somewhere else, an other file, or using some mechanism.

Then I would add file dependencie on these files - but I don't want my 
build to be so complex. I want everything in the buildfile. -- ntu 
that's not a subject I want to discus right now ;-)

>> That's not what I want : I want to run tests for my artifact and not for
>> the other projects, so I can't use "test=no".
>>
> You can run tests for a particular project.
>
> Here for example:
> buildr myProject:artifactToBuild:test

but, when I run "buildr test", I do it under the 
myProject/artifactToBuild forder.

when I do "buildr myProject:artifactToBuild:test", it does the same : 
runs ALL tests in ALL other dependencies.


-- Jean-Philippe Caruana
********************************
Ce message et toutes les pieces jointes (ci-apres le "message") sont
confidentiels et etablis a l'attention exclusive de ses destinataires.
Toute utilisation ou diffusion non autorisee est interdite.
Tout message electronique est susceptible d'alteration. CVF decline
toute responsabilite au titre de ce message s'il a ete altere, deforme
ou falsifie.
Si vous n'etes pas destinataire de ce message, merci de le detruire
immediatement et d'avertir l'expediteur.
*********************************
This message and any attachments (the "message") are confidential and
intended solely for the addressees. Any unauthorised use or
dissemination is prohibited.
Messages are susceptible to alteration. CVF shall not be liable for the
message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it
immediately and inform the sender..
********************************

Re: always running test for other project

Posted by Antoine Toulme <an...@lunar-ocean.com>.
On Tue, Mar 23, 2010 at 08:05, Jean-Philippe Caruana <
jeanphilippe1.caruana@orange-ftgroup.com> wrote:

> Le 23/03/2010 15:44, Antoine Toulme a écrit :
>
>  It's a bit delicate: we can't know for sure that nothing changed.
>>
>
> But, if nothing changed (no file changed on other projects, so tests are
> always ok), I don't need to rerun tests, as I don't need to re compile.
>
> When i do "buildr compile test=no", the 1st time it does compile every
> project. The 2nd time I launch "buildr compile test=no", it does not compile
> any of them since nothing changed.
> I thought it would be the same behaviour for testing, otherwise I don't see
> the point. Let me quote the online documentation about projects :
> "In reality, it does the right thing. A simple rule to remember is that
> each project definition is executed before you need it, lazy evaluation of
> sort. The reason we do that? So you can write projects that depend on each
> other without worrying about their order."
> What did I miss ? How can compile be different from testing ?


>
> > You could have changed the version of a dependency in your Buildfile
>
> How can I detect a change on my buildfile ?
> Can I add a file task dependency on the buildfile ?

A Buildfile is a dynamic object - meaning it can fetch the dependency
numbers from somewhere else, an other file, or using some mechanism.
No, that won't cut it.

>
>
> > or the tests require internet access.
>
> not in my project : we just do unit testing (
> http://www.artima.com/weblogs/viewpost.jsp?thread=126923). we use CI for
> other testingm purposes (acceptance, integration etc)

OK, but as a rule of thumb, we won't know about it for sure.

>
>
>  To avoid running tests, you can do:
>> buildr package test=NO
>>
>
> That's not what I want : I want to run tests for my artifact and not for
> the other projects, so I can't use "test=no".
>
You can run tests for a particular project.

Here for example:
buildr myProject:artifactToBuild:test

HTH

Antoine


>
> --
> Jean-Philippe Caruana - jeanphilippe.caruana@orange-ftgroup.com
> Tel : 01 53 90 85 33 / 1533 - Projet AVSP
> ********************************
> Ce message et toutes les pieces jointes (ci-apres le "message") sont
> confidentiels et etablis a l'intention exclusive de ses destinataires.
>
> Toute utilisation ou diffusion non autorisee est interdite.
> Tout message electronique est susceptible d'alteration. Multimedia Business
> Services decline toute responsabilite au titre de ce message s'il a ete
> altere, deforme ou falsifie.
>
> Si vous n'etes pas destinataire de ce message, merci de le detruire
> immediatement et d'avertir l'expediteur.
> *********************************
> This message and any attachments (the "message") are confidential and
> intended solely for the addressees. Any unauthorised use or dissemination is
> prohibited.
> Messages are susceptible to alteration. Multimedia Business Services shall
> not be liable for the message if altered, changed or
>
> falsified.
> If you are not the intended addressee of this message, please cancel it
> immediately and inform the sender.
> ********************************
>
>

Re: always running test for other project

Posted by Jean-Philippe Caruana <je...@orange-ftgroup.com>.
Le 23/03/2010 15:44, Antoine Toulme a écrit :
> It's a bit delicate: we can't know for sure that nothing changed.

But, if nothing changed (no file changed on other projects, so tests are 
always ok), I don't need to rerun tests, as I don't need to re compile.

When i do "buildr compile test=no", the 1st time it does compile every 
project. The 2nd time I launch "buildr compile test=no", it does not 
compile any of them since nothing changed.
I thought it would be the same behaviour for testing, otherwise I don't 
see the point. Let me quote the online documentation about projects :
"In reality, it does the right thing. A simple rule to remember is that 
each project definition is executed before you need it, lazy evaluation 
of sort. The reason we do that? So you can write projects that depend on 
each other without worrying about their order."
What did I miss ? How can compile be different from testing ?

 > You could have changed the version of a dependency in your Buildfile

How can I detect a change on my buildfile ?
Can I add a file task dependency on the buildfile ?

 > or the tests require internet access.

not in my project : we just do unit testing 
(http://www.artima.com/weblogs/viewpost.jsp?thread=126923). we use CI 
for other testingm purposes (acceptance, integration etc)

> To avoid running tests, you can do:
> buildr package test=NO

That's not what I want : I want to run tests for my artifact and not for 
the other projects, so I can't use "test=no".

-- 
Jean-Philippe Caruana - jeanphilippe.caruana@orange-ftgroup.com
Tel : 01 53 90 85 33 / 1533 - Projet AVSP
********************************
Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et etablis a l'intention exclusive de ses destinataires.
Toute utilisation ou diffusion non autorisee est interdite.
Tout message electronique est susceptible d'alteration. Multimedia Business Services decline toute responsabilite au titre de ce message s'il a ete altere, deforme ou falsifie.
Si vous n'etes pas destinataire de ce message, merci de le detruire immediatement et d'avertir l'expediteur.
*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. Multimedia Business Services shall not be liable for the message if altered, changed or
falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************


Re: always running test for other project

Posted by Antoine Toulme <an...@lunar-ocean.com>.
It's a bit delicate: we can't know for sure that nothing changed.
You could have changed the version of a dependency in your Buildfile for
example, or the tests require internet access.

To avoid running tests, you can do:
buildr package test=NO

Thanks,

Antoine

On Tue, Mar 23, 2010 at 07:25, Jean-Philippe Caruana <
jeanphilippe1.caruana@orange-ftgroup.com> wrote:

> Hi,
>
> I don't understand how buildr works - I thought i did though.
> I have a project made of several subprojects with dependencies between each
> other.
>
> /myProject (that's where my buildfile is)
> /---/commons-util
> /---/commons-test
> /---/artifactToBuild
>
> so my build file looks like something like this :
> ---------------------------------------------------------------------
> define 'myProject' do
>
>  compile.using :target=>'1.5', :other=>['-encoding', 'ISO8859_1']
> :debug=>true
>
>  desc 'utils for easy testing in the project'
>  define 'commons-test' do
>    compile.with COMMONS_TEST_DEPENDENCIES
>    test.resources
>    package :jar
>  end
>
>  desc 'utils for the whole project'
>  define 'commons-util' do
>    compile.with COMMONS_UTIL_DEPENDENCIES
>    test.with project('commons-test'), JUNIT_3, MOCKRUNNER, DB_UNIT
>    package :jar
>  end
>
>  desc 'i want to build it as fast as possible'
>    define 'artifactToBuild' do
>      compile.with project('commons-util'),
> ARTIFACT_TO_BUILD_UTIL_DEPENDENCIES, COMMONS_UTIL_DEPENDENCIES
>      test.with project('commons-test'), JUNIT_3, DB_UNIT
>      test.exclude 'Abstract*'
>      package :jar
>    end
> end
> ---------------------------------------------------------------------
>
> every time i launch "buildr package" in artifactToBuild or "buildr test",
> it launches all the tests in commons-test and commons-util even if nothing
> changed in this projects. These can be pretty long. How can I do to change
> this behaviour ?
>
> (Buildr 1.3.5 )
>
> Thanks
>
> -- Jean-Philippe Caruana
> ********************************
> Ce message et toutes les pieces jointes (ci-apres le "message") sont
> confidentiels et etablis a l'attention exclusive de ses destinataires.
> Toute utilisation ou diffusion non autorisee est interdite.
> Tout message electronique est susceptible d'alteration. CVF decline
> toute responsabilite au titre de ce message s'il a ete altere, deforme
> ou falsifie.
> Si vous n'etes pas destinataire de ce message, merci de le detruire
> immediatement et d'avertir l'expediteur.
> *********************************
> This message and any attachments (the "message") are confidential and
> intended solely for the addressees. Any unauthorised use or
> dissemination is prohibited.
> Messages are susceptible to alteration. CVF shall not be liable for the
> message if altered, changed or falsified.
> If you are not the intended addressee of this message, please cancel it
> immediately and inform the sender..
> ********************************
>