Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Schalk W. Cronjé
    @ysb33r
    Should we wait and rather do that? I'm not sure whether there are people wanting a 2.0
    Well eagerly wanting.
    I would be happy with a couple of rounds of RC releases.
    Robert Panzer
    @robertpanzer
    Sure, we can move that. There's no way though to run Asciidoctor 2.0.x in AsciidoctorJ though
    Schalk W. Cronjé
    @ysb33r
    I thought the new API
    Was based upon 2.0?
    Robert Panzer
    @robertpanzer
    You mean it won't work in Maven or Gradle yet anyway? That's true. But for anyone else who might be embedding it directly it might be nice. However I am fine with any decision. If we think we want this, we can add it first
    I think though that this could be implemented as an addition only without other incompatible changes, so it could also come into a 2.1.0.
    Schalk W. Cronjé
    @ysb33r
    2.0.0 of asciidoctorj will work with 3.0.0 of the Gradle plugin (I have a prototype already). I think Abel will make a release of the Maven plugin one 2.0.0 is released.
    If you think it can be done without breaking APIs I don't have an issue with an earlier release.
    But maybe now that you've done the logger additions an RC.3 might be in order first.
    Robert Panzer
    @robertpanzer
    Similar to Asciidoctor (at least how I currently understand the sources) this could live in parallel to the extensions and would just add another method on the Asciidoctor(J?) class that returns a SourceHighlighterRegistry. Similar to the ExtensionRegistries and ConverterRegistry.
    However, let's wait until we have some more opinions on the timeline.
    Schalk W. Cronjé
    @ysb33r
    Ok. Hey upgrading to trying out RC.3
    Robert Panzer
    @robertpanzer
    asciidoctor/asciidoctorj#805 I assigned it to the 2.0.0 milestone for now.
    Dan Allen
    @mojavelinux
    we can give the RCs a few more days, maybe a week, but we really shouldn't delay too much longer so we all can start living in a post 2.0 world.
    Schalk W. Cronjé
    @ysb33r
    Good news is that the RC.3 integrated without a problem. The good news is that as of today we have a 3.0.0 Gradle plugin that is good to go sometime after asciidoctorj 2.0.0 is released. Still I would like to release a 2.2.0 of the plugin before 3.0.0, so personally I can hang on a while for the release.
    Robert Panzer
    @robertpanzer
    So release AsciidoctorJ 2.0.0 without Java source highlighter? I won’t be able to do it in the next few days, this is definitely a bigger effort for me right now.
    Dan Allen
    @mojavelinux
    @robertpanzer yes, I would agree with that. it's still possible to register a syntax highlighter via Ruby, so it's an enhancement to add it to java...and we'll need time to sort out that API.
    (you might consider bundling rouge to use the built-in support for it)
    Schalk W. Cronjé
    @ysb33r
    @mojavelinux am I correct to assume that coderay will still be bundled? Or will @robertpanzer need to add a bundled GEM for that too?
    Dan Allen
    @mojavelinux
    it's your choice whether to continue bundling coderay or not. at this point, it should be considered deprecated because it's no longer maintained and it's not as good as rouge.
    Schalk W. Cronjé
    @ysb33r
    There is quit a lot of docs out there I suspect that still rely on coderay, so it will probably be better for it to be bundled for now. Maybe we can add a message somewhere in asciidoctor or asciidoctorj that says coderay is deprecated should it detect it being set as the the source highlighter.
    Dan Allen
    @mojavelinux
    i don't think we want anything in core since technically all syntax highlighters are valid
    but when we remove it from core (in 3.0) and move it to a plugin, then it will warn that there is no syntax highlighter (just like if you typed foobar)
    Robert Panzer
    @robertpanzer
    I'd prefer to continue bundling both code ray and rouge.
    Robert Panzer
    @robertpanzer
    I guess we came to the agreement that pluggable source highlighters can be added at a later time.
    So is there anything else speaking against making an AsciidoctorJ 2.0.0 release now? Current master has Asciidoctor 2.0.0, Asciidoctor-PDF 1.5.0-alpha.17, and rouge plus coderay.
    Schalk W. Cronjé
    @ysb33r
    :+1:
    Robert Panzer
    @robertpanzer
    And it's out! Maven Central is misbehaving again, but I will retry until pushing there works
    Dan Allen
    @mojavelinux
    @robertpanzer congratulations!!!!!!!!!!!!!!!! :tada: :beers: :rocket:
    it's the dawn of a new era!
    Dan Allen
    @mojavelinux
    I hope you're enjoying a nice big release beer this evening!
    Robert Panzer
    @robertpanzer
    Yes! :) The Firestone Helldorado. I really started linking barley wines a lot :beers:
    Dan Allen
    @mojavelinux
    ooooooooooh. nice.
    and Firestone does them very well (because of their wine heritage)
    I just had my first blended beer from them...their 22 anniversary blend. it was out of this world.
    Schalk W. Cronjé
    @ysb33r

    News on the asciidoctor-gradle 3.x front, I have managed to create an additional plugin that integrates DeckTape to export slides to PDF/JPG/PNG. It can basically convert any HTML slide deck that DeckTape supports and that was created by an Asciidoctor task.

    However, because we already have specific Reveal.js support in the GRadle plugins the integration is even more slick. It will detect the presence of the asciidoctorRevealJs task and allow on-demand creation of asciidoctorRevealJsExport.

    Screenshot_20190513_161350.png
    It can be as slick as the above
    Given that we also now have asciidoctor.js (html & docbook at least) integration into the plugin suite, I think we are near enough to release a 3.0.0-alpha.1 future in the next couple of weeks so that people can have a play.
    Schalk W. Cronjé
    @ysb33r

    I'm really confused about some error that popped up today.

    Running AsciidoctorJ instance with classpath [
      $ROOT/asciidoctor-gradle-jvm/build/libs/asciidoctor-gradle-jvm-3.0.0-alpha.1.jar, 
      $GRADLEHOME/wrapper/dists/gradle-4.4.1-bin/46gopw3g8i1v3zqqx4q949t2x/gradle-4.4.1/lib/groovy-all-2.4.12.jar,
      $ROOT/testfixtures/offline-repo/build/repo/org.asciidoctor/asciidoctorj/2.0.0/asciidoctorj-2.0.0.jar, 
      $ROOT/testfixtures/offline-repo/build/repo/org.jruby/jruby-complete/9.2.7.0/jruby-complete-9.2.7.0.jar, 
      $ROOT/testfixtures/offline-repo/build/repo/org.asciidoctor/asciidoctorj-api/2.0.0/asciidoctorj-api-2.0.0.jar, 
      $ROOT/testfixtures/offline-repo/build/repo/com.beust/jcommander/1.35/jcommander-1.35.jar] 
    
    Starting process 'command '/usr/lib/jvm/java-8-oracle/bin/java''. 
    
    Working directory: $ROOT/asciidoctor-gradle-jvm-gems/build/gradleTest/external-gems/4.4.1 
    
    Command: /usr/lib/jvm/java-8-oracle/bin/java \
      -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant \
      \
      -cp $ROOT/asciidoctor-gradle-jvm/build/libs/asciidoctor-gradle-jvm-3.0.0-alpha.1.jar:\
      $GRADLEHOME/wrapper/dists/gradle-4.4.1-bin/46gopw3g8i1v3zqqx4q949t2x/gradle-4.4.1/lib/groovy-all-2.4.12.jar:\
      $ROOT/testfixtures/offline-repo/build/repo/org.asciidoctor/asciidoctorj/2.0.0/asciidoctorj-2.0.0.jar:\
      $ROOT/testfixtures/offline-repo/build/repo/org.jruby/jruby-complete/9.2.7.0/jruby-complete-9.2.7.0.jar:\
      $ROOT/testfixtures/offline-repo/build/repo/org.asciidoctor/asciidoctorj-api/2.0.0/asciidoctorj-api-2.0.0.jar:\
      $ROOT/testfixtures/offline-repo/build/repo/com.beust/jcommander/1.35/jcommander-1.35.jar \
      org.asciidoctor.gradle.remote.AsciidoctorJavaExec \
      \
      $ROOT/asciidoctor-gradle-jvm-gems/build/gradleTest/external-gems/4.4.1/build/tmp/asciidoctor.javaexec-data
    
      Successfully started process 'command '/usr/lib/jvm/java-8-oracle/bin/java''
    
      Exception in thread "main" org.jruby.exceptions.LoadError: (MissingSpecVersionError) Gem::MissingSpecVersionError
      at RUBY.to_specs(uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/rubygems/dependency.rb:313)
      at RUBY.activate_dependencies(uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/rubygems/specification.rb:1472)
      at org.jruby.RubyArray.each(org/jruby/RubyArray.java:1792)
      at RUBY.activate_dependencies(uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/rubygems/specification.rb:1461)
      at RUBY.activate(uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/rubygems/specification.rb:1443)
      at RUBY.try_activate(uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/rubygems.rb:224)
      at RUBY.require(uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/rubygems/core_ext/kernel_require.rb:123)
      at RUBY.<main>(<script>:1)

    This happens in a test were the asciidoctor-bibtex GEM has been added. Apparantly the issue is due to a GEM on the filesystem not being the one required, but I have no idea how to figure that out.

    Dan Allen
    @mojavelinux
    hmmm
    Schalk W. Cronjé
    @ysb33r
    I have discovered something... I reran a job on CI which was successful previously and now it has failed with the same issue as well. I suspect this is down to Rubygem dependencies having changed.
    And the same test now fails on master as well.
    Dan Allen
    @mojavelinux
    do you think it's a dependency on rubygems itself, or a gem specifically?
    Schalk W. Cronjé
    @ysb33r
    A GEM has changed I think
    Dan Allen
    @mojavelinux
    I wouldn't be surprised. note that rouge was recently released. not sure if that could be it, but I do know it happened last night
    Schalk W. Cronjé
    @ysb33r
    No, that should not affect this as this is asciidoctorj 2.0, should it should have rouge bundled at a set version.
    Stupid ruby question: If a dependency is set at ~> 4, should it resolve anything 4.x, but not 5?