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

robertpanzer · 2015-11-03T14:43:31Z

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...

The text was updated successfully, but these errors were encountered:

robertpanzer · 2015-11-03T17:06:37Z

Problem does also not occur on OS X.

ysb33r · 2015-11-03T20:32:59Z

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 · 2015-11-03T20:34:00Z

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. asciidoctor/asciidoctor-diagram@835bcd1

mojavelinux · 2015-11-03T20:35:19Z

@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 · 2015-11-03T20:45:19Z

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 · 2015-11-03T20:54:13Z

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 · 2015-11-03T20:58:05Z

@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 · 2015-11-03T21:00:54Z

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 · 2015-11-03T21:27:58Z

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 [email protected]:

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 · 2015-11-03T21:30:15Z

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 · 2015-11-03T21:30:48Z

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 · 2015-11-03T21:39:14Z

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 · 2015-11-03T21:41:59Z

@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 · 2015-11-03T21:49:14Z

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 [email protected]:

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 · 2015-11-03T22:23:21Z

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

johncarl81 · 2015-11-03T22:54:56Z

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

atomfrede · 2015-11-04T07:24:59Z

Same problem here (WIndows 8), looks like this JRuby issue still exists: jruby/jruby#2944

mojavelinux · 2015-11-04T07:41:57Z

Thanks for finding that reference, @atomfrede!

robertpanzer · 2015-11-04T07:43:16Z

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 · 2015-11-04T07:57:38Z

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

mojavelinux · 2015-11-04T08:10:38Z

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

robertpanzer · 2015-11-04T08:55:17Z

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 · 2015-11-04T09:06:13Z

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 · 2015-11-04T09:19:59Z

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 · 2015-11-04T09:22:15Z

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 · 2015-11-04T09:33:45Z

@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 · 2015-11-04T09:42:54Z

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 · 2015-11-04T18:59:09Z

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 · 2015-11-04T20:52:36Z

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 · 2015-11-05T14:59:34Z

Fixed by going down to JRuby 1.7.21

mojavelinux · 2015-11-05T18:16:03Z

+1 !

robertpanzer · 2015-11-16T11:00:04Z

Filed issue jruby/jruby#3466 for this problem.

robertpanzer · 2015-11-25T14:10:38Z

asciidoctorj-diagram works with the last release jruby 1.7.23.
But now asciidoctorj-pdf fails: jruby/jruby#3496

mkristian · 2015-11-26T14:34:09Z

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:

no user installed gems get used
no rvm or chruby setup get used - both set GEM_PATH and/or GEM_HOME and jruby (or any ruby) just uses those environment variables.

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 jruby-gradle/jruby-gradle-plugin#258
this last issue also means that the asciidoctor jar will not work with jruby-9k inside (some or most) OSGi setups.

robertpanzer · 2015-11-26T15:11:28Z

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.

ysb33r · 2015-11-26T15:15:48Z

? 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 · 2015-11-26T15:28:25Z

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

happy to help here to get it working here.

robertpanzer · 2015-11-26T15:28:33Z

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: #375 (comment)

mojavelinux · 2015-11-26T15:35:04Z

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 · 2015-11-26T15:55:19Z

@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 · 2015-11-26T16:03:06Z

Understood.

ysb33r · 2015-11-26T16:19:07Z

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.

robertpanzer added the bug label Nov 3, 2015

robertpanzer added this to the v1.5.3.2 milestone Nov 3, 2015

robertpanzer added a commit that referenced this issue Nov 4, 2015

Go back to JRuby 1.7.21 due to #401

38c92b9

robertpanzer closed this as completed Nov 5, 2015

robertpanzer mentioned this issue Nov 16, 2015

require_relative fails sometimes with JRuby 1.7.22 on Win7 jruby/jruby#3466

Closed

robertpanzer mentioned this issue Nov 20, 2015

Fixes #405. Adds integration tests to asciidoctorj-distribution. #410

Merged

abelsromero pushed a commit to abelsromero/asciidoctorj that referenced this issue Dec 14, 2016

Go back to JRuby 1.7.21 due to asciidoctor#401

6c5e5d6

fapdash mentioned this issue Jan 18, 2017

Warning "io/console not supported; tty will not be manipulated" occurs again on 1.7.23 jruby/jruby#3550

Closed

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

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

Comments

robertpanzer commented Nov 3, 2015

robertpanzer commented Nov 3, 2015

ysb33r commented Nov 3, 2015

mojavelinux commented Nov 3, 2015

mojavelinux commented Nov 3, 2015

ysb33r commented Nov 3, 2015

mojavelinux commented Nov 3, 2015

ysb33r commented Nov 3, 2015

mojavelinux commented Nov 3, 2015

robertpanzer commented Nov 3, 2015

mojavelinux commented Nov 3, 2015

mojavelinux commented Nov 3, 2015

johncarl81 commented Nov 3, 2015

ysb33r commented Nov 3, 2015

robertpanzer commented Nov 3, 2015

johncarl81 commented Nov 3, 2015

johncarl81 commented Nov 3, 2015

atomfrede commented Nov 4, 2015

mojavelinux commented Nov 4, 2015

robertpanzer commented Nov 4, 2015

atomfrede commented Nov 4, 2015

mojavelinux commented Nov 4, 2015

robertpanzer commented Nov 4, 2015

mojavelinux commented Nov 4, 2015

ysb33r commented Nov 4, 2015

mojavelinux commented Nov 4, 2015

atomfrede commented Nov 4, 2015

mojavelinux commented Nov 4, 2015

robertpanzer commented Nov 4, 2015

mojavelinux commented Nov 4, 2015

robertpanzer commented Nov 5, 2015

mojavelinux commented Nov 5, 2015 via email

robertpanzer commented Nov 16, 2015

robertpanzer commented Nov 25, 2015

mkristian commented Nov 26, 2015

robertpanzer commented Nov 26, 2015

ysb33r commented Nov 26, 2015

mkristian commented Nov 26, 2015

robertpanzer commented Nov 26, 2015

mojavelinux commented Nov 26, 2015

mkristian commented Nov 26, 2015

mojavelinux commented Nov 26, 2015

ysb33r commented Nov 26, 2015