Mailing-List: contact buildr-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: buildr-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of antoine.contal@gmail.com
 designates 209.85.200.174 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references:x-google-sender-auth;
        b=FN+WBfhXAnFWNuujWIdd55V7jh/bdpB4iY71a/NKRfDV2mjK6zN3FTls1VvFVW5CTx
         ndgFs+pYAUB04eK8OrUDUI3K+1iNcx7F/FCEsPq9Hkridi0aiCUzosMgbYbdTP0c913f
         7XMXQ2ad+Gdk6C6y0+d/w3jYe98Ix5YM/iyuI=
Message-ID: <fbb63c440808160227i76a14270gefe1ecb275e2ed49@mail.gmail.com>
Date: Sat, 16 Aug 2008 11:27:31 +0200
From: lacton <lacton@users.sourceforge.net>
Sender: antoine.contal@gmail.com
To: buildr-user@incubator.apache.org
Subject: Re: [buildr] Compile and test order
In-Reply-To: <3de5d7d20808151630q49f8b3a1xa7f667356b6f147f@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <fbb63c440808141411t1a1b508am4bbc0d4a16b246a8@mail.gmail.com>
	 <3de5d7d20808141442u734bc5afy641cf7c7d76febe2@mail.gmail.com>
	 <fbb63c440808151044g22c02de8t6b0f8e99fc9fd088@mail.gmail.com>
	 <3de5d7d20808151137m1c31346ex7e13f10d47bb87f@mail.gmail.com>
	 <fbb63c440808151356l178aeca5p199146f4eb3b0795@mail.gmail.com>
	 <3de5d7d20808151429q7ab16c09v43de9050fab60198@mail.gmail.com>
	 <fbb63c440808151619x2aed47c3p3b2346e6f4f73501@mail.gmail.com>
	 <3de5d7d20808151630q49f8b3a1xa7f667356b6f147f@mail.gmail.com>

On Sat, Aug 16, 2008 at 1:30 AM, Assaf Arkin <arkin@intalio.com> wrote:
> On Fri, Aug 15, 2008 at 4:19 PM, lacton <lacton@users.sourceforge.net> wrote:
>> On Fri, Aug 15, 2008 at 11:29 PM, Assaf Arkin <arkin@intalio.com> 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.

Lacton

> Assaf
>
>>
>> Lacton
>>
>>> Assaf