AsciidoctorJ 1.X.Y and beyond with AsciidoctorJs

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

AsciidoctorJ 1.X.Y and beyond with AsciidoctorJs

asotobu
Hi guys,

I have just created a branch of AsciidoctorJ project to start the migration to Java 8 (for using Nashorn and allow users render documents using asciidoctor.js from Java instead of JRuby).

The link is here: https://github.com/lordofthejars/asciidoctorj/tree/feature_189

Let me summarize some changes:

pom.xml now uses 1.8 compile version

Now Asciidoctor is not an interface but a class (https://github.com/lordofthejars/asciidoctorj/blob/feature_189/src/main/java/org/asciidoctor/Asciidoctor.java). This class implements all operations that users may use independently of render method (JRuby or Nashorn). For example methods like convertDirectory, convertFiles, convertFile and so on fall in this class. This class has an attribute of type AsciidoctorJ (https://github.com/lordofthejars/asciidoctorj/blob/feature_189/src/main/java/org/asciidoctor/internal/AsciidoctorJ.java) This is an interface which is not intend to be used by final users. It implements basic operations like load, convert, convertFile, or registering extensions. Then the key point is that JRuby implementation implements this interface (https://github.com/lordofthejars/asciidoctorj/blob/feature_189/src/main/java/org/asciidoctor/internal/RubyAsciidoctorJ.java), Javascript implementation will implement this interface as well, so effectively only implementing 10 methods you will have AsciidoctorJ rendering documents in another system.

One thing that may look strange is this method:

 <T extends ExtensionRegistry> T create(final Class<T> type) throws IllegalArgumentException;

If you look current AsciidoctorJ extension mechanism you can get two different objects JavaExtensionRegistry and RubyExtensionRegistry. The first one is used to register extensions written in Java and the second one for extensions written in Ruby. But for example both of them only works if you are using JRuby (some logic is done behind the scene). So what's happen with JavaScript? You will be able to write extensions in Javascript and in Java (but using Nashorn and not JRuby) so we need a generic way to create this classes. This method is generic enough to fit this requirement. (https://github.com/lordofthejars/asciidoctorj/blob/feature_189/src/main/java/org/asciidoctor/internal/RubyAsciidoctorJ.java#L207)

If you download the code you will see that tests does not compile. Why? Because there are some breaks on method contracts. Before fixing this problems I prefer to start a feedback round so when we definitely have a final contract where everybody feels comfortable then I will fix them.

This issue is only about  integration with AsciidoctorJs and the modifications I need to insert into the code. I will open more rounds to talk about other problems we might target to fix like FunctionalInterfaces or Symbols.

Thank you very much for your collaboration. Feel free to clone the project, do PR or comment this post. Meanwhile I will start the first prototype of AsciidoctorJs inside Nashorn.

Alex.


Reply | Threaded
Open this post in threaded view
|

Re: AsciidoctorJ 1.X.Y and beyond with AsciidoctorJs

domgold
Hi Alex

I like the idea of having two different asciidoctor implementations on the jvm. The js approach seems to be less complicated, avoiding all the gem stuff etc.

You say you update to Java 1.8. Does this mean that we won't be able to use AsciidoctorJ in 1.6 code?

I see that the upgrade to 1.8 is necessary to support AsciidoctorJS via Nashorn.
Would it be possible having the js implementation in a separate module and include it as a dependency inside AsciidoctorJ? This way AsciidoctorJ itself would still be Java 1.6 and we could still use the JRuby version in 1.6 by simply excluding the AsciidoctorJS dependency.

More generally spoken, I think AsciidoctorJ would benefit from being broken into different modules:
* asciidoctorj-api/ast
* asciidoctorj-jruby
* asciidoctorj-js
* asciidoctorj

(Another side effect: people who only want to use the js version can just exclude the asciidoctor-jruby dependency and avoid polluting their dependency tree with dependencies they'll never use.)

If you think this is a good idea, I might be able to find some time to provide a first modularized version.

Dominik
Reply | Threaded
Open this post in threaded view
|

Re: AsciidoctorJ 1.X.Y and beyond with AsciidoctorJs

asotobu
Hi Dominik,

these changes is something I have in mind til 0.1.4 version so I am happy that we agree on the approach. Currently before splitting the project, I prefer to maintain all in one, do the first full approach, and when we know exactly which parts can be moved in each module then refactor the project. So give me some time to finish the first approach and then if you want we can start work together on this split :).

I think that instead of asciidoctorj-api we can call it asciidoctorj-core but well it is only a name, we can discuss lately. Moreover I think that instead of calling asciidoctorj-js we can create asciidoctorj-nashorn,  asciidoctorj-dynjs and for example asciidoctorj-rhino, and of course asciidoctorj-jruby and asciidoctor-jruby9000. In this way any user will be able to import the implementation they think it may require. Also we can see if every module can be compiled with different version of compiler so for example core can be compiled in Java 6 and nashorn with Java 8.

Well let's see the best way to do it but for now I think that the best way to do it is by finishing the first prototype and see how it looks.

WDYT?
Reply | Threaded
Open this post in threaded view
|

Re: AsciidoctorJ 1.X.Y and beyond with AsciidoctorJs

asotobu
Any thoughts on this Dan? BTW will be asciidoctor.js uploaded to webjars?
Reply | Threaded
Open this post in threaded view
|

Re: AsciidoctorJ 1.X.Y and beyond with AsciidoctorJs

ysb33r
Webjars will be realy useful when using the gradle & maven plugins for asciidoctorj.
Reply | Threaded
Open this post in threaded view
|

Re: AsciidoctorJ 1.X.Y and beyond with AsciidoctorJs

mojavelinux
Administrator
In reply to this post by asotobu
Alex et al,

I'm really excited about this change and the integration of Asciidoctor.js.

> Now Asciidoctor is not an interface but a class. This class implements all operations that users may use independently of convert method.

Excellent! I would also like to see this method added to the Asciidoctor class

Asciidoctor.require(String libraryName)

Users shouldn't have to use the RubyUtils internal class for this step.

I agree that we should splits AsciidoctorJ into multiple modules as soon as it's convenient. I like the names asciidoctorj-common or asciidoctorj-shared for the common module and, naturally, the implementation-specific names for the rest. I think that only asciidoctorj-nashorn needs to require JDK 1.8. We don't want to scare away our loyal users :) For the rest, 1.6 (or 1.7) is more ideal.

Having said that, I think we can maintain an asciidoctorj module that allows folks to migrate without changing any dependencies. The asciidoctorj module would simply depend on asciidoctorj-jruby and, in turn, asciidoctorj-shared. That way, the most common use cases can still have just a single dependency (we could even make a shaded jar file that has the same contents as the asciidoctorj jar has today).

I also think it's time to split out the epub3 and pdf backends into separate jar files as well. This allows AsciidoctorJ to mirror the packaging on the Ruby side. For right now, these will be focused only on the Ruby implementation since we don't have (nor have we figured out) how to make them in JavaScript. The pdf backend in particular adds almost *11 MB* of gems, so we definitely don't want to bundle those into a single AsciidoctorJ jar file.

.Putting Asciidoctor.js in perspective
****
While many of us are excited about the opportunity to use Asciidoctor.js on the JVM, don't discount the JRuby implementation to quickly as a user. It's unlikely that the JavaScript implementation will ever threaten the Ruby implementation in terms of speed (at least not soon). There are two reasons for this. First, JRuby is incredibly fast on the JVM, faster than any Ruby implementation outside the JVM, in fact. The other reason is that Asciidoctor.js is trancompiled from the Ruby implementation, so it does a lot of extra work to delegate method calls that the Ruby implementation is not doing. I definitely think that Asciidoctor.js will have lots of important uses, but don't be disappointed if it's a little slower...that's to be expected.
****

Great work Alex!!

-Dan

On Mon, Sep 1, 2014 at 12:59 AM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote:
Hi Dominik,

these changes is something I have in mind til 0.1.4 version so I am happy that we agree on the approach. Currently before splitting the project, I prefer to maintain all in one, do the first full approach, and when we know exactly which parts can be moved in each module then refactor the project. So give me some time to finish the first approach and then if you want we can start work together on this split :).

I think that instead of asciidoctorj-api we can call it asciidoctorj-core but well it is only a name, we can discuss lately. Moreover I think that instead of calling asciidoctorj-js we can create asciidoctorj-nashorn,  asciidoctorj-dynjs and for example asciidoctorj-rhino, and of course asciidoctorj-jruby and asciidoctor-jruby9000. In this way any user will be able to import the implementation they think it may require. Also we can see if every module can be compiled with different version of compiler so for example core can be compiled in Java 6 and nashorn with Java 8.

Well let's see the best way to do it but for now I think that the best way to do it is by finishing the first prototype and see how it looks.

WDYT?


If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/AsciidoctorJ-1-X-Y-and-beyond-with-AsciidoctorJs-tp2090p2096.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
|

Re: AsciidoctorJ 1.X.Y and beyond with AsciidoctorJs

jnorthr
In reply to this post by asotobu
hey alex
do we have any date yet for an alpha version of your a/d js ? am ready to clone & build just for fun !  I have jdk8 installed so just say when !
thx
jim
Reply | Threaded
Open this post in threaded view
|

Re: AsciidoctorJ 1.X.Y and beyond with AsciidoctorJs

asotobu
Well we have found a bug in nashorn so you cannot do a lot of things. now we are waiting for jdk8u40 that it may fixes this. Meanwhile you Can only render strings to html.

I keep you informed
Alex

Enviat des del meu iPhone

El 10/09/2014, a les 18.10, "jnorthr [via Asciidoctor :: Discussion]" <[hidden email]> va escriure:
hey alex
do we have any date yet for an alpha version of your a/d js ? am ready to clone & build just for fun !  I have jdk8 installed so just say when !
thx
jim


If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/AsciidoctorJ-1-X-Y-and-beyond-with-AsciidoctorJs-tp2090p2175.html
To unsubscribe from AsciidoctorJ 1.X.Y and beyond with AsciidoctorJs, click here.
NAML
Reply | Threaded
Open this post in threaded view
|

Re: AsciidoctorJ 1.X.Y and beyond with AsciidoctorJs

mojavelinux
Administrator
Note that you can build from the branch to create the AsciidoctorJ jar file and start toying with it today.

-Dan

On Wed, Sep 10, 2014 at 10:18 AM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote:
Well we have found a bug in nashorn so you cannot do a lot of things. now we are waiting for jdk8u40 that it may fixes this. Meanwhile you Can only render strings to html.

I keep you informed
Alex

Enviat des del meu iPhone

El 10/09/2014, a les 18.10, "jnorthr [via Asciidoctor :: Discussion]" <[hidden email]> va escriure:
hey alex
do we have any date yet for an alpha version of your a/d js ? am ready to clone & build just for fun !  I have jdk8 installed so just say when !
thx
jim


If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/AsciidoctorJ-1-X-Y-and-beyond-with-AsciidoctorJs-tp2090p2175.html
To unsubscribe from AsciidoctorJ 1.X.Y and beyond with AsciidoctorJs, click here.
NAML



If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/AsciidoctorJ-1-X-Y-and-beyond-with-AsciidoctorJs-tp2090p2176.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
|

Re: AsciidoctorJ 1.X.Y and beyond with AsciidoctorJs

jnorthr
In reply to this post by asotobu
well - strings are good too ! at least we can get started being familiar with the bits and pieces.
Reply | Threaded
Open this post in threaded view
|

Re: AsciidoctorJ 1.X.Y and beyond with AsciidoctorJs

asotobu
Yes until bug fixed there will be no extensions in js, no ast parser and some options disabled :)

Enviat des del meu iPhone

El 11/09/2014, a les 12.49, "jnorthr [via Asciidoctor :: Discussion]" <[hidden email]> va escriure:
well - strings are good too ! at least we can get started being familiar with the bits and pieces.


If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/AsciidoctorJ-1-X-Y-and-beyond-with-AsciidoctorJs-tp2090p2189.html
To unsubscribe from AsciidoctorJ 1.X.Y and beyond with AsciidoctorJs, click here.
NAML