Next steps for AsciidoctorJ

Alex et al,

There are two important changes we are currently scheduling in AsciidoctorJ:

* Distributing AsciidoctorJ PDF and AsciidoctorJ EPUB3 jars

* Pluggable Asciidoctor implementation (JRuby and Nashorn)

I know we really want to get the pluggable Asciidoctor implementation integrated and released, but I think that the request from the community to produce jars for AsciidoctorJ PDF and AsciidoctorJ EPUB3 is more urgent. I've given some thought about how to proceed and I've come up with a proposal.

My proposal is to perform the work of reorganizing the AsciidoctorJ repository in two discrete phases.

Phase #1::

  Convert the current single-module build to a multi-module build that is capable of building & distributing jars for asciidoctorj, asciidoctorj-pdf and asciidoctor-epub3 (maybe asciidoctorj-diagram too).

  To avoid sinking more time & effort into the Maven build, I think we should also switch to Gradle at this point.

  Switching to Gradle also allows us to leverage the JRuby Gradle plugin, which is much more capable of doing what we need to do than the Maven support.

Phase #2::

  Split the core module into an API and multiple implementations (asciidoctorj-api, asciidoctorj-jruby, asciidoctorj-nashorn).

NOTE: After phase #2 is complete, we can still produce an asciidoctorj jar that combines the asciidoctorj-api and asciidoctorj-jruby for backward compatibility and convenience.

I think we should complete Phase #1 for the AsciidoctorJ 1.5.2 release.

I thought about whether we should keep the PDF and EPUB3 modules inside the AsciidoctorJ repository or split them out as individual repositories. What I concluded is that splitting them out would be too much administrative overhead for right now. Instead, we can release these components when we release AsciidoctorJ, using the gem versions available at the time. If we need to make an interim release of a component (e.g., asciidoctorj-pdf), we can create a dedicated tag for that upgrade and release only that component out of the repository. Gradle affords us this flexibility, which is one of the key reasons I want to switch to it now.

To summarize, I consider it imperative to get a jar for Asciidoctor PDF released as part of the AsciidoctorJ 1.5.2 release. I believe that my proposal gives us a way to make that happen. I'm thinking Phase #2 would then be most appropriate for the AsciidoctorJ 1.6.0 release.

I'm interested to hear your feedback about this plan.

Cheers,

-Dan

p.s. Another reason to be more patient about the Nashorn support is that it can't be used until JDK 8u40 is released anyway (due to bugs we found in Nashorn, which are now fixed in the EA builds).

--

Dan Allen | http://google.com/profiles/dan.j.allen

---

If you reply to this email, your message will be added to the discussion below:

http://discuss.asciidoctor.org/Next-steps-for-AsciidoctorJ-tp2488.html

To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML

+1 for this roadmap.

Though I don't see the urge to switch to a gradle build too quickly. (I admit that I feel pretty comfortable with Maven :-) )
 What feature exactly do you have in mine when you mention the ruby gradle plugin?

Dominik

---

If you reply to this email, your message will be added to the discussion below:

http://discuss.asciidoctor.org/Next-steps-for-AsciidoctorJ-tp2488p2493.html

To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML