You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@buildr.apache.org by Pepijn Van Eeckhoudt <pe...@luciad.com> on 2010/03/15 18:10:06 UTC
invoke_with_call_chain not restoring call chain correctly
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
Re: invoke_with_call_chain not restoring call chain correctly
Posted by Pepijn Van Eeckhoudt <pe...@luciad.com>.
On 16/3/2010 07:43, Pepijn Van Eeckhoudt wrote:
>> Second, I'm not sure I understand why Buildr.projects is called in this
>> context. It seems it would lead to duplicate iterations over the same
>> projects in hierarchical projects. Maybe you or Klass can comment on
>> that. (I don't have full picture of everything Ivy4r does)
>
> I don't quite understand why it's done this way either. I'll check
> with the developer of ivy4r and maybe try to restructure the logic to
> avoid the projects call.
Just to give you an update, I've been able to get rid of the need to
call Buildr.projects. I mailed an explanation of the issue and a patch
to Klaas Prause and he has integrated it and released ivy4r 0.9.14 which
resolves the circular dependency.
Thanks for your help Alex,
Pepijn
Re: invoke_with_call_chain not restoring call chain correctly
Posted by Pepijn Van Eeckhoudt <pe...@luciad.com>.
Op 16-mrt-2010 om 01:12 heeft Alex Boisvert <al...@gmail.com>
het volgende geschreven:\
> I'm getting the same behavior (circular dependency detected) on both
> Buildr
> 1.3.5 and trunk so I'm guessing there must be another variable.
Hmm must be something in ourbuild script. I traced the rest of the
invocation chain through the code and it was being reset due to a call
to file().invoke somewhere in the java packaging module.
>
> Second, I'm not sure I understand why Buildr.projects is called in
> this
> context. It seems it would lead to duplicate iterations over the same
> projects in hierarchical projects. Maybe you or Klass can comment on
> that. (I don't have full picture of everything Ivy4r does)
I don't quite understand why it's done this way either. I'll check
with the developer of ivy4r and maybe try to restructure the logic to
avoid the projects call.
>
> One way to break the circle would be to add an option such as
> Buildr.project(:invoke => false) to retrieve the project list without
> invoking projects, with the caveat that not all projects may have
> been fully
> evaluated yet. We could do that if there's a good justification
> for using
> Buildr.project at this stage.
I don't think this should be modified. It feels like this could be
very error prone.
Pepijn
>
> alex
>
> On Mon, Mar 15, 2010 at 3:32 PM, Pepijn Van Eeckhoudt <
> pepijn.vaneeckhoudt@luciad.com> wrote:
>
>> See ivy_extension.rb line 589 (
>> http://github.com/klaas1979/ivy4r/blob/15452546811bc9ae74b0c56f53f52002059d37a8/lib/buildr/ivy_extension.rb
>> ).
>>
>> Pepijn
>>
>> On 15 Mar 2010, at 23:26, Alex Boisvert wrote:
>>
>>> Yes, calling Buildr.projects is a little dangerous at this stage. I
>> would
>>> need to see what actually happens (call order) to give you a good
>>> answer.
>>> Can you provide a simple buildfile that illustrates this?
>>>
>>> alex
>>>
>>>
>>> On Mon, Mar 15, 2010 at 3:01 PM, Pepijn Van Eeckhoudt <
>>> pepijn.vaneeckhoudt@luciad.com> wrote:
>>>
>>>> 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 <alex.boisvert@gmail.com
>>>> >
>> 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 <
>> alex.boisvert@gmail.com
>>>>>> 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 <
>>>>>> pepijn.vaneeckhoudt@luciad.com> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>
>>
Re: invoke_with_call_chain not restoring call chain correctly
Posted by Alex Boisvert <al...@gmail.com>.
I'm getting the same behavior (circular dependency detected) on both Buildr
1.3.5 and trunk so I'm guessing there must be another variable.
Second, I'm not sure I understand why Buildr.projects is called in this
context. It seems it would lead to duplicate iterations over the same
projects in hierarchical projects. Maybe you or Klass can comment on
that. (I don't have full picture of everything Ivy4r does)
One way to break the circle would be to add an option such as
Buildr.project(:invoke => false) to retrieve the project list without
invoking projects, with the caveat that not all projects may have been fully
evaluated yet. We could do that if there's a good justification for using
Buildr.project at this stage.
alex
On Mon, Mar 15, 2010 at 3:32 PM, Pepijn Van Eeckhoudt <
pepijn.vaneeckhoudt@luciad.com> wrote:
> See ivy_extension.rb line 589 (
> http://github.com/klaas1979/ivy4r/blob/15452546811bc9ae74b0c56f53f52002059d37a8/lib/buildr/ivy_extension.rb
> ).
>
> Pepijn
>
> On 15 Mar 2010, at 23:26, Alex Boisvert wrote:
>
> > Yes, calling Buildr.projects is a little dangerous at this stage. I
> would
> > need to see what actually happens (call order) to give you a good answer.
> > Can you provide a simple buildfile that illustrates this?
> >
> > alex
> >
> >
> > On Mon, Mar 15, 2010 at 3:01 PM, Pepijn Van Eeckhoudt <
> > pepijn.vaneeckhoudt@luciad.com> wrote:
> >
> >> 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 <al...@gmail.com>
> 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 <
> alex.boisvert@gmail.com
> >>>> 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 <
> >>>> pepijn.vaneeckhoudt@luciad.com> 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
> >>>>>
> >>>>>
> >>>>
> >>>>
>
>
Re: invoke_with_call_chain not restoring call chain correctly
Posted by Pepijn Van Eeckhoudt <pe...@luciad.com>.
See ivy_extension.rb line 589 (http://github.com/klaas1979/ivy4r/blob/15452546811bc9ae74b0c56f53f52002059d37a8/lib/buildr/ivy_extension.rb).
Pepijn
On 15 Mar 2010, at 23:26, Alex Boisvert wrote:
> Yes, calling Buildr.projects is a little dangerous at this stage. I would
> need to see what actually happens (call order) to give you a good answer.
> Can you provide a simple buildfile that illustrates this?
>
> alex
>
>
> On Mon, Mar 15, 2010 at 3:01 PM, Pepijn Van Eeckhoudt <
> pepijn.vaneeckhoudt@luciad.com> wrote:
>
>> 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 <al...@gmail.com> 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 <alex.boisvert@gmail.com
>>>> 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 <
>>>> pepijn.vaneeckhoudt@luciad.com> 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
>>>>>
>>>>>
>>>>
>>>>
Re: invoke_with_call_chain not restoring call chain correctly
Posted by Alex Boisvert <al...@gmail.com>.
Yes, calling Buildr.projects is a little dangerous at this stage. I would
need to see what actually happens (call order) to give you a good answer.
Can you provide a simple buildfile that illustrates this?
alex
On Mon, Mar 15, 2010 at 3:01 PM, Pepijn Van Eeckhoudt <
pepijn.vaneeckhoudt@luciad.com> wrote:
> 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 <al...@gmail.com> 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 <alex.boisvert@gmail.com
>> >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 <
>>> pepijn.vaneeckhoudt@luciad.com> 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
>>>>
>>>>
>>>
>>>
Re: invoke_with_call_chain not restoring call chain correctly
Posted by Pepijn Van Eeckhoudt <pe...@luciad.com>.
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 <al...@gmail.com>
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 <alex.boisvert@gmail.com
> >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 <
>> pepijn.vaneeckhoudt@luciad.com> 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
>>>
>>
>>
Re: invoke_with_call_chain not restoring call chain correctly
Posted by Alex Boisvert <al...@gmail.com>.
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 <al...@gmail.com>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 <
> pepijn.vaneeckhoudt@luciad.com> 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
>>
>
>
Re: invoke_with_call_chain not restoring call chain correctly
Posted by Alex Boisvert <al...@gmail.com>.
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 <
pepijn.vaneeckhoudt@luciad.com> 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
>