copycss attribute causes exception in asciidoctor-java-integration

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

copycss attribute causes exception in asciidoctor-java-integration

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: copycss attribute causes exception in asciidoctor-java-integration

mojavelinux
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

--
Sent from my CyanogenMod-powered
Android device, an open platform for
carriers, developers and consumers.

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

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





If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/copycss-attribute-causes-exception-in-asciidoctor-java-integration-tp179.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: copycss attribute causes exception in asciidoctor-java-integration

LightGuardjp
Administrator
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:

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

--
Sent from my CyanogenMod-powered
Android device, an open platform for
carriers, developers and consumers.

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

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





If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/copycss-attribute-causes-exception-in-asciidoctor-java-integration-tp179.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML



If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/copycss-attribute-causes-exception-in-asciidoctor-java-integration-tp179p180.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: copycss attribute causes exception in asciidoctor-java-integration

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: copycss attribute causes exception in asciidoctor-java-integration

mojavelinux
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:

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.




If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/copycss-attribute-causes-exception-in-asciidoctor-java-integration-tp179p182.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML



--
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: copycss attribute causes exception in asciidoctor-java-integration

asotobu
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: copycss attribute causes exception in asciidoctor-java-integration

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


If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/copycss-attribute-causes-exception-in-asciidoctor-java-integration-tp179p204.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML



--
Loading...