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 < [email protected]> 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 < > > [email protected]> 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 <[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 > >>>>> > >>>>> > >>>> > >>>> > >
