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
|

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

mojavelinux
Administrator

We've all worked in Ruby for the first time, many of us quite recently. What I've enjoyed about Ruby is that it puts the focus on solutions, not whether you are doing it right. We figure out the latter together.

So just hack away and enjoy doing it! ... Welcome to a polyglot world!

-Dan

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

On Mar 16, 2013 4:54 AM, "asotobu [via Asciidoctor :: Discussion]" <[hidden email]> wrote:
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.


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-tp25p52.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
Good news, almost the first version of asciidoctor-java-integration is done. Gems no longer lives inside project, they are simply a dependency inside Maven, and when process-resources phase is executed, gems are download and installed correctly inside target directory, so can be available from Java code.

Now to change any version of a gem, we simply need to change a property in pom file and the new gem will be bundled inside jar.

Dan sadly I could not add last version of slim, I don't know why but in torquebox proxy repository (release and prerelease) the 2.0.0.pre6 does not exists so I have added the 1.3.6, and when a final version will be released, I will update the pom (as easy as this).

Next steps I will follow:

- adding a better way to setting parameters to Asciidoctor instead of /apart from a simple Map. Surely using a Fluent interface.
- adding extra features (for example scanning and converting a directory of asciidoctor files).
- adding release plugin to publish jar to maven central repo.
- Dan, Jason I think it is time to start thinking about cloning my project into asciidoctor repository (what you think?).
- registering project to Build Hive so we can have CI.
- and of course more tests and improve javadoc.

As usually please if you found anything that you don't like, any method name that should be changed (I am the worst person given name to things), etc ... do not hesitate to do it.

Also Jonathan if you find something to improve so it can make your life easier in jBake, feel free to comment.

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

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

LightGuardjp
Administrator

I'll have to take a look at the great job that's been done!


I'd say, yes, let's bring this into the asciidoctor org. 

For CI, not that I have any issues with Cloudbees, but Travis is soo much easier to integrate. 

I'll look more tomorrow

Sent from Mailbox for iPhone


On Sun, Mar 31, 2013 at 1:40 PM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote:

Good news, almost the first version of asciidoctor-java-integration is done. Gems no longer lives inside project, they are simply a dependency inside Maven, and when process-resources phase is executed, gems are download and installed correctly inside target directory, so can be available from Java code.

Now to change any version of a gem, we simply need to change a property in pom file and the new gem will be bundled inside jar.

Dan sadly I could not add last version of slim, I don't know why but in torquebox proxy repository (release and prerelease) the 2.0.0.pre6 does not exists so I have added the 1.3.6, and when a final version will be released, I will update the pom (as easy as this).

Next steps I will follow:

- adding a better way to setting parameters to Asciidoctor instead of /apart from a simple Map. Surely using a Fluent interface.
- adding extra features (for example scanning and converting a directory of asciidoctor files).
- adding release plugin to publish jar to maven central repo.
- Dan, Jason I think it is time to start thinking about cloning my project into asciidoctor repository (what you think?).
- registering project to Build Hive so we can have CI.
- and of course more tests and improve javadoc.

As usually please if you found anything that you don't like, any method name that should be changed (I am the worst person given name to things), etc ... do not hesitate to do it.

Also Jonathan if you find something to improve so it can make your life easier in jBake, feel free to comment.

Cheers,
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-tp25p83.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?

LightGuardjp
Administrator
In reply to this post by asotobu
Good stuff!


On Sun, Mar 31, 2013 at 2:39 PM, Jason Porter <[hidden email]> wrote:

I'll have to take a look at the great job that's been done!


I'd say, yes, let's bring this into the asciidoctor org. 

For CI, not that I have any issues with Cloudbees, but Travis is soo much easier to integrate. 

I'll look more tomorrow

Sent from Mailbox for iPhone


On Sun, Mar 31, 2013 at 1:40 PM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote:

Good news, almost the first version of asciidoctor-java-integration is done. Gems no longer lives inside project, they are simply a dependency inside Maven, and when process-resources phase is executed, gems are download and installed correctly inside target directory, so can be available from Java code.

Now to change any version of a gem, we simply need to change a property in pom file and the new gem will be bundled inside jar.

Dan sadly I could not add last version of slim, I don't know why but in torquebox proxy repository (release and prerelease) the 2.0.0.pre6 does not exists so I have added the 1.3.6, and when a final version will be released, I will update the pom (as easy as this).

Next steps I will follow:

- adding a better way to setting parameters to Asciidoctor instead of /apart from a simple Map. Surely using a Fluent interface.
- adding extra features (for example scanning and converting a directory of asciidoctor files).
- adding release plugin to publish jar to maven central repo.
- Dan, Jason I think it is time to start thinking about cloning my project into asciidoctor repository (what you think?).
- registering project to Build Hive so we can have CI.
- and of course more tests and improve javadoc.

As usually please if you found anything that you don't like, any method name that should be changed (I am the worst person given name to things), etc ... do not hesitate to do it.

Also Jonathan if you find something to improve so it can make your life easier in jBake, feel free to comment.

Cheers,
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-tp25p83.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 asotobu
Alex,

This is indeed great news. By pulling the gems out of the project and making the upgrade as easy as changing a property file is going to bring this library a lot of respect [1]. People should take notice.

No worries about the latest version of slim. Version 1.3.6 functions the same, so nothing is lost. We can be patient for an official release.

It's absolutely time to bring this project into the Asciidoctor organization! I'll pull it in later today. It's graduation time!

When I get it moved over, perhaps you can convert your roadmap items into issues in the issue tracker.

As Jason mentioned, I also recommend Travis CI over BuildHive. I have been so impressed by Travis and it's reliability. It just seems to get the job done w/o so much as a compliant. If you need help setting it up, just let us know.

Keep up the great work!

-Dan

[1] In fact, I'd say the research you've done is worth of an article...let me know if you are interested in writing something and I'll put you in touch w/ magazine folks.

On Sun, Mar 31, 2013 at 1:40 PM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote:
Good news, almost the first version of asciidoctor-java-integration is done. Gems no longer lives inside project, they are simply a dependency inside Maven, and when process-resources phase is executed, gems are download and installed correctly inside target directory, so can be available from Java code.

Now to change any version of a gem, we simply need to change a property in pom file and the new gem will be bundled inside jar.

Dan sadly I could not add last version of slim, I don't know why but in torquebox proxy repository (release and prerelease) the 2.0.0.pre6 does not exists so I have added the 1.3.6, and when a final version will be released, I will update the pom (as easy as this).

Next steps I will follow:

- adding a better way to setting parameters to Asciidoctor instead of /apart from a simple Map. Surely using a Fluent interface.
- adding extra features (for example scanning and converting a directory of asciidoctor files).
- adding release plugin to publish jar to maven central repo.
- Dan, Jason I think it is time to start thinking about cloning my project into asciidoctor repository (what you think?).
- registering project to Build Hive so we can have CI.
- and of course more tests and improve javadoc.

As usually please if you found anything that you don't like, any method name that should be changed (I am the worst person given name to things), etc ... do not hesitate to do it.

Also Jonathan if you find something to improve so it can make your life easier in jBake, feel free to comment.

Cheers,
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-tp25p83.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML



--
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
Hi Dan,

this afternoon I will migrate the project to asciidoctor repository and then I will register the project to Travis CI. I have been reading its documentation and it seems so easy to use it with a github project.

About the article of course I am interested in writing about it, I think it might help other people to do something similar as I have done in Asciidoctor but for other gems, projects, ....

Also I would like to thank Jason and you for your helping me in the initial stages of the project.

We are in touch,

Alex.


2013/4/3 mojavelinux [via Asciidoctor :: Discussion] <[hidden email]>
Alex,

This is indeed great news. By pulling the gems out of the project and making the upgrade as easy as changing a property file is going to bring this library a lot of respect [1]. People should take notice.

No worries about the latest version of slim. Version 1.3.6 functions the same, so nothing is lost. We can be patient for an official release.

It's absolutely time to bring this project into the Asciidoctor organization! I'll pull it in later today. It's graduation time!

When I get it moved over, perhaps you can convert your roadmap items into issues in the issue tracker.

As Jason mentioned, I also recommend Travis CI over BuildHive. I have been so impressed by Travis and it's reliability. It just seems to get the job done w/o so much as a compliant. If you need help setting it up, just let us know.

Keep up the great work!

-Dan

[1] In fact, I'd say the research you've done is worth of an article...let me know if you are interested in writing something and I'll put you in touch w/ magazine folks.

On Sun, Mar 31, 2013 at 1:40 PM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote:
Good news, almost the first version of asciidoctor-java-integration is done. Gems no longer lives inside project, they are simply a dependency inside Maven, and when process-resources phase is executed, gems are download and installed correctly inside target directory, so can be available from Java code.

Now to change any version of a gem, we simply need to change a property in pom file and the new gem will be bundled inside jar.

Dan sadly I could not add last version of slim, I don't know why but in torquebox proxy repository (release and prerelease) the 2.0.0.pre6 does not exists so I have added the 1.3.6, and when a final version will be released, I will update the pom (as easy as this).

Next steps I will follow:

- adding a better way to setting parameters to Asciidoctor instead of /apart from a simple Map. Surely using a Fluent interface.
- adding extra features (for example scanning and converting a directory of asciidoctor files).
- adding release plugin to publish jar to maven central repo.
- Dan, Jason I think it is time to start thinking about cloning my project into asciidoctor repository (what you think?).
- registering project to Build Hive so we can have CI.
- and of course more tests and improve javadoc.

As usually please if you found anything that you don't like, any method name that should be changed (I am the worst person given name to things), etc ... do not hesitate to do it.

Also Jonathan if you find something to improve so it can make your life easier in jBake, feel free to comment.

Cheers,
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-tp25p83.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML



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




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-tp25p87.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
Hello,

project is transferred to asciidoctor repository, next step is to publish to maven central repo, so can be used as a dependency in projects. Before that I will improve a little bit the public interface so can be easy to integrate with asciidoctor-gradle/maven plugin.

And of course Davide will be able to use it within its project.

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

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

davide.cavestro
@Alex
That's great!
Asciidoctor has a great community and I hope to contribute in the near future.

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

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

lincolnthree
Just in case it helps at all, it sounds like you guys already have a solid start on this, but in Rewrite, we actually just used a little script to copy the Gems into our sources. This of course is not as optimal as having maven do this based on a property file, but it means we don't have to download new versions of Gems on every build, which in turn makes it easy to lock versions of intermediate gems (might be a problem for build stability if something else changes in the Gem depchain.)

https://github.com/ocpsoft/rewrite/tree/master/transform-markup
https://github.com/ocpsoft/rewrite/blob/master/transform-markup/download-gems.sh

Cheers guys! Asciidoctor is awesome! And actually we are already supporting it with the rewrite-transform module (as described above.) - See usage here for rendering directly from source to HTML - https://github.com/ocpsoft/redoculous/blob/master/src/main/java/org/ocpsoft/redoculous/RedoculousConfigurationProvider.java#L211

We would obviously prefer to use a Java API than doing this ourselves, but since we also support Markdown and several other markup languages, I can definitely see the use for doing this on other projects as well and creating a more general solution.

~Lincoln

~~~ Rewrite
Reply | Threaded
Open this post in threaded view
|

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

LightGuardjp
Administrator
Thanks Lincoln. We were doing that before with bundler, but I think the maven solution is better, if for no other reason, it will allow others to use different backends and simply add them via maven. If you're company is using a specific backend, or your doing some in house tweaking of a backend, you just need to put it in a jar and add it to your pom.


On Fri, Apr 5, 2013 at 12:52 PM, Lincoln Baxter, III [via Asciidoctor :: Discussion] <[hidden email]> wrote:
Just in case it helps at all, it sounds like you guys already have a solid start on this, but in Rewrite, we actually just used a little script to copy the Gems into our sources. This of course is not as optimal as having maven do this based on a property file, but it means we don't have to download new versions of Gems on every build, which in turn makes it easy to lock versions of intermediate gems (might be a problem for build stability if something else changes in the Gem depchain.)

https://github.com/ocpsoft/rewrite/tree/master/transform-markup
https://github.com/ocpsoft/rewrite/blob/master/transform-markup/download-gems.sh

Cheers guys! Asciidoctor is awesome! And actually we are already supporting it with the rewrite-transform module (as described above.) - See usage here for rendering directly from source to HTML - https://github.com/ocpsoft/redoculous/blob/master/src/main/java/org/ocpsoft/redoculous/RedoculousConfigurationProvider.java#L211

We would obviously prefer to use a Java API than doing this ourselves, but since we also support Markdown and several other markup languages, I can definitely see the use for doing this on other projects as well and creating a more general solution.

~Lincoln




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-tp25p91.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?

jonbullock
In reply to this post by asotobu
Great work Alex, used the project to get a test class in JBake to render a AsciiDoc file.

Jon
Reply | Threaded
Open this post in threaded view
|

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

mojavelinux
Administrator
I'd conclude that the answer to the subject of this thread is:

*Absolutely*

What an impact it has made.
Reply | Threaded
Open this post in threaded view
|

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

LightGuardjp
Administrator
What do we mean by this? Isn't it already a shared library? I understand this is old, but why revive the zombie thread?


On Thu, May 23, 2013 at 3:42 AM, mojavelinux [via Asciidoctor :: Discussion] <[hidden email]> wrote:
I'd conclude that the answer to the subject of this thread is:

*Absolutely*

What an impact it has made.


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-tp25p224.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

Because I'm proud of it :)

-Dan

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

On May 23, 2013 10:12 AM, "lightguard.jp [via Asciidoctor :: Discussion]" <[hidden email]> wrote:
What do we mean by this? Isn't it already a shared library? I understand this is old, but why revive the zombie thread?


On Thu, May 23, 2013 at 3:42 AM, mojavelinux [via Asciidoctor :: Discussion] <[hidden email]> wrote:
I'd conclude that the answer to the subject of this thread is:

*Absolutely*

What an impact it has made.


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-tp25p224.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML



--



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-tp25p225.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?

LightGuardjp
Administrator
* shuffle shuffle*

MUGH.... PRIDE .... MUGH

*shuffle shuffle*


On Thu, May 23, 2013 at 10:32 AM, mojavelinux [via Asciidoctor :: Discussion] <[hidden email]> wrote:

Because I'm proud of it :)

-Dan

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

On May 23, 2013 10:12 AM, "lightguard.jp [via Asciidoctor :: Discussion]" <[hidden email]> wrote:
What do we mean by this? Isn't it already a shared library? I understand this is old, but why revive the zombie thread?


On Thu, May 23, 2013 at 3:42 AM, mojavelinux [via Asciidoctor :: Discussion] <[hidden email]> wrote:
I'd conclude that the answer to the subject of this thread is:

*Absolutely*

What an impact it has made.


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-tp25p224.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML

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-tp25p225.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML



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-tp25p226.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML



--
123