Is it worth refactoring asciidoctor-jruby integration into a shared library?

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

Is it worth refactoring asciidoctor-jruby integration into a shared library?

davide.cavestro
Hi guys,
I've just discovered asciidoctor following Andres Almiray tweets: is it worth refactoring the asciidoctor-jruby integration from maven and gradle plugins into a separate subproject?
If you make it available as a separate reusable library for the jvm that could increment asciidoctor diffusion, enabling other exotic/foolish usages (such as sketching to produce a plugin providing asciidoc(tor) previews within Eclipse IDE internal browser without other external dependency other than that library).

Cheers
Davide
Reply | Threaded
Open this post in threaded view
|

Re: Is it worth refactoring asciidoctor-jruby integration into a shared library?

LightGuardjp
That's an interesting idea. I'm actually wondering now if it would be better to simply instantiate the asciidoctor object in java and not worry about the little ruby script. Thoughts on that approach?


On Thu, Mar 7, 2013 at 9:25 AM, davide.cavestro [via Asciidoctor :: Discussion] <[hidden email]> wrote:
Hi guys,
I've just discovered asciidoctor following Andres Almiray tweets: is it worth refactoring the asciidoctor-jruby integration from maven and gradle plugins into a separate subproject?
If you make it available as a separate reusable library for the jvm that could increment asciidoctor diffusion, enabling other exotic/foolish usages (such as sketching to produce a plugin providing asciidoc(tor) previews within Eclipse IDE internal browser without other external dependency other than that library).

Cheers
Davide


If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Is-it-worth-refactoring-asciidoctor-jruby-integration-into-a-shared-library-tp25.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: Is it worth refactoring asciidoctor-jruby integration into a shared library?

davide.cavestro
lightguard.jp wrote
[...]I'm actually wondering now if it would be
better to simply instantiate the asciidoctor object in java and not worry
about the little ruby script. Thoughts on that approach?
Granted that I'm not a specialist, I'll go for the way that provides best integration with actual and future asciidoctor environment and features.
I mean if asciidoctor loads resources from ruby environment, I'd look for a way that gives to the jvm similar access to whatever resources it needs, namely backends, configuration and so on (possibly enabling the distribution of mandatory and optional artifacts along with the library or accessible companions).
Reply | Threaded
Open this post in threaded view
|

Re: Is it worth refactoring asciidoctor-jruby integration into a shared library?

mojavelinux
Administrator

I agree, if we can find a common joint point, I'm all for it. Keeping the plugins as thin as possible, including shared bundling of Asciidoctor (and potentially Tilt) would be good for general purpose adoption.

-Dan

--
Sent from my CyanogenMod-powered
Android device, an open platform for
carriers, developers and consumers.

On Mar 7, 2013 11:54 AM, "davide.cavestro [via Asciidoctor :: Discussion]" <[hidden email]> wrote:
[...]I'm actually wondering now if it would be
better to simply instantiate the asciidoctor object in java and not worry
about the little ruby script. Thoughts on that approach?
Granted that I'm not a specialist, I'll go for the way that provides best integration with actual and future asciidoctor environment and features.
I mean if asciidoctor loads resources from ruby environment, I'd look for a way that gives to the jvm similar access to whatever resources it needs, namely backends, configuration and so on (possibly enabling the distribution of mandatory and optional artifacts along with the library or accessible companions).


If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Is-it-worth-refactoring-asciidoctor-jruby-integration-into-a-shared-library-tp25p27.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: Is it worth refactoring asciidoctor-jruby integration into a shared library?

asotobu
I agree too. If we can have a jar artifact which of course internally would use Asciidoctor, and this artifact could be used as  dependency within Java project, we could develop some plugins for some applications so they can use asciidoctor too. At this time I am thinking about Jira, Spring MVC templates for static resources, or one new project called jbake.org which it is saving the distances, something that can become an awestruct like-tool written in Java.

Moreover another advantage that I see is that every time a new asciidoctor version is released, only this shared library would be updated, so Maven Asciidoctor plugin would not require any further modification more than updating pom file. (Of course if no big modification happens on Asciidoctor).

So if lightguard.jp agreed I can start a new project taking as reference the work done for Maven project to start the migration of that part of code to as an external jar.

Well we stay in contact.

Alex.
Reply | Threaded
Open this post in threaded view
|

Re: Is it worth refactoring asciidoctor-jruby integration into a shared library?

LightGuardjp
Sure go for. I'd like to see invoking asciidoctor straight from Java though and avoiding the little ruby script.


On Thu, Mar 14, 2013 at 11:55 AM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote:
I agree too. If we can have a jar artifact which of course internally would use Asciidoctor, and this artifact could be used as  dependency within Java project, we could develop some plugins for some applications so they can use asciidoctor too. At this time I am thinking about Jira, Spring MVC templates for static resources, or one new project called jbake.org which it is saving the distances, something that can become an awestruct like-tool written in Java.

Moreover another advantage that I see is that every time a new asciidoctor version is released, only this shared library would be updated, so Maven Asciidoctor plugin would not require any further modification more than updating pom file. (Of course if no big modification happens on Asciidoctor).

So if lightguard.jp agreed I can start a new project taking as reference the work done for Maven project to start the migration of that part of code to as an external jar.

Well we stay in contact.

Alex.


If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Is-it-worth-refactoring-asciidoctor-jruby-integration-into-a-shared-library-tp25p32.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: Is it worth refactoring asciidoctor-jruby integration into a shared library?

asotobu
Ok,
 my first idea was using the same approach you are using in Maven plugin, that is copying all Asciidoctor stuff from project to another new and invoking as you do. So my main idea is about creating an Asciidoctor Java class which invokes:

  final ScriptEngineManager engineManager = new ScriptEngineManager();
        final ScriptEngine rubyEngine = engineManager.getEngineByName("jruby");
        final Bindings bindings = new SimpleBindings();

        bindings.put("srcDir", sourceDirectory.getAbsolutePath());
        bindings.put("outputDir", outputDirectory.getAbsolutePath());
        bindings.put("backend", backend);

        try {
            final InputStream script = getClass().getClassLoader().getResourceAsStream("execute_asciidoctor.rb");
            final InputStreamReader streamReader = new InputStreamReader(script);
            rubyEngine.eval(streamReader, bindings);
        } catch (ScriptException e) {
            getLog().error("Error running ruby script", e);
        }


Maybe you have another idea? Of course I am open to receive any other suggestion.

Thanks Jason for your attention.

Alex.
Reply | Threaded
Open this post in threaded view
|

Re: Is it worth refactoring asciidoctor-jruby integration into a shared library?

LightGuardjp
Essentially you'd end up doing the same thing as the ruby code, just do it in Java, I'd have to look for an example.


On Thu, Mar 14, 2013 at 12:22 PM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote:
Ok,
 my first idea was using the same approach you are using in Maven plugin, that is copying all Asciidoctor stuff from project to another new and invoking as you do. So my main idea is about creating an Asciidoctor Java class which invokes:

  final ScriptEngineManager engineManager = new ScriptEngineManager();
        final ScriptEngine rubyEngine = engineManager.getEngineByName("jruby");
        final Bindings bindings = new SimpleBindings();

        bindings.put("srcDir", sourceDirectory.getAbsolutePath());
        bindings.put("outputDir", outputDirectory.getAbsolutePath());
        bindings.put("backend", backend);

        try {
            final InputStream script = getClass().getClassLoader().getResourceAsStream("execute_asciidoctor.rb");
            final InputStreamReader streamReader = new InputStreamReader(script);
            rubyEngine.eval(streamReader, bindings);
        } catch (ScriptException e) {
            getLog().error("Error running ruby script", e);
        }


Maybe you have another idea? Of course I am open to receive any other suggestion.

Thanks Jason for your attention.

Alex.



If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Is-it-worth-refactoring-asciidoctor-jruby-integration-into-a-shared-library-tp25p34.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: Is it worth refactoring asciidoctor-jruby integration into a shared library?

asotobu
Ok don't worry I will start next week with this project.

groupId: org.asciidoctor
artifactId: asciidoctor

here I go!!!!
Reply | Threaded
Open this post in threaded view
|

Re: Is it worth refactoring asciidoctor-jruby integration into a shared library?

LightGuardjp
I think maybe a better artifact name: asciidoctor-java-integration perhaps?


On Thu, Mar 14, 2013 at 12:31 PM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote:
Ok don't worry I will start next week with this project.

groupId: org.asciidoctor
artifactId: asciidoctor

here I go!!!!


If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Is-it-worth-refactoring-asciidoctor-jruby-integration-into-a-shared-library-tp25p36.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: Is it worth refactoring asciidoctor-jruby integration into a shared library?

asotobu
mmm maybe yo are right that better another name, but I don't like putting the -integration word, how about jasciidoctor? maybe too much typical? and asciidoctor-java or asciidoctorj? OMG what a headache :P well I think that project should be called asciidoctor-java-integration for sure, but I am not pretty sure about the artifact name. Well anyway I start working and at the end we could define what to do.

Alex.
Reply | Threaded
Open this post in threaded view
|

Re: Is it worth refactoring asciidoctor-jruby integration into a shared library?

LightGuardjp
I don't want to do jasciidoctor, that would imply a java port of asciidoctor. Not exactly what we're doing. I like the integration part because it says what it is that we're doing. org.asciidoctor:java-integration ?


On Thu, Mar 14, 2013 at 12:43 PM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote:
mmm maybe yo are right that better another name, but I don't like putting the -integration word, how about jasciidoctor? maybe too much typical? and asciidoctor-java or asciidoctorj? OMG what a headache :P well I think that project should be called asciidoctor-java-integration for sure, but I am not pretty sure about the artifact name. Well anyway I start working and at the end we could define what to do.

Alex.


If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Is-it-worth-refactoring-asciidoctor-jruby-integration-into-a-shared-library-tp25p38.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: Is it worth refactoring asciidoctor-jruby integration into a shared library?

asotobu
yes true, it seems a port when in reality is not a port.

Maybe you are right and the best way would be:

org.asciidoctor
asciidoctor-java-integration

because maybe if the artifact name  does not contain what is integrating can be a little bit confusing. Well let's try with asciidoctor-java-integration and we have always time to change it ;)
Reply | Threaded
Open this post in threaded view
|

Re: Is it worth refactoring asciidoctor-jruby integration into a shared library?

LightGuardjp
+1


On Thu, Mar 14, 2013 at 12:50 PM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote:
yes true, it seems a port when in reality is not a port.

Maybe you are right and the best way would be:

org.asciidoctor
asciidoctor-java-integration

because maybe if the artifact name  does not contain what is integrating can be a little bit confusing. Well let's try with asciidoctor-java-integration and we have always time to change it ;)


If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Is-it-worth-refactoring-asciidoctor-jruby-integration-into-a-shared-library-tp25p40.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: Is it worth refactoring asciidoctor-jruby integration into a shared library?

davide.cavestro
In reply to this post by asotobu
I asked bintray guys to support rendering github README.asciidoc (Case #: 75). They replied it's on their roadmap, and hence they would also be interested into the asciidoctor-java-integration library (they would be happy to host the binaries in jcenter).

Cheers
Davide
asotobu wrote
... At this time I am thinking about Jira, Spring MVC templates for static resources, or one new project called jbake.org which it is saving the distances, something that can become an awestruct like-tool written in Java...
Reply | Threaded
Open this post in threaded view
|

Re: Is it worth refactoring asciidoctor-jruby integration into a shared library?

asotobu
Next week I will start working on it.


2013/3/15 davide.cavestro [via Asciidoctor :: Discussion] <[hidden email]>
I asked bintray guys to support rendering github README.asciidoc (Case #: 75). They replied it's on their roadmap, and hence they would also be interested into the asciidoctor-java-integration library (they would be happy to host the binaries in jcenter).

Cheers
Davide
asotobu wrote
... At this time I am thinking about Jira, Spring MVC templates for static resources, or one new project called jbake.org which it is saving the distances, something that can become an awestruct like-tool written in Java...



If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Is-it-worth-refactoring-asciidoctor-jruby-integration-into-a-shared-library-tp25p43.html
To unsubscribe from Is it worth refactoring asciidoctor-jruby integration into a shared library?, click here.
NAML



--
+----------------------------------------------------------+
  Alex Soto Bueno - Computer Engineer
  www.lordofthejars.com
+----------------------------------------------------------+
Reply | Threaded
Open this post in threaded view
|

Re: Is it worth refactoring asciidoctor-jruby integration into a shared library?

asotobu
In reply to this post by LightGuardjp
Cool, next week I start with this java integration.
Reply | Threaded
Open this post in threaded view
|

Re: Is it worth refactoring asciidoctor-jruby integration into a shared library?

LightGuardjp
In reply to this post by davide.cavestro
It's certainly something well need to figure out. 

Sent from my iPhone

On Mar 15, 2013, at 2:16, "davide.cavestro [via Asciidoctor :: Discussion]" <[hidden email]> wrote:

I asked bintray guys to support rendering github README.asciidoc (Case #: 75). They replied it's on their roadmap, and hence they would also be interested into the asciidoctor-java-integration library (they would be happy to host the binaries in jcenter).

Cheers
Davide
asotobu wrote
... At this time I am thinking about Jira, Spring MVC templates for static resources, or one new project called jbake.org which it is saving the distances, something that can become an awestruct like-tool written in Java...



If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Is-it-worth-refactoring-asciidoctor-jruby-integration-into-a-shared-library-tp25p43.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: Is it worth refactoring asciidoctor-jruby integration into a shared library?

mojavelinux
Administrator
In reply to this post by LightGuardjp
On Thu, Mar 14, 2013 at 12:11 PM, lightguard.jp [via Asciidoctor :: Discussion] <[hidden email]> wrote:
Sure go for. I'd like to see invoking asciidoctor straight from Java though and avoiding the little ruby script.


Yes, the goals here are two fold:

* A common library that handles the bundling of gems (or gem fetcher, if that becomes the approach) that can be used from Java.
* Switch to calling the Asciidoctor API directly rather than using a Ruby script
** If we need changes to Asciidoctor to enable the direct invocation, feel free to suggest them.

-Dan

--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597

Reply | Threaded
Open this post in threaded view
|

Re: Is it worth refactoring asciidoctor-jruby integration into a shared library?

asotobu
Yes!!
Before starting with asciidoctor-java-integration project, I have one question regarding of what Dan has pointed out in his reply.

From first point:

In Asciidoctor Maven Plugin project, ruby gems (asciidoctor, tilt and coderay) are already bundled into src/main/resources so final user should not worry about installing in his system. Also to update the versions of gems, as it is told in documentation you only have to download the code, run next command (bundle install --path src/main/resources --standalone --clean) and then repackage the plugin. So in case of Java, we can still use the same approach (maybe automatized within build project) so every time a new version of asciidoctor gem is relased a new version of asciidoctor-java-integration is released too. But also if I have not missed something (probably because of my inexperience in Ruby), what Dan is suggesting is that maybe the gems can be fetched  from Java API too, instead/also from build phase.

About second point:

I will start working of course, probably I will importune you more than once because this is the first contact with Ruby for me , never is late to learn one new language.

Well this is all for now, on Monday  you will post the repository location of the project.

Have a nice day

Alex.
123