Op 16-mrt-2010 om 01:12 heeft Alex Boisvert <[email protected]>
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 <
[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
