buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <>
Subject Re: [buildr] Compile and test order
Date Sun, 17 Aug 2008 22:32:55 GMT
On Sat, Aug 16, 2008 at 2:27 AM, lacton <> wrote:
> 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
>>> 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.

I think the easiest way would be to define a custom task
(BuildfileTask, or something like that) that collects the latest
timestamp from either buildfile or any of its dependencies, and make
that accessible from Buildr.appication.

Right now Buildr.application.buildfile returns a file name, maybe
change that to return the task instead, and we won't need build_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.
> Lacton
>> Assaf
>>> Lacton
>>>> Assaf

View raw message