Uploaded image for project: 'Buildr (Retired)'
  1. Buildr (Retired)
  2. BUILDR-248

JtestR configuration read twice in different contexts

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Auto Closed
    • 1.3.3
    • 1.5
    • Test frameworks
    • None
    • Ruby 1.8.6

    Description

      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.

      Attachments

        Activity

          People

            Unassigned Unassigned
            rsutphin Rhett Sutphin
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: