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 Sat, 16 Aug 2008 09:27:31 GMT
On Sat, Aug 16, 2008 at 1:30 AM, Assaf Arkin <> wrote:
> On Fri, Aug 15, 2008 at 4:19 PM, lacton <> wrote:
>> On Fri, Aug 15, 2008 at 11:29 PM, Assaf Arkin <> wrote:
>>> 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
>> buildfile.
>> Still, I would be delighted if buildr had a better way than these
>> venerable tools. :-)
> Yep.  Ideally the only time you would run buildr clean is when making
> a release, and then, just to prove that buildr clean was unnecessary.

Sounds great to me.

>>> 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.
> Or Buildr.application.build_files which also includes buildr.rb,
> tasks/*.rake and (should but doesn't right now) the YAML files.  We'll
> probably want some simpler API to add just one dependency to all these
> tasks.

Yes, you're right.  We need to use the latest timestamp among all those files.

>>>>> 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."
> buildr package --force
> I'm guessing this should only force packaging, but not compile?

I like that.  When using the '--force' option, the goals the user has
explicitely chosen are automatically considered needed.  From a UI
perspective, I think this is great.  It's consistent across tasks and
it feels standard (e.g., 'svn' has a '--force' option too).

Yet, I don't think we're going to need it soon if we implement the
automatic checking of Buildr.application.build_files's timestamps.


> Assaf
>> Lacton
>>> Assaf

View raw message