search

asciidoctor / asciidoctorj

:coffee: Java bindings for Asciidoctor. Asciidoctor on the JVM!
http://asciidoctor.org
Apache License 2.0
625 stars 173 forks source link

asciidoctorj-diagram 1.3.0 does not work on Windows with JRuby 1.7.22 #401

Closed robertpanzer closed 8 years ago

robertpanzer commented 8 years ago

When trying to render the test document from the asciidoctorj-diagram on Win7 via the distribution rendering fails with an exception:

c:\work\asciidoctorj-1.5.3.1\bin>asciidoctorj -r asciidoctor-diagram test.adoc
io/console not supported; tty will not be manipulated
Exception in thread "main" org.jruby.exceptions.RaiseException: (Errno::ENOENT) C:\work\asciidoctorj-1.5.3.1\lib\asciidoctorj-diagra
m-1.3.0.jar!\gems\asciidoctor-diagram-1.3.0\lib\asciidoctor-diagram\blockdiag.rb
        at org.jruby.RubyFile.realpath(org/jruby/RubyFile.java:840)
        at RUBY.require_relative(file:/C:/work/asciidoctorj-1.5.3.1/lib/jruby-complete-1.7.22.jar!/jruby/kernel19/kernel.rb:11)
        at RUBY.(root)(C:/work/asciidoctorj-1.5.3.1/lib/asciidoctorj-diagram-1.3.0.jar!/gems/asciidoctor-diagram-1.3.0/lib/asciidoct
or-diagram/blockdiag.rb:2)
        at org.jruby.RubyKernel.require(org/jruby/RubyKernel.java:1040)
        at RUBY.(root)(/C:/work/asciidoctorj-1.5.3.1/lib/jruby-complete-1.7.22.jar!/META-INF/jruby.home/lib/ruby/shared/rubygems/cor
e_ext/kernel_require.rb:1)
        at RUBY.require(/C:/work/asciidoctorj-1.5.3.1/lib/jruby-complete-1.7.22.jar!/META-INF/jruby.home/lib/ruby/shared/rubygems/co
re_ext/kernel_require.rb:54)
        at org.jruby.RubyKernel.require(org/jruby/RubyKernel.java:1040)
        at RUBY.(root)(C:/work/asciidoctorj-1.5.3.1/lib/asciidoctorj-diagram-1.3.0.jar!/gems/asciidoctor-diagram-1.3.0/lib/asciidoct
or-diagram.rb:1)
        at RUBY.(root)(/C:/work/asciidoctorj-1.5.3.1/lib/jruby-complete-1.7.22.jar!/META-INF/jruby.home/lib/ruby/shared/rubygems/cor
e_ext/kernel_require.rb:1)

So what actually fails is this line in blockdiag.rb:

require_relative 'version'

But a version.rb exists next to the blockdiag.rb!

I can't reproduce that on Linux (in a Docker container) nor in the test cases on Win that also render this document.

Funny thing is that it works if I use another JRuby like 1.7.21 or lower.

Or maybe I just have a bad karma today...

robertpanzer commented 8 years ago

Problem does also not occur on OS X.

ysb33r commented 8 years ago

I'm sure I've seen something similar like this on an older version of JRuby in the asciidoctor-gradle-plugin.

An on this note, are we not going to use JRuby 9.x? (or is that a 1.6.0 thing).

mojavelinux commented 8 years ago

This looks a lot like a process error in JRuby. They were making a lot of changes in that area of the code and capabilities went in and out for several releases. Does it work with JRuby 9000? There were also fixes to Asciidoctor Diagram 1.3.1 for Windows, so it could be related to that as well. https://github.com/asciidoctor/asciidoctor-diagram/commit/835bcd1c38b1644ab2962a42d59f89cf5a586446

mojavelinux commented 8 years ago

@ysb33r We are shipping AsciidoctorJ with JRuby 1.7 by default (in the dep tree), but we are recommending everyone switch to JRuby 9000 now. No one should be using JRuby 1.7 unless they absolutely must because frankly it was showing a lot of problems in the later releases.

ysb33r commented 8 years ago

Just to correct something. It was not in asciidoctor-gradle-plugin where I saw it, but jruby-gradle/jruby-gradle-plugin#83. Remember this @mojavelinux? It also involved the asciidoctor-diagram GEM but seems to have been fixed in 1.7.17.

Not exactly the same error, but quite coincidental that it was asciidoctor-diagram involved again.

mojavelinux commented 8 years ago

Asciidoctor Diagram does some pretty advanced tty stuff, so it's not unlikely that if we are going to hit bugs, that it will scare them out.

ysb33r commented 8 years ago

@ysb33r We are shipping AsciidoctorJ with JRuby 1.7 by default (in the dep tree), but we are recommending everyone switch to JRuby 9000 now. No one should be using JRuby 1.7 unless they absolutely must because frankly it was showing a lot of problems in the later releases.

This still leaves the problem with the full asciidoctorj distribution, which would bundle 1.7.22. Should we not rather just downgrade it to 1.7.21 for thie point release?

(Still thinking though that as from 1.6.0 we should bundle 9k as the default).

mojavelinux commented 8 years ago

downgrade it to 1.7.21 for thie point release?

Sounds like a wise plan. We should verify that actually solves the problem. Is there any other reason we need 1.7.22 (security?)

(Still thinking though that as from 1.6.0 we should bundle 9k as the default).

That's a certainty.

robertpanzer commented 8 years ago

The funny thing is that the test case does not fail! That means that the require_relative is successfully resolved when the gem is exploded in the file system. If it's packaged in a jar, it fails.

I'm also for downgrading to 1.7.21, I just chose the newest version.

I am a bit reluctant to jump on JRuby 9000 with a 1.5.3 release because it also means that we raise the runtime requirements from Java 6 to 7.

Am 03.11.2015 um 22:00 schrieb Dan Allen notifications@github.com:

downgrade it to 1.7.21 for thie point release?

Sounds like a wise plan. We should verify that actually solves the problem. Is there any other reason we need 1.7.22 (security?)

(Still thinking though that as from 1.6.0 we should bundle 9k as the default).

That's a certainty.

— Reply to this email directly or view it on GitHub.

mojavelinux commented 8 years ago

I am a bit reluctant to jump on JRuby 9000 with a 1.5.3 release because it also means that we raise the runtime requirements from Java 6 to 7.

Agreed. It's definitely a 1.6.0 thing. But we can still recommend to users that they use JRuby 9000 by setting the dependency explicitly.

mojavelinux commented 8 years ago

If it's packaged in a jar, it fails.

Crazy! But keep in mind, we never released AsciidoctorJ Diagram before, so this could be the first time we're evening trying to run it. That could be why it surprised us.

johncarl81 commented 8 years ago

I am seeing a similar error when I try to execute asciidoctorj-pdf on a windows system through Cygwin (#402: the same code executed on a linux system):

$ java -jar adt.jar
io/console not supported; tty will not be manipulated
Exception in thread "main" org.jruby.exceptions.RaiseException: (Errno::ENOENT) C:\...\adt.jar!\gems\asciidoctor-pdf-1.5.0.alpha.10\lib\asciidoctor-pdf.rb
        at org.jruby.RubyFile.realpath(org/jruby/RubyFile.java:840)
        at RUBY.require_relative(file:/c:/.../asciiDoctorTest-1.0.0-SNAPSHOT-jar-with-dependencies.jar!/jruby/kernel19/kernel.rb:11)
        at RUBY.(root)(c:/.../asciiDoctorTest-1.0.0-SNAPSHOT-jar-with-dependencies.jar!/gems/asciidoctor-pdf-1.5.0.alpha.10/lib/asciidoctor-pdf.rb:2)
        at org.jruby.RubyKernel.require(org/jruby/RubyKernel.java:1040)
        at RUBY.(root)(/c:/.../asciiDoctorTest-1.0.0-SNAPSHOT-jar-with-dependencies.jar!/META-INF/jruby.home/lib/ruby/shared/rubygems/core_ext/kernel_require.rb:1)
        at RUBY.require(/c:/.../asciiDoctorTest-1.0.0-SNAPSHOT-jar-with-dependencies.jar!/META-INF/jruby.home/lib/ruby/shared/rubygems/core_ext/kernel_require.rb:128)

I am also packaging this in a fat-jar... I will try it in an unpackaged jar and see if it doesn't fail.

ysb33r commented 8 years ago

@johncarl81 If you packaged the fat jar with jruby-gradle, it is worth discussing this on Gitter on loggin and issue with the jruby-gradle project.

robertpanzer commented 8 years ago

Ok, this looks similar. Would be great if you could override JRuby to 1.7.21.

Am 03.11.2015 um 22:39 schrieb John Ericksen notifications@github.com:

I am seeing a similar error when I try to execute asciidoctorj-pdf on a windows system through Cygwin (#402: the same code executed on a linux system):

$ java -jar adt.jar io/console not supported; tty will not be manipulated Exception in thread "main" org.jruby.exceptions.RaiseException: (Errno::ENOENT) C:...\adt.jar!\gems\asciidoctor-pdf-1.5.0.alpha.10\lib\asciidoctor-pdf.rb at org.jruby.RubyFile.realpath(org/jruby/RubyFile.java:840) at RUBY.require_relative(file:/c:/.../asciiDoctorTest-1.0.0-SNAPSHOT-jar-with-dependencies.jar!/jruby/kernel19/kernel.rb:11) at RUBY.(root)(c:/.../asciiDoctorTest-1.0.0-SNAPSHOT-jar-with-dependencies.jar!/gems/asciidoctor-pdf-1.5.0.alpha.10/lib/asciidoctor-pdf.rb:2) at org.jruby.RubyKernel.require(org/jruby/RubyKernel.java:1040) at RUBY.(root)(/c:/.../asciiDoctorTest-1.0.0-SNAPSHOT-jar-with-dependencies.jar!/META-INF/jruby.home/lib/ruby/shared/rubygems/core_ext/kernel_require.rb:1) at RUBY.require(/c:/.../asciiDoctorTest-1.0.0-SNAPSHOT-jar-with-dependencies.jar!/META-INF/jruby.home/lib/ruby/shared/rubygems/core_ext/kernel_require.rb:128) I am also packaging this in a fat-jar... I will try it in an unpackaged jar and see if it doesn't fail.

— Reply to this email directly or view it on GitHub.

johncarl81 commented 8 years ago

Downgrading (specifying JRuby) 1.7.21 worked on windows. Interestingly I'm seeing another error in linux (posting in #402)

johncarl81 commented 8 years ago

@ysb33r, I am using maven's assembly plugin to build the fat-jar.

atomfrede commented 8 years ago

Same problem here (WIndows 8), looks like this JRuby issue still exists: https://github.com/jruby/jruby/issues/2944

mojavelinux commented 8 years ago

Thanks for finding that reference, @atomfrede!

robertpanzer commented 8 years ago

Seems like I have to play around with different JRuby versions. At least the crash was only reproducible on my machine with 1.7.22.

atomfrede commented 8 years ago

I updated jruby to 9.0.3.0 for my buildscript, still not working, different error: (LoadError) libraryjava' could not be loaded: java.lang.NoSuchMethodError: org.jruby.util.ByteList.realSize()I`

mojavelinux commented 8 years ago

Could you turn on stacktraces so we can see where that's getting triggered?

robertpanzer commented 8 years ago

Rendering also crashes with asciidoctor-diagram 1.3.1 on Win with JRuby 1.7.22. But runs with 1.7.21. Cannot reproduce the other errors yet.

Also works with 9.0.3.0 on my machine (Win7 Enterprise) (I know, "works on my machine" is a no-no...)

mojavelinux commented 8 years ago

Also works with 9.0.3.0 on my machine (Win7 Enterprise)

The real key will be getting this to happen on AppVeyor. Though, before you try that, it's probably best to understand what triggers the errors or otherwise you'll be waiting for builds for hours :)

ysb33r commented 8 years ago

The real key will be getting this to happen on AppVeyor. Though, before you try that, it's probably best to understand what triggers the errors or otherwise you'll be waiting for builds for hours :

I remember a previous time where we could not reproduce the error on Appveyor at all, but relatively easy with a modern.ie image. I still don't know enough about Appveyor Windows images to explain that.

mojavelinux commented 8 years ago

I still don't know enough about Appveyor Windows images to explain that.

Very likely differences in Windows itself. Unfortunately, we can't run Win7 on AppVeyor, only Windows Server.

atomfrede commented 8 years ago

@mojavelinux My stacktrace:

org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':abc'.
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:69)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:46)
        at org.gradle.api.internal.tasks.execution.PostExecutionAnalysisTaskExecuter.execute(PostExecutionAnalysisTaskExecuter.java:35)
        at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:64)
        at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:58)
        at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:52)
        at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:52)
        at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:53)
        at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
        at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:203)
        at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:185)
        at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.processTask(AbstractTaskPlanExecutor.java:62)
        at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.run(AbstractTaskPlanExecutor.java:50)
        at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor.process(DefaultTaskPlanExecutor.java:25)
        at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:110)
        at org.gradle.execution.SelectedTaskExecutionAction.execute(SelectedTaskExecutionAction.java:37)
        at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:37)
        at org.gradle.execution.DefaultBuildExecuter.access$000(DefaultBuildExecuter.java:23)
        at org.gradle.execution.DefaultBuildExecuter$1.proceed(DefaultBuildExecuter.java:43)
        at org.gradle.execution.DryRunBuildExecutionAction.execute(DryRunBuildExecutionAction.java:32)
        at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:37)
        at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:30)
        at org.gradle.initialization.DefaultGradleLauncher$4.run(DefaultGradleLauncher.java:158)
        at org.gradle.internal.Factories$1.create(Factories.java:22)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:90)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:52)
        at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:155)
        at org.gradle.initialization.DefaultGradleLauncher.access$200(DefaultGradleLauncher.java:36)
        at org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:103)
        at org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:97)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:90)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:62)
        at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:97)
        at org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:86)
        at org.gradle.launcher.exec.InProcessBuildActionExecuter$DefaultBuildController.run(InProcessBuildActionExecuter.java:102)
        at org.gradle.tooling.internal.provider.ExecuteBuildActionRunner.run(ExecuteBuildActionRunner.java:28)
        at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35)
        at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:47)
        at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:32)
        at org.gradle.launcher.exec.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:77)
        at org.gradle.launcher.exec.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:47)
        at org.gradle.launcher.exec.DaemonUsageSuggestingBuildActionExecuter.execute(DaemonUsageSuggestingBuildActionExecuter.java:51)
        at org.gradle.launcher.exec.DaemonUsageSuggestingBuildActionExecuter.execute(DaemonUsageSuggestingBuildActionExecuter.java:28)
        at org.gradle.launcher.cli.RunBuildAction.run(RunBuildAction.java:43)
        at org.gradle.internal.Actions$RunnableActionAdapter.execute(Actions.java:170)
        at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:237)
        at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:210)
        at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:35)
        at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:24)
        at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:206)
        at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:169)
        at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33)
        at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22)
        at org.gradle.launcher.Main.doAction(Main.java:33)
        at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45)
        at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:54)
        at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:35)
        at org.gradle.launcher.GradleMain.main(GradleMain.java:23)
        at org.gradle.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:30)
        at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:129)
        at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:61)
Caused by: org.jruby.exceptions.RaiseException: (LoadError) library `java' could not be loaded: java.lang.NoSuchMethodError: org.jruby.util.ByteList.realSize()I
mojavelinux commented 8 years ago

I wonder if this is the "compiled with Java 8, running with Java 7" error. It seems really strange that it wouldn't be able to find a core JRuby type.

robertpanzer commented 8 years ago

Using asciidoctorj-diagram on Win 10 also fails with JRuby 1.7.22. So I think the decision to go back to 1.7.21 is correct.

Nevertheless I also see this warning with 1.7.21:

io/console not supported; tty will not be manipulated
mojavelinux commented 8 years ago

As long as it's just a warning, we shouldn't worry about it too much. But if it causes a failure down the line, then of course it's a real concern.

robertpanzer commented 8 years ago

Fixed by going down to JRuby 1.7.21

mojavelinux commented 8 years ago

+1 !

robertpanzer commented 8 years ago

Filed issue https://github.com/jruby/jruby/issues/3466 for this problem.

robertpanzer commented 8 years ago

asciidoctorj-diagram works with the last release jruby 1.7.23. But now asciidoctorj-pdf fails: https://github.com/jruby/jruby/issues/3496

mkristian commented 8 years ago

we have no CI for windows for jruby, so it looks any windows fix we have another regression somewhere. jruby-9k works better because it does not use those jar-url paths and goes through the classloader instead which does not need to handle OS specific paths at all !!!

so best would be to set GEM_PATH to uri:classloader:// and GEM_HOME to uri:classloader://META-INF/jruby.home/lib/ruby/gems/shared because:

assuming you guys use jruby-gradle-plugin to embed those gems into the jar: unfortunately the current version of the jruby-gradle-plugin does not produce a jar which works on jruby-1.7 due to https://github.com/jruby-gradle/jruby-gradle-plugin/issues/258 this last issue also means that the asciidoctor jar will not work with jruby-9k inside (some or most) OSGi setups.

robertpanzer commented 8 years ago

We actually only use the Base plugin (http://jruby-gradle.org/base/) as the Jar plugin does not exactly do what we want. Also see the discussion in https://github.com/asciidoctor/asciidoctorj/issues/375 So we only use the Base plugin to "install" the gems and then package the exploded content ourselves into the jars.

ysb33r commented 8 years ago

? We actually only use the Base plugin (http://jruby-gradle.org/base/) as the Jar plugin does not exactly do what we want. Also see the discussion in #375 So we only use the Base plugin to "install" the gems and then package the exploded content ourselves into the jars.

The JRubyJar stuff have changed a lot. I have been meaning to look at upgrading the 1.6.0 build to see if the new jruby-gradle functionality works for asciidoctor as I would have hoped.

mkristian commented 8 years ago

oh - I see. the jar-plugin is far from useful for asciidoctorj :(

happy to help here to get it working here.

robertpanzer commented 8 years ago

It would be great if we could use that! I spent some hours trying to migrate our build to the Jar plugin and always found a full exploded jruby library inside the created jars. Maybe I've done something wrong, so if you could help to get it running that would be just awesome. I wrote my issues down here: https://github.com/asciidoctor/asciidoctorj/issues/375#issuecomment-129458813

mojavelinux commented 8 years ago

we have no CI for windows for jruby

Why not setup AppVeyor. It's just as easy to get setup as Travis CI. We use it for AsciidoctorJ. It doesn't catch everything, but it at least gives us some idea of what to expect.

mkristian commented 8 years ago

@mojavelinux AppVeyor is actually on its way but there are tons of tests which will not work on windows and needs to be excluded and probably loads to work to get test parity between windows and *nix

mojavelinux commented 8 years ago

Understood.

ysb33r commented 8 years ago

I wrote my issues down here: #375 (comment)

Can you assign #375 to me? I might be able to see if we can do something about it at the #GGX hackergarten.