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 hellonico@gmail.com
 designates 74.125.44.153 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=YRvy7PKPb+YFVcQF8aL4/WkuWdZP5uzvXv62+ZAK9+/Y82KOnwgpbOebRu5ycBBBYy
         +YqvQppuK1ewdhn+7iKUSvjpWsD71pYmff+B9Y+3f143OkmtV1bnmA9cS3y1czLEdA4l
         p2JLCQoGEydRFNQRbbsXdvV9x8pFuieBoz+BA=
Message-ID: <6539b1ea0810082030n7eca4a89x9d8e6df2a7ae8b95@mail.gmail.com>
Date: Thu, 9 Oct 2008 12:30:17 +0900
From: "Nicolas Modrzyk" <hellonico@gmail.com>
To: buildr-user@incubator.apache.org
Subject: Re: Buildr.settings before buildfile located
In-Reply-To: <3de5d7d20810081925m273a25d5w3a59e82763bfdb98@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <6539b1ea0810081845v530c7309p3d3eed11d6cca52c@mail.gmail.com>
	 <3de5d7d20810081925m273a25d5w3a59e82763bfdb98@mail.gmail.com>

Ok I get it.
The strange thing though, is that right now it only failed for groups,
not for standalone artifacts.

For example, this doesn't cause any troubles:
APACHE_DS = "org.apache.apacheds:noarch-installer:jar:1.5.1"
But this does:
AXIOM = group("axiom-api", "axiom-dom", "axiom-impl",
:under=>"org.apache.ws.commons.axiom", :version=>"1.2.7")

Nicolas,

On Thu, Oct 9, 2008 at 11:25 AM, Assaf Arkin <arkin@intalio.com> wrote:
> On Wed, Oct 8, 2008 at 6:45 PM, Nicolas Modrzyk <hellonico@gmail.com> wrote:
>> Hi list,
>>
>> I am using buildr 1.3.3 (snapshot) not standalone, but embedded into
>> my own script.
>>
>> I have a set of dependencies, and one of them would be:
>> AXIOM = group("axiom-api", "axiom-dom", "axiom-impl",
>> :under=>"org.apache.ws.commons.axiom", :version=>"1.2.7")
>>
>> That call fails with the following:
>> Internal error: Called Buildr.settings before buildfile located (RuntimeError)
>>
>> The full stack trace would be:
>> /Users/niko/tools/gemrepository/gems/buildr-1.3.3/lib/buildr/core/application.rb:144:in
>> `settings': Internal error: Called Buildr.settings before buildfile
>> located (RuntimeError)
>>        from /Users/niko/tools/gemrepository/gems/buildr-1.3.3/lib/buildr/core/application.rb:375:in
>> `settings'
>>        from /Users/niko/tools/gemrepository/gems/buildr-1.3.3/lib/buildr/packaging/artifact.rb:431:in
>> `local'
>>        from /Users/niko/tools/gemrepository/gems/buildr-1.3.3/lib/buildr/packaging/artifact.rb:458:in
>> `locate'
>>        from /Users/niko/tools/gemrepository/gems/buildr-1.3.3/lib/buildr/packaging/artifact.rb:593:in
>> `artifact'
>>        from /Users/niko/tools/gemrepository/gems/buildr-1.3.3/lib/buildr/packaging/artifact.rb:686:in
>> `group'
>>        from /Users/niko/tools/gemrepository/gems/buildr-1.3.3/lib/buildr/packaging/artifact.rb:686:in
>> `map'
>>        from /Users/niko/tools/gemrepository/gems/buildr-1.3.3/lib/buildr/packaging/artifact.rb:686:in
>> `group'
>>        from /Users/niko/projects/tempo.svn/rsc/scripts/../build/dependencies.rb:21
>>
>> I went and look at applications.rb, and there's obviously the line
>> firing the RuntimeError:
>> def settings
>>      fail "Internal error: Called Buildr.settings before buildfile
>> located" unless rakefile
>>      @settings ||= Settings.new(self)
>> end
>>
>> If I comment it out, everything works fine, and it was also working
>> fine with earlier versions of buildr.
>>
>> Is there any reason why we're now forcing the check for a rakefile ?
>
> Settings -- in this case path to local repository -- are loaded and
> cached from optional YAML files, two of which, build.yml and
> profile.yml are located in the same directory as the buildfile.  The
> only way to access these files is to locate the buildfile first, which
> happens during Buildr.application.run.
>
> This sanity check is there to prevent Buildr (or 3rd party library)
> from incorrectly loading settings too early, preventing issues like
> this form cropping undetected:
> https://issues.apache.org/jira/browse/BUILDR-115
>
>> Or anyway I can disable it (apart from touching buildr source code)?
>
> You can create your own Application object that has different behavior
> and assign it to Buildr.application.
>
> Assaf
>
>>
>> Thanks,
>>
>> Nicolas,
>>
>