buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lacton <>
Subject Re: [buildr] Compile and test order
Date Fri, 15 Aug 2008 23:19:17 GMT
On Fri, Aug 15, 2008 at 11:29 PM, Assaf Arkin <> wrote:
> On Fri, Aug 15, 2008 at 1:56 PM, lacton <> wrote:
>> On Fri, Aug 15, 2008 at 8:37 PM, Assaf Arkin <> wrote:
>> Yes. I'm toying with a TestTask that has a custom 'needed?' method
>> that checks timestamps.
>> The algorithm I use is: a test run is needed if and only if there one
>> or more test dependencies with a timestamp later than the time of the
>> last successful test run for this project.
> That would most probably work for what we have right now.  Compile and
> resources both touch their target when they're done running, so if the
> target is newer, something interesting happened.  And test depends on

Required projects are also handled correctly.  If the required project
has changed, then its package will have a new timestamp and it will
make testing the depending project needed.

> My only worry is trying to identify all the things that would not work
> as expected.  For example, if you change the dependencies you use
> (compile.with, test.with, etc) nothing interesting happens.  Tests
> don't run even though they should.

I understand your worry.  In fact, I want to broaden this worry to
compile and package.  If the only thing I change is the buildfile,
calling 'buildr compile' or 'buildr package' will not produce the
right results.  Compile will not happen, though maybe the compile
classpath is now broken (e.g., an API changed).  Package will not
happen, though maybe different items should be packaged now.

It seems to me the assumption made by make, ant, rake and maven is
that the user is expected to call 'clean' if she changes her

Still, I would be delighted if buildr had a better way than these
venerable tools. :-)

> Easy to fix by adding buildfile as a prerequisite (the IDE tasks do just that).

I see.  You're saying tasks like compile, test or package would have
the buildfile as an automatic prerequisite, meaning a change in the
buildfile will make these tasks needed, to be on the safe side.  I
like that.

In my own buildfile, I often add dependencies on the buildfile itself.
 For instance, I may have a resource filter that replaces the
~VERSION~ token to project('foo').version.  Although the resource in
src/main/resources itself may not change, its target needs to be
regenerated when the project version increases.

> What else could we be missing?

I don't have any better idea right now.

>>> But we also need a way to force
>>> all tests to run, especially when you're doing things like coverage
>>> reports or cutting a release.  Ideas?
>> The simplest thing I can imagine is to do exactly what one would do to
>> force all classes to be compiled or packaged.  Call 'buildr clean'.
> Maybe test=force to always report needed? as true?

Yes, that should work and be relatively easy to implement.

Still, I would prefer we find a way of dealing with this issue that
would be consistent no matter the task.  What I would like to read in
the documentation is something along these lines.

"Although buildr has smart mechanisms to decide whether a task is
needed or not, sometimes you will want to force the execution of a
task.  Whether you want to force a compile, a test run, a packaging,
it does not matter, all you have to do is X."


> Assaf
>> Lacton

View raw message