copycss attribute causes exception in asciidoctor-java-integration
Locked
 
|
Issue related with this topic is : https://github.com/asciidoctor/asciidoctor-java-integration/issues/21
I'm using the Gradle plugin for Asciidoctor and tried to use the copycss attribute as it seems the easiest way to get hold of the stylesheet. But the attribute results in the exception at the end of this report. I don't think this is a problem with the Gradle plugin but the Java integration. Perhaps JRuby's stat() method can't handle files inside archives? If that's the case, perhaps the JARs need unpacking first? Caused by: org.jruby.exceptions.RaiseException: (Errno::ENOENT) /Users/pledbrook/dev/tools/ratpack/ratpack-docs/jar:file:/Users/pledbrook/.gradle/caches/artifacts-23/filestore/org.asciidoctor/asciidoctor-java-integration/0.1.2/jar/34e5c3a38e59337da992243afb25185c56462866/asciidoctor-java-integration-0.1.2.jar!/gems/asciidoctor-0.1.2/stylesheets/asciidoctor.css at org.jruby.RubyFile.stat(org/jruby/RubyFile.java:810) at RUBY.fu_each_src_dest(jar:file:/Users/pledbrook/.gradle/caches/artifacts-23/filestore/org.jruby/jruby-complete/1.7.3/jar/2273e4c2a2abdd4b25a21bc513bfc05cfba31f3b/jruby-complete-1.7.3.jar!/META-INF/jruby.home/lib/ruby/1.9/fileutils.rb:1524) at RUBY.fu_each_src_dest0(jar:file:/Users/pledbrook/.gradle/caches/artifacts-23/filestore/org.jruby/jruby-complete/1.7.3/jar/2273e4c2a2abdd4b25a21bc513bfc05cfba31f3b/jruby-complete-1.7.3.jar!/META-INF/jruby.home/lib/ruby/1.9/fileutils.rb:1538) at RUBY.fu_each_src_dest(jar:file:/Users/pledbrook/.gradle/caches/artifacts-23/filestore/org.jruby/jruby-complete/1.7.3/jar/2273e4c2a2abdd4b25a21bc513bfc05cfba31f3b/jruby-complete-1.7.3.jar!/META-INF/jruby.home/lib/ruby/1.9/fileutils.rb:1522) at RUBY.cp(jar:file:/Users/pledbrook/.gradle/caches/artifacts-23/filestore/org.jruby/jruby-complete/1.7.3/jar/2273e4c2a2abdd4b25a21bc513bfc05cfba31f3b/jruby-complete-1.7.3.jar!/META-INF/jruby.home/lib/ruby/1.9/fileutils.rb:395) at RUBY.render(jar:file:/Users/pledbrook/.gradle/caches/artifacts-23/filestore/org.asciidoctor/asciidoctor-java-integration/0.1.2/jar/34e5c3a38e59337da992243afb25185c56462866/asciidoctor-java-integration-0.1.2.jar!/gems/asciidoctor-0.1.2/lib/asciidoctor.rb:851) at RUBY.render_file(jar:file:/Users/pledbrook/.gradle/caches/artifacts-23/filestore/org.asciidoctor/asciidoctor-java-integration/0.1.2/jar/34e5c3a38e59337da992243afb25185c56462866/asciidoctor-java-integration-0.1.2.jar!/gems/asciidoctor-0.1.2/lib/asciidoctor.rb:870) at RUBY.render_file(<script>:8) at org.jruby.gen.InterfaceImpl1066952373.render_file(org/jruby/gen/InterfaceImpl1066952373.gen:13) at org.asciidoctor.gradle.AsciidoctorTask$_gititdone_closure1.doCall(AsciidoctorTask.groovy:87) at org.asciidoctor.gradle.AsciidoctorTask.gititdone(AsciidoctorTask.groovy:74) at org.gradle.util.ReflectionUtil.invoke(ReflectionUtil.groovy:23) And the reason is exactly the one the user pointed out. So first of all we can try to find a way that Ruby gems can copy resources from bundled gem to an external directory, maybe there is an option in JRuby ( I will make some research about it), maybe modifying the Ruby part, maybe unpacking jar (so ugly I know). Also keep in mind that for running asciidoctor-java-integration in OSGI, the jars should be uncompressed into a directory because of classloader issues, so unpacking jars could resolve two problems, but I think it creates anothers like startup time, version management, ... |
Re: copycss attribute causes exception in asciidoctor-java-integration
Administrator
|
I admit I failed to consider that scenario when writing the code to handle copying the default stylesheet. There are two ways to handle this, both which involve reading the stylesheet out of the zipped stream. 1. If Asciidoctor is running as a packed gem, and there is some way for Ruby to know that, Asciidoctor can open a reader on its own gem and pull out the file. 2. Java has a much better toolset to locate the compressed file and read files from it with extracting. The Java integration could intercept the copycss setting, not pass it to Asciidoctor, then perform the copy to the destination folder after returning from Asciidoctor. Wdyt? Option #2 seems more viable. -Dan -- On May 4, 2013 2:01 PM, "asotobu [via Asciidoctor :: Discussion]" <[hidden email]> wrote:
Issue related with this topic is : https://github.com/asciidoctor/asciidoctor-java-integration/issues/21 |
Re: copycss attribute causes exception in asciidoctor-java-integration
|
|
I would agree to doing this via #2. It will be easier to do this on the java side. — Sent from Mailbox for iPhone On Sat, May 4, 2013 at 3:06 PM, mojavelinux [via Asciidoctor :: Discussion] <[hidden email]> wrote:
|
|
|
In reply to this post by mojavelinux
Dan suggested in the issue:
After giving it some more thought, I realized there is a third solution. I can put the default CSS into a constant in a Ruby file, then load that Ruby file using require when it is needed and read the value off the constant. ...which brings up another data point when looking into this issue. Somewhere in JRuby (I think in JRubyKernel.java), JRuby is able to read files out of the classpath for the require statement. Thus, there must be some way in Ruby to read the file contents from a file on the LOAD_PATH without evaluating it. Maybe Kernel#open? and I have replied there and now I write here too: Ok, then one idea that I was discarding at first (implementing copycss feature inside java). it seems that would be the best one. I agree that the best way would be trying to read the file from the gem with a method (Kernel#open) could be an option if works. But it comes to my mind one thing: If we add a specific behaviour in one attribute, maybe in future we will add another one, and another one, ... and we can finish by having some logic duplicated in Java and Ruby part. I think this would not be the case, but opens the door to do it again. Of course I think third option could be the best one, but I don't like this duplication. |
Re: copycss attribute causes exception in asciidoctor-java-integration
|
Administrator
|
Alex et al, I've done some thinking about this and I absolutely like the idea of being able to have Asciidoctor pass information about the file it wants to read to the integration layer and allow the integration layer to read it.
For the default stylesheet however, since it's a very special case...at least for now, I'm going to store the content in a string so that there is no need to locate a file to read the content. There are a few reasons for doing it this way...but most importantly it keeps things self contained for handling such a core use case.
Here's the pull request for that change. This will solve the immediate copycss problem in the integration layer...because now we are not reading a file:
When we get into bundles themes and perhaps backends, then we will need to use the integration that Alex is proposing. It's still critical.
-Dan On Sun, May 5, 2013 at 12:34 PM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote: Dan suggested in the issue: Dan Allen | http://google.com/profiles/dan.j.allen |
|
|
Well now I have finished a version which reads from classpath the information, so I think that today I will release a version with that implementation, and then for 0.1.3 version I will remove it, so users that now are blocked because of this issue can continue work.
|
Re: copycss attribute causes exception in asciidoctor-java-integration
|
Administrator
|
Sounds perfect! That's exactly the strategy we want to take here. Users should see smooth seas while we wrestle classpaths and file paths underwater :)
I'm excited that you worked out how to read from the classpath because we are *definitely* going to be needing that as we get deeper into things. Solid work!
-Dan On Thu, May 16, 2013 at 12:23 AM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote: Well now I have finished a version which reads from classpath the information, so I think that today I will release a version with that implementation, and then for 0.1.3 version I will remove it, so users that now are blocked because of this issue can continue work. Dan Allen | http://google.com/profiles/dan.j.allen
|
«
Return to Asciidoctor :: Discussion
|
1 view|%1 views
| Free forum by Nabble | Edit this page |