Closed robertpanzer closed 8 years ago
Problem does also not occur on OS X.
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).
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
@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.
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.
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 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).
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.
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.
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.
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.
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.
@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.
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.
Downgrading (specifying JRuby) 1.7.21 worked on windows. Interestingly I'm seeing another error in linux (posting in #402)
@ysb33r, I am using maven's assembly plugin to build the fat-jar.
Same problem here (WIndows 8), looks like this JRuby issue still exists: https://github.com/jruby/jruby/issues/2944
Thanks for finding that reference, @atomfrede!
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.
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`
Could you turn on stacktraces so we can see where that's getting triggered?
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...)
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 :)
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.
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.
@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
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.
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
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.
Fixed by going down to JRuby 1.7.21
+1 !
Filed issue https://github.com/jruby/jruby/issues/3466 for this problem.
asciidoctorj-diagram works with the last release jruby 1.7.23. But now asciidoctorj-pdf fails: https://github.com/jruby/jruby/issues/3496
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.
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.
? 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.
oh - I see. the jar-plugin is far from useful for asciidoctorj :(
happy to help here to get it working here.
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
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.
@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
Understood.
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.
When trying to render the test document from the asciidoctorj-diagram on Win7 via the distribution rendering fails with an exception:
So what actually fails is this line in
blockdiag.rb
:But a
version.rb
exists next to theblockdiag.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...