New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix various JRuby failures #422

Merged
merged 34 commits into from May 1, 2014

Conversation

Projects
None yet
3 participants
@ddfreyne
Member

ddfreyne commented Apr 14, 2014

This improves compatibility with nanoc on JRuby (and, to a lesser extent, Ruby 1.8.x).

Some changes:

  • JRuby tests are run twice: once with Nokogiri enabled, and once with Nokogiri disabled. JRuby-Nokogiri has several problems (most of them being worked on), but I’d much rather split up the tests while waiting for Nokogiri to be fixed.
  • A warning message is printed when using Nokogiri on JRuby. See above for the reasoning why.
  • JRuby with 1.8 mode has been dropped. If you already have JRuby, why would you want to run it in 1.8 mode?
  • The Gemfile now more clearly defines supported platforms for dependencies. It has been modified to accomodate both JRuby and Ruby 1.8.x.
  • Temp path creation is more reliable on JRuby (JRuby seems to delete empty temp directories, which is sensible, but breaks an assumption made by nanoc).

@ddfreyne ddfreyne changed the title from Fix various JRuby failures to [WIP] Fix various JRuby failures Apr 14, 2014

@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Apr 14, 2014

Member

I reported a bunch of issues for Nokogiri on JRuby, that came to light in the nanoc test cases:

Member

ddfreyne commented Apr 14, 2014

I reported a bunch of issues for Nokogiri on JRuby, that came to light in the nanoc test cases:

@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne
Member

ddfreyne commented Apr 20, 2014

Skip Nokogiri tests on JRuby
Nokogiri on JRuby is unusably buggy. For details, see #422.
@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Apr 20, 2014

Member

I’ve decided to skip all Nokogiri tests on JRuby, because that library is insanely buggy and I just don’t want to deal with it anymore.

I’m considering printing a warning whenever Nokogiri is used on JRuby. @bobthecow Thoughts?

Member

ddfreyne commented Apr 20, 2014

I’ve decided to skip all Nokogiri tests on JRuby, because that library is insanely buggy and I just don’t want to deal with it anymore.

I’m considering printing a warning whenever Nokogiri is used on JRuby. @bobthecow Thoughts?

@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Apr 20, 2014

Member

The following is now printed when using Nokogiri on JRuby:

--------------------------------------------------------------------------------
Caution:

Nokogiri on JRuby has severe bugs that prevent it from producing correct results
in many cases. For example, the nanoc test cases revealed the following bugs:

- http://github.com/sparklemotion/nokogiri/issues/1077
- http://github.com/sparklemotion/nokogiri/issues/1078
- http://github.com/sparklemotion/nokogiri/issues/1079
- http://github.com/sparklemotion/nokogiri/issues/1080
- http://github.com/sparklemotion/nokogiri/issues/1081
- http://github.com/sparklemotion/nokogiri/issues/1084

Because of these issues, we advise against using Nokogiri on JRuby. If you need
XML parsing functionality, consider not using JRuby for the time being.
--------------------------------------------------------------------------------

Given the bugginess of the library, I think it’s necessary to warn users so that they know what to expect.

Suggestions about the phrasing is quite welcome.

Member

ddfreyne commented Apr 20, 2014

The following is now printed when using Nokogiri on JRuby:

--------------------------------------------------------------------------------
Caution:

Nokogiri on JRuby has severe bugs that prevent it from producing correct results
in many cases. For example, the nanoc test cases revealed the following bugs:

- http://github.com/sparklemotion/nokogiri/issues/1077
- http://github.com/sparklemotion/nokogiri/issues/1078
- http://github.com/sparklemotion/nokogiri/issues/1079
- http://github.com/sparklemotion/nokogiri/issues/1080
- http://github.com/sparklemotion/nokogiri/issues/1081
- http://github.com/sparklemotion/nokogiri/issues/1084

Because of these issues, we advise against using Nokogiri on JRuby. If you need
XML parsing functionality, consider not using JRuby for the time being.
--------------------------------------------------------------------------------

Given the bugginess of the library, I think it’s necessary to warn users so that they know what to expect.

Suggestions about the phrasing is quite welcome.

@ddfreyne ddfreyne changed the title from [WIP] Fix various JRuby failures to Fix various JRuby failures Apr 20, 2014

@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Apr 20, 2014

Member

All JRuby issues are now fixed (apart from the Nokogiri ones; those are just skipped).

CC @bobthecow

Member

ddfreyne commented Apr 20, 2014

All JRuby issues are now fixed (apart from the Nokogiri ones; those are just skipped).

CC @bobthecow

@ddfreyne ddfreyne added to review and removed waiting labels Apr 20, 2014

@bobthecow

This comment has been minimized.

Show comment
Hide comment
@bobthecow

bobthecow Apr 20, 2014

Member

I feel like leaving nokogiri tests in and marking jruby as an allowed failure is slightly better. That way it's very clear that jruby/nokogiri is still crappy until it's fixed.

Member

bobthecow commented Apr 20, 2014

I feel like leaving nokogiri tests in and marking jruby as an allowed failure is slightly better. That way it's very clear that jruby/nokogiri is still crappy until it's fixed.

@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Apr 20, 2014

Member

@bobthecow What about running JRuby twice, once with Nokogiri enabled and once with Nokogiri disabled?

Member

ddfreyne commented Apr 20, 2014

@bobthecow What about running JRuby twice, once with Nokogiri enabled and once with Nokogiri disabled?

@bobthecow

This comment has been minimized.

Show comment
Hide comment
@bobthecow

bobthecow Apr 20, 2014

Member

@ddfreyne Yeah, good call.

Member

bobthecow commented Apr 20, 2014

@ddfreyne Yeah, good call.

@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Apr 20, 2014

Member

Done. (Seems like there is a new JRuby failure related to piper… odd. Will fix later.)

Member

ddfreyne commented Apr 20, 2014

Done. (Seems like there is a new JRuby failure related to piper… odd. Will fix later.)

@bobthecow

This comment has been minimized.

Show comment
Hide comment
@bobthecow

bobthecow Apr 21, 2014

Member

would this still fall into the "allowed failure" of jruby-1.7.11 below?

Member

bobthecow commented on .travis.yml in f885fe7 Apr 21, 2014

would this still fall into the "allowed failure" of jruby-1.7.11 below?

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Apr 21, 2014

Member

It was meant to be, but didn’t work out. I probably need to tweak the allow_failures section to set an explicit empty env.

But… I think it’s fine to leave it as an allowed failure, because it gives the impression that JRuby is an officially supported platform, which we can’t really afford given the JRuby-Nokogiri problems, and the new jruby/jruby#1647 which I found yesterday.

Speaking of officially supporting platforms: the nanoc web site should clearly list what platforms are supported and under which conditions. I’d say:

Ruby language versions

  • Ruby 1.8.x - not supported, but we’ll do our best (as in, a Ruby 1.8.x incompatibility will be fixed)
  • Ruby 1.9.x - supported
  • Ruby 2.0.x - supported
  • Ruby 2.1.x - supported

Platforms

  • MRI - supported
  • JRuby - tested, not supported?
  • Rubinius - tested, not supported?

I am not sure whether “supported” should mean that nanoc can and will provide workarounds for known bugs. (Thinking of jruby/jruby#1647 now.)

Member

ddfreyne replied Apr 21, 2014

It was meant to be, but didn’t work out. I probably need to tweak the allow_failures section to set an explicit empty env.

But… I think it’s fine to leave it as an allowed failure, because it gives the impression that JRuby is an officially supported platform, which we can’t really afford given the JRuby-Nokogiri problems, and the new jruby/jruby#1647 which I found yesterday.

Speaking of officially supporting platforms: the nanoc web site should clearly list what platforms are supported and under which conditions. I’d say:

Ruby language versions

  • Ruby 1.8.x - not supported, but we’ll do our best (as in, a Ruby 1.8.x incompatibility will be fixed)
  • Ruby 1.9.x - supported
  • Ruby 2.0.x - supported
  • Ruby 2.1.x - supported

Platforms

  • MRI - supported
  • JRuby - tested, not supported?
  • Rubinius - tested, not supported?

I am not sure whether “supported” should mean that nanoc can and will provide workarounds for known bugs. (Thinking of jruby/jruby#1647 now.)

@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Apr 21, 2014

Member

Getting this error locally, and a different one on Travis CI:

  1) Error:
Nanoc::OutdatednessCheckerTest#test_outdated_if_dependent_item_outdated:
Errno::ENOENT: No such file or directory - /private/var/folders/jf/v8gkrcc973l5l6f6561_zqp00000gn/T/nanoc-test20140421-80471-59vd3x/foo/tmp/text_items/20140421-80471-1idmpu7
    org/jruby/RubyFile.java:361:in `initialize'
    org/jruby/RubyIO.java:1178:in `open'
    /Users/ddfreyne/.rubies/jruby-1.7.11/lib/ruby/1.9/fileutils.rb:1380:in `copy_file'
    /Users/ddfreyne/.rubies/jruby-1.7.11/lib/ruby/1.9/fileutils.rb:477:in `copy_file'
    /Users/ddfreyne/.rubies/jruby-1.7.11/lib/ruby/1.9/fileutils.rb:396:in `cp'
    /Users/ddfreyne/.rubies/jruby-1.7.11/lib/ruby/1.9/fileutils.rb:1525:in `fu_each_src_dest'
    /Users/ddfreyne/.rubies/jruby-1.7.11/lib/ruby/1.9/fileutils.rb:1541:in `fu_each_src_dest0'
    /Users/ddfreyne/.rubies/jruby-1.7.11/lib/ruby/1.9/fileutils.rb:1523:in `fu_each_src_dest'
    /Users/ddfreyne/.rubies/jruby-1.7.11/lib/ruby/1.9/fileutils.rb:395:in `cp'
    /Users/ddfreyne/Documents/Development/nanoc/repos/nanoc/lib/nanoc/base/result_data/item_rep.rb:146:in `write'
[snip]
Member

ddfreyne commented Apr 21, 2014

Getting this error locally, and a different one on Travis CI:

  1) Error:
Nanoc::OutdatednessCheckerTest#test_outdated_if_dependent_item_outdated:
Errno::ENOENT: No such file or directory - /private/var/folders/jf/v8gkrcc973l5l6f6561_zqp00000gn/T/nanoc-test20140421-80471-59vd3x/foo/tmp/text_items/20140421-80471-1idmpu7
    org/jruby/RubyFile.java:361:in `initialize'
    org/jruby/RubyIO.java:1178:in `open'
    /Users/ddfreyne/.rubies/jruby-1.7.11/lib/ruby/1.9/fileutils.rb:1380:in `copy_file'
    /Users/ddfreyne/.rubies/jruby-1.7.11/lib/ruby/1.9/fileutils.rb:477:in `copy_file'
    /Users/ddfreyne/.rubies/jruby-1.7.11/lib/ruby/1.9/fileutils.rb:396:in `cp'
    /Users/ddfreyne/.rubies/jruby-1.7.11/lib/ruby/1.9/fileutils.rb:1525:in `fu_each_src_dest'
    /Users/ddfreyne/.rubies/jruby-1.7.11/lib/ruby/1.9/fileutils.rb:1541:in `fu_each_src_dest0'
    /Users/ddfreyne/.rubies/jruby-1.7.11/lib/ruby/1.9/fileutils.rb:1523:in `fu_each_src_dest'
    /Users/ddfreyne/.rubies/jruby-1.7.11/lib/ruby/1.9/fileutils.rb:395:in `cp'
    /Users/ddfreyne/Documents/Development/nanoc/repos/nanoc/lib/nanoc/base/result_data/item_rep.rb:146:in `write'
[snip]
@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Apr 21, 2014

Member

On Ruby 1.8.x:

623 tests, 1596 assertions, 2 failures, 12 errors, 34 skips

Lots of dependencies without Ruby 1.8.x support, hence the skips. Other problems:

  • Open3 does not have a wait thread, hence undefined methodvalue' for nil:NilClass`
  • Ruby 1.8.x does not have #each_with_object, hence undefined method 'each_with_object'
  • Other broken tests due to libraries not being available on 1.8.x and only on 1.9.x
Member

ddfreyne commented Apr 21, 2014

On Ruby 1.8.x:

623 tests, 1596 assertions, 2 failures, 12 errors, 34 skips

Lots of dependencies without Ruby 1.8.x support, hence the skips. Other problems:

  • Open3 does not have a wait thread, hence undefined methodvalue' for nil:NilClass`
  • Ruby 1.8.x does not have #each_with_object, hence undefined method 'each_with_object'
  • Other broken tests due to libraries not being available on 1.8.x and only on 1.9.x
@headius

This comment has been minimized.

Show comment
Hide comment
@headius

headius Apr 21, 2014

Please don't quietly mask failures when you encounter them on JRuby. Usually if you make a bit more noise, the JRuby team is willing to assist with third-party libraries. By masking the failures you only allow the issues to remain.

Nokogiri is a difficult library to simulate on JRuby because libxml has such a broad set of features and because it's very forgiving of bad XML content. We are always looking for help to keep it going.

headius commented Apr 21, 2014

Please don't quietly mask failures when you encounter them on JRuby. Usually if you make a bit more noise, the JRuby team is willing to assist with third-party libraries. By masking the failures you only allow the issues to remain.

Nokogiri is a difficult library to simulate on JRuby because libxml has such a broad set of features and because it's very forgiving of bad XML content. We are always looking for help to keep it going.

@headius

This comment has been minimized.

Show comment
Hide comment
@headius

headius Apr 21, 2014

I looked into these issues, since @ddfreyne made a point of calling JRuby-Nokogiri "a horrible horrible thing" on IRC.

We certainly don't guarantee that JRuby-Nokogiri is perfect, but it passes Nokogiri's tests. Your bug reports help us improve it, but Nokogiri also has very few dev resources right now. In the future, try to hunt down someone responsible for fixing Nokogiri and make it clear these issues are a high priority for you...or help try to investigate or fix the issues yourself.

headius commented Apr 21, 2014

I looked into these issues, since @ddfreyne made a point of calling JRuby-Nokogiri "a horrible horrible thing" on IRC.

We certainly don't guarantee that JRuby-Nokogiri is perfect, but it passes Nokogiri's tests. Your bug reports help us improve it, but Nokogiri also has very few dev resources right now. In the future, try to hunt down someone responsible for fixing Nokogiri and make it clear these issues are a high priority for you...or help try to investigate or fix the issues yourself.

ddfreyne added some commits Apr 21, 2014

Fix JRuby-related Gemfile platforms
With C extensions disabled, a bunch of dependencies failed to compile.
Fix broken XSLT stylesheet
XSLT stylesheets that use variable names must define the variables.
libxml appears to be too permissive and allow broken stylesheets, while
JRuby-Nokogiri correctly fails to parse the stylesheet.

For details, see the following analysis of this issue by @headius:
sparklemotion/nokogiri#1078 (comment)

This test still fails due to a missing <?xml> header. For details, see
sparklemotion/nokogiri#1079
@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Apr 21, 2014

Member

@headius Thanks for your involvement. We’re working hard to make JRuby a supported platform for nanoc, hence all the noise.

Please don't quietly mask failures when you encounter them on JRuby.

There are currently two cases of JRuby-related failures being masked:

  • The test that revealed the jruby/jruby#1647 bug is skipped when the JRuby version is equal to 1.7.11. This test will start failing as soon as a newer release is used in Travis CI.
  • JRuby tests are run once with Nokogiri enabled, and once with Nokogiri disabled.
    • With Nokogiri disabled, there are few remaining failures. Once JRuby-without-Nokogiri is free of failures, I’d like to make this an officially supported platform (i.e. remove it from the allow_failures from .travis.yml).
    • With Nokogiri enabled, about a dozen failures remain, and I don’t feel like working around these issues since the tests should simply remain failing.

I’d much rather make JRuby a supported platform with clearly indicated known problems (i.e. the ones related to Nokogiri) rather than waiting for everything to be fixed. Nokogiri is not essential for nanoc to function properly.

Member

ddfreyne commented Apr 21, 2014

@headius Thanks for your involvement. We’re working hard to make JRuby a supported platform for nanoc, hence all the noise.

Please don't quietly mask failures when you encounter them on JRuby.

There are currently two cases of JRuby-related failures being masked:

  • The test that revealed the jruby/jruby#1647 bug is skipped when the JRuby version is equal to 1.7.11. This test will start failing as soon as a newer release is used in Travis CI.
  • JRuby tests are run once with Nokogiri enabled, and once with Nokogiri disabled.
    • With Nokogiri disabled, there are few remaining failures. Once JRuby-without-Nokogiri is free of failures, I’d like to make this an officially supported platform (i.e. remove it from the allow_failures from .travis.yml).
    • With Nokogiri enabled, about a dozen failures remain, and I don’t feel like working around these issues since the tests should simply remain failing.

I’d much rather make JRuby a supported platform with clearly indicated known problems (i.e. the ones related to Nokogiri) rather than waiting for everything to be fixed. Nokogiri is not essential for nanoc to function properly.

@ddfreyne ddfreyne added feature and removed feature labels Apr 21, 2014

@ddfreyne ddfreyne changed the title from Fix various JRuby failures to Fix various JRuby and Ruby 1.8.x failures Apr 21, 2014

ddfreyne added some commits Apr 21, 2014

Do not use #each_with_object
Ruby 1.8.x does not have #each_with_object; Ruby 1.9+ does.
Skip ordered hash test on Ruby 1.8.x.
Ruby 1.8.x does not have ordered hashes; Ruby 1.9+ does.
@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Apr 21, 2014

Member

Ruby 1.8.x doesn’t have a way of figuring out the exit status of the child. That’s unfortunate, as it means popen3 can’t be used reliably.

This article suggests to use either the open4 functionality built into JRuby, or using the open4 gem.

Member

ddfreyne commented Apr 21, 2014

Ruby 1.8.x doesn’t have a way of figuring out the exit status of the child. That’s unfortunate, as it means popen3 can’t be used reliably.

This article suggests to use either the open4 functionality built into JRuby, or using the open4 gem.

@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Apr 21, 2014

Member

The jruby-18mode Travis CI target is problematic now. It errors with the following message:

Gem::InstallError: celluloid requires Ruby version >= 1.9.2.

This makes sense, since the Gemfile contains (simplified) this:

gem 'listen', :platforms => [:ruby_19, :ruby_20, :ruby_21, :jruby]

Listen depends on celluloid, which is not compatible with 1.8.x (because Celluloid uses fibers, I believe, which are available on 1.9+ only).

The :jruby symbol here should really be something like “JRuby-but-not-1.8”.

That is, unless we decide to only support JRuby with 1.9 support, and only support 1.8.x on MRI. Thoughts?

Member

ddfreyne commented Apr 21, 2014

The jruby-18mode Travis CI target is problematic now. It errors with the following message:

Gem::InstallError: celluloid requires Ruby version >= 1.9.2.

This makes sense, since the Gemfile contains (simplified) this:

gem 'listen', :platforms => [:ruby_19, :ruby_20, :ruby_21, :jruby]

Listen depends on celluloid, which is not compatible with 1.8.x (because Celluloid uses fibers, I believe, which are available on 1.9+ only).

The :jruby symbol here should really be something like “JRuby-but-not-1.8”.

That is, unless we decide to only support JRuby with 1.9 support, and only support 1.8.x on MRI. Thoughts?

@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Apr 21, 2014

Member

Seems like JRuby (without Nokogiri) is passing the tests now. Sweet!

I believe the Tempfile trick I used to create a new path (rather than a file) is unreliable. I’m doing this:

      def temp_filename
        FileUtils.mkdir_p(TMP_TEXT_ITEMS_DIR)
        tempfile = Tempfile.new('', TMP_TEXT_ITEMS_DIR)
        new_filename = tempfile.path
        tempfile.close!

        File.expand_path(new_filename)
      end

That should really be replaced with something that returns a unique, new and unused filename in a directory that is guaranteed to exist. The Tempfile#close! method makes no guarantee that the directory of the temporary file won’t be deleted. (In fact, deleting the directory if it’s empty makes sense.)

So, it seems to me that exchanging the Tempfile trick with proper temp-path logic is a requirement for this PR to be merged.

Member

ddfreyne commented Apr 21, 2014

Seems like JRuby (without Nokogiri) is passing the tests now. Sweet!

I believe the Tempfile trick I used to create a new path (rather than a file) is unreliable. I’m doing this:

      def temp_filename
        FileUtils.mkdir_p(TMP_TEXT_ITEMS_DIR)
        tempfile = Tempfile.new('', TMP_TEXT_ITEMS_DIR)
        new_filename = tempfile.path
        tempfile.close!

        File.expand_path(new_filename)
      end

That should really be replaced with something that returns a unique, new and unused filename in a directory that is guaranteed to exist. The Tempfile#close! method makes no guarantee that the directory of the temporary file won’t be deleted. (In fact, deleting the directory if it’s empty makes sense.)

So, it seems to me that exchanging the Tempfile trick with proper temp-path logic is a requirement for this PR to be merged.

Move temp path creation logic into new TempPathRegistry
Using `Tempfile` is unreliable as there is no guarantee that the
generated temporary file's directory will not be deleted after calling
`Tempfile#close!`.
@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Apr 21, 2014

Member

Temporary path creation logic is now in a separate TempPathRegistry (WIP).

Member

ddfreyne commented Apr 21, 2014

Temporary path creation logic is now in a separate TempPathRegistry (WIP).

@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Apr 22, 2014

Member

This PR is ready to be reviewed.

Open questions:

  • Should we disable jruby-18mode? (My vote: yes)
  • Should we move JRuby 1.7.11 (without Nokogiri) out of allowed failures? (My vote: yes)

There are still some Ruby 1.8.x and Rubinius issues, but I’ll tackle those in separate PRs.

Member

ddfreyne commented Apr 22, 2014

This PR is ready to be reviewed.

Open questions:

  • Should we disable jruby-18mode? (My vote: yes)
  • Should we move JRuby 1.7.11 (without Nokogiri) out of allowed failures? (My vote: yes)

There are still some Ruby 1.8.x and Rubinius issues, but I’ll tackle those in separate PRs.

@ddfreyne ddfreyne changed the title from Fix various JRuby and Ruby 1.8.x failures to Fix various JRuby failures Apr 22, 2014

@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Apr 22, 2014

Member

JRuby 1.8 mode disabled and JRuby 1.7.11 removed from allowed failures after discussing with @bobthecow.

Member

ddfreyne commented Apr 22, 2014

JRuby 1.8 mode disabled and JRuby 1.7.11 removed from allowed failures after discussing with @bobthecow.

@ddfreyne ddfreyne added the to review label Apr 22, 2014

Reword Pure Java Nokogiri warning
The original message was too negative.
@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Apr 22, 2014

Member

I’ve reworded the JRuby-Nokogiri message to be more constructive:

Note:

The behavior of Pure Java Nokogiri differs from the Nokogiri used on the
standard Ruby interpreter (MRI) due to differences in underlying libraries.

These sometimes problematic behavioral differences can cause nanoc filters not
to function properly, if at all. If you need reliable (X)HTML and XML handling
functionality, consider not using Nokogiri on JRuby for the time being.

These issues are being worked on both from the Nokogiri and the nanoc side. Keep
your Nokogiri and nanoc versions up to date!

For details, see https://github.com/nanoc/nanoc/pull/422.

@headius Apologies for letting my frustrations get the better of me.

Member

ddfreyne commented Apr 22, 2014

I’ve reworded the JRuby-Nokogiri message to be more constructive:

Note:

The behavior of Pure Java Nokogiri differs from the Nokogiri used on the
standard Ruby interpreter (MRI) due to differences in underlying libraries.

These sometimes problematic behavioral differences can cause nanoc filters not
to function properly, if at all. If you need reliable (X)HTML and XML handling
functionality, consider not using Nokogiri on JRuby for the time being.

These issues are being worked on both from the Nokogiri and the nanoc side. Keep
your Nokogiri and nanoc versions up to date!

For details, see https://github.com/nanoc/nanoc/pull/422.

@headius Apologies for letting my frustrations get the better of me.

@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Apr 22, 2014

Member

Ready for review.

Member

ddfreyne commented Apr 22, 2014

Ready for review.

@bobthecow

This comment has been minimized.

Show comment
Hide comment
@bobthecow

bobthecow Apr 22, 2014

Member

haven't reviewed the code yet, but the warning is better.

Member

bobthecow commented Apr 22, 2014

haven't reviewed the code yet, but the warning is better.

@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Apr 23, 2014

Member

Hm, had ~> 1.5.5 for Nokogiri in the Gemfile. I don’t quite remember what that was for, so I changed it to ~> 1.6. Maybe I should get rid of it entirely?

It doesn’t affect any of the reported issues, since those were tested outside of the nanoc context.

Member

ddfreyne commented Apr 23, 2014

Hm, had ~> 1.5.5 for Nokogiri in the Gemfile. I don’t quite remember what that was for, so I changed it to ~> 1.6. Maybe I should get rid of it entirely?

It doesn’t affect any of the reported issues, since those were tested outside of the nanoc context.

@@ -94,6 +94,10 @@ def test_run_with_exclude
def test_run_with_symlink_to_output_dir
skip_unless_have_symlink
if defined?(JRUBY_VERSION) && JRUBY_VERSION == '1.7.11'

This comment has been minimized.

@bobthecow

bobthecow Apr 30, 2014

Member

should that be <= or something?

@bobthecow

bobthecow Apr 30, 2014

Member

should that be <= or something?

This comment has been minimized.

@ddfreyne

ddfreyne Apr 30, 2014

Member

Theoretically, yes, but I only really care about the version that is currently the latest one. (Travis CI runs 1.7.11.)

@ddfreyne

ddfreyne Apr 30, 2014

Member

Theoretically, yes, but I only really care about the version that is currently the latest one. (Travis CI runs 1.7.11.)

@bobthecow

This comment has been minimized.

Show comment
Hide comment
@bobthecow

bobthecow Apr 30, 2014

Member

👍

Member

bobthecow commented Apr 30, 2014

👍

ddfreyne added a commit that referenced this pull request May 1, 2014

@ddfreyne ddfreyne merged commit 14ceafc into release-3.6.x May 1, 2014

1 check passed

continuous-integration/travis-ci The Travis CI build passed
Details

@ddfreyne ddfreyne deleted the bug/fix-jruby-failures branch May 1, 2014

@ddfreyne ddfreyne removed the to review label May 1, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment