You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@buildr.apache.org by "Antoine Toulme (JIRA)" <ji...@apache.org> on 2016/05/20 07:23:12 UTC

[jira] [Closed] (BUILDR-248) JtestR configuration read twice in different contexts

     [ https://issues.apache.org/jira/browse/BUILDR-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Toulme closed BUILDR-248.
---------------------------------
    Resolution: Auto Closed

Closing for inactivity.

> JtestR configuration read twice in different contexts
> -----------------------------------------------------
>
>                 Key: BUILDR-248
>                 URL: https://issues.apache.org/jira/browse/BUILDR-248
>             Project: Buildr
>          Issue Type: Bug
>          Components: Test frameworks
>    Affects Versions: 1.3.3
>         Environment: Ruby 1.8.6
>            Reporter: Rhett Sutphin
>             Fix For: 1.5
>
>
> When running some known-good (= they work using the jtestr ant task) jtestr specs, I found that it seems that buildr is instance_evaling jtestr_config.rb twice in different contexts.
> Sample output:
> ------
> Running java org.jruby.Main
> undefined method `log_level' for main:Object
> Finished in 0.077696 seconds
> 0 examples, 0 failures
> buildr aborted!
> file:/Users/rsutphin/.m2/repository/org/jtestr/jtestr/0.3.1/jtestr-0.3.1.jar!/jtestr/test_runner.rb:57:in `run'
> /Users/rsutphin/[...]/target/spec/runner.rb:120
> ------
> I tracked "log_level" back to my jtestr_config.rb file whose first line is "log_level :DEBUG".  I put these lines at the top:
> puts "self: #{self.inspect}"
> puts "self.class: #{self.class}"
> and then the output includes this:
> self: #<JtestR::Configuration:0x13862 @values={}>
> self.class: JtestR::Configuration
> self: main
> self.class: Object
> undefined method `log_level' for main:Object
> I've worked around this for the moment by adding the following to the top of my jtestr_config.rb:
> return if self.inspect == "main"
> This isn't a great solution, but I haven't had any luck yet tracking down the source of the extra eval.  I'm reporting this without a solution in case anyone else runs into the same thing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)