CaseChange.classwhich 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?
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.
@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.
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).
@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.
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.
Converterwould be left out then. That could work. I'd like to avoid requiring methods like
setDelegate()to the interface. Too bad Java doesn't have traits
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
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
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.