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)