Will do. I uncivered this one when trying to use ivy4r with buildr
trunk. Turns out ivy4r causes a circular dependency in trunk but not
in 1.3.5 due to this issue. The circular dependency is caused by a
call to Buildr.projects from an after_define callback. This causes a
call to invoke on the project being defined as well triggering the
circular dependency exception. Is there a way to resolve this or
should ivy4r be tweaked so the projects call is avoided?
Pepijn
Op 15-mrt-2010 om 18:23 heeft Alex Boisvert <[email protected]>
het volgende geschreven:\
Would you mind filing a Jira issue with your spec? Just to clear
the IP.
thanks,
alex
On Mon, Mar 15, 2010 at 10:20 AM, Alex Boisvert <[email protected]
>wrote:
Wheeep! Yes, it's an issue. I'll fix it right away.
alex
On Mon, Mar 15, 2010 at 10:10 AM, Pepijn Van Eeckhoudt <
[email protected]> wrote:
I'm bumping into unpredictable behaviour related to the call chain
handling. It seems invoke_with_call_chain doesn't restore the call
chain
correctly after calling invoke. Since this is in the core of
buildr I wanted
to just check with you guys before creating an issue in jira.
invoke_with_call_chain currently does
begin
old_chain, Thread.current[:rake_chain] = Thread.current
[:rake_chain],
new_chain
execute(task_args) if needed?
ensure
Thread.current[:rake_chain] = nil
end
The ensure block seems obviously incorrect. Shouldn't this be
Thread.current[:rake_chain] = old_chain?
The following spec shows when this causes things to go wrong:
describe Buildr do
it 'should restore call chain when invoke is called' do
task1 = Rake::Task.define_task('task1') do
end
task2 = Rake::Task.define_task('task2') do
chain1 = Thread.current[:rake_chain]
task1.invoke
chain2 = Thread.current[:rake_chain]
chain2.should == chain1
end
task2.invoke
end
end
So is this an issue or intentional?
Regards,
Pepijn
