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
    @robertpanzer will see if I can reduce the failing tests to something more simple. (And yes I'm using the jruby registry).
    Schalk W. Cronjé
    @ysb33r
    @robertpanzer Do we have newer builds of PDF, EPUb as well? Currently I am seeing
    Unable to activate asciidoctor-epub3-1.5.0.alpha.8, because asciidoctor-2.0.2 conflicts with asciidoctor (~> 1.5.0)
    Robert Panzer
    @robertpanzer
    But PDF should work, right? At least we have some integration tests for that. @mojavelinux Do you have plans for making a release of EPUB that is compatible with asciidoctor 2.0.0?
    Schalk W. Cronjé
    @ysb33r
    Yes, PDF integration tests are passing.
    Dan Allen
    @mojavelinux
    oh, I didn't realize Asciidoctor EPUB3 was pinned at 1.5.x. Yeah, I can do a release that lifts that requirement.
    Schalk W. Cronjé
    @ysb33r
    Added issue asciidoctor/asciidoctorj-epub3#1 for that
    Dan Allen
    @mojavelinux
    :+1:
    Dan Allen
    @mojavelinux
    I ran out of hours to get Asciidoctor EPUB3 published. I'll make sure I get to it in the next 24 hours. If not, just keep prodding me.
    Schalk W. Cronjé
    @ysb33r
    :point_up: @mojavelinux @robertpanzer I can confirm that the new EPUB jar works with asciidoctor 2.0.0-RC.2
    So it looks that my RC.2 integrations with Gradle are now blocked by compiled extensions (not Groovy DSL). The extensions compiles OK, but are not picked up by Asciidoctorj on the classpath.
    (Note that the same test works with Asciidoctorj 1.6).
    Schalk W. Cronjé
    @ysb33r
    @robertpanzer I can see the extensions.jar is on the classpath and it contains a class CaseChange.class which is the registry class as defined by META-INF/services/org.asciidoctor.extension.spi.ExtensionRegistry. So has there been any chances in the way extensiosn have to be registered?
    Robert Panzer
    @robertpanzer
    The name of the interface ExtensionRegistry was moved to a new package, therefore you have to rename the file under META-INF/services. Like here: https://github.com/asciidoctor/asciidoctorj/tree/master/asciidoctorj-core/src/test/resources/serviceloadertest/1/META-INF/services ie it has moved to org.asciidoctor.jruby.extension.spi.ExtensionRegistry
    Dan Allen
    @mojavelinux
    you might want to call attention to that at the top of the docs or in some sort of migration section or page. could save you from answering a lot of questions.
    Robert Panzer
    @robertpanzer
    Yes, I’ll add that to the migration guide. I see that this is really evil, but it was necessary to split packages for the module system.
    Schalk W. Cronjé
    @ysb33r
    Ah thanks @robertpanzer

    you might want to call attention to that at the top of the docs or in some sort of migration section or page. could save you from answering a lot of questions.

    Haha, that is why I am the unofficial alpha tester on asciidoctorj.

    Dan Allen
    @mojavelinux
    a necessary evil, i'd say. as long as we documented it well, then it's a positive thing
    Abel Salgado Romero
    @abelsromero
    I assume this is part of this PR right? asciidoctor/asciidoctorj#792
    need to address 1.6 -> 2.0 stuff
    Schalk W. Cronjé
    @ysb33r

    @robertpanzer Gradle plugin has achieved full integration with 2.0.0-RC.2.

    An upgrade will touch at least 20 files and we would have to release as 3.0.0 due to the binary incompatibilities. There are quite a number of feastures I might want to add to 3.0.0 as well so it might take time before we get there.

    Robert Panzer
    @robertpanzer
    :+1:
    Schalk W. Cronjé
    @ysb33r
    @robertpanzer Do you have a rough timeline as to when you think the final 2.0 can get released?
    Robert Panzer
    @robertpanzer
    Except for providing logger support for converters I don't have much additional features on my list. For this I have no real inspiration yet how to go for it. If we leave this out I could do a release sooner than later.
    I am not sure though if we want/need to make further changes to the API before the release. And I would like to avoid doing a 3.0.0 this year.
    Dan Allen
    @mojavelinux
    i'll give you the same advice I gave to Guillaume. Just go for it. Switching to semver makes releasing so much less complicated that you can just correct problems as you go (fix forward, so to speak)

    I would like to avoid doing a 3.0.0 this year.

    we must get out of this mindset of emotional attachment to version numbers. that's one of the main reasons we're making this switch. a major version can and should happen when a change calls for it to happen. in other words, the situation decides, not us. if we try to map out when we have major versions, then we end up violating semver (often in creative ways).

    Robert Panzer
    @robertpanzer
    OK, then I'll go for it and try to do an Easter release :)
    Stefan
    @stefanwendelmann
    "Fail fast learn quick"
    Schalk W. Cronjé
    @ysb33r

    @robertpanzer Apologies for the confusion. With 3.0.0 I meant the gradle plugin will have to go to that version in order to accommodate asciidoctorj-2.0.0.

    When we released one of the 1.5.x versions of the Gradle plugins, I made asciidoctorj-1.6 the default in that and got a lot of flack from one of the well-known users in the community. So I had to roll back and release a 1.6 version of the gradle plugin just with the new asciidoctorj version. So this time I want to avoid that and just straight to a next bick number due to all of the API incompatibilities between asciidcotorj-1.6 and asciidoctorj-2.0.

    Robert Panzer
    @robertpanzer
    This is also a thing I want to look at before releasing: asciidoctor/asciidoctorj#790
    Schalk W. Cronjé
    @ysb33r

    Except for providing logger support for converters I don't have much additional features on my list. For this I have no real inspiration yet how to go for it. If we leave this out I could do a release sooner than later.

    @robertpanzer I would assume not to be fancy about it, but simply expose some form of Logger interface instance that converters can obtain by calling getLogger() on the Converter interface. For a start the object returned can simply be a noop logger.

    Robert Panzer
    @robertpanzer
    The thing is that the logger is coupled to the Asciidoctor instance. Therefore I would need some way to inject the current Asciidoctor instance and add some base class to converters that would allow to swap out implementations, similar to what we have right now with Extensions
    Schalk W. Cronjé
    @ysb33r
    Personally I think it is worth delaying the release to get this functionality in there.
    Robert Panzer
    @robertpanzer
    One approach could be to only offer this to subclasses of AbstractConverter. Converters that only implement the interface Converter would be left out then. That could work. I'd like to avoid requiring methods like setAsciidoctor() or setDelegate() to the interface. Too bad Java doesn't have traits
    Schalk W. Cronjé
    @ysb33r

    I am thinking off-the-cuff now as I did not look inside the implementation, but when the converter is registered via SPI, there is a Asciidoctor instance that is passed down. If you add a default method to the Converter instance setLogger(Logger), a converter can choose to implement that. The during registration of the converter, you can work out something to call Converter.setLogger at that point.

    What I like about the API is that it already has LogHandler and LogRecord. Although that was designed for acting on logged events, it can also be applied in reverse. Alternatively what about making an instance of something available that can create LogRecord and submit them. This instance can then be injected into a converter via @Inject on a field or a c-tor.

    Robert Panzer
    @robertpanzer
    I created a proposal for logging support for converters here: asciidoctor/asciidoctorj#801
    Robert Panzer
    @robertpanzer
    I guess it's time to build the AsciidoctorJ 2.0.0 release. Any objections?
    Schalk W. Cronjé
    @ysb33r
    Was going to ask whether it includes pluggable source highlighter API.
    Robert Panzer
    @robertpanzer
    No, that's not in yet. Unfortunately I didn't find the time yet for this
    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.