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?

LightGuardjp

Do some research around point one and see what others are doing. There's also the approach [torquebox](http://www.torquebox.org) is taking. They have mirrored rubygems.org and wrapped everything in a jar. If that works, that would be the most ideal way, I think. If not, then using bundler to automatically fetch the gems may be another way to go. The main thing is to get the gems unpacked and in the LOAD_PATH for JRuby. 


Second point: there's no reason to worry about bugging me, it's all collaborative and part of the fun of OSS!


Sent from Mailbox for iPhone


On Sat, Mar 16, 2013 at 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
I have been reading and watching the way how torquebox are dealing with gems (http://torquebox.org/2x/maven-mechanics/). From my point of view I think that we don't have to overcomplicated by mirroring rubygems if we only need 3 gems (Asciidoctor, Coderay and Tilt). So in my opinion we need something pretty much simple. I have seen some people that are using Gradle to download gems and put it into a jar, so I think I will start working in this approach, we can always shift to the torquebox one, but for now I think it is enough.

Alex.


2013/3/16 lightguard.jp [via Asciidoctor :: Discussion] <[hidden email]>

Do some research around point one and see what others are doing. There's also the approach [torquebox](http://www.torquebox.org) is taking. They have mirrored rubygems.org and wrapped everything in a jar. If that works, that would be the most ideal way, I think. If not, then using bundler to automatically fetch the gems may be another way to go. The main thing is to get the gems unpacked and in the LOAD_PATH for JRuby. 


Second point: there's no reason to worry about bugging me, it's all collaborative and part of the fun of OSS!


Sent from Mailbox for iPhone


On Sat, Mar 16, 2013 at 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




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

LightGuardjp

That works fine, as long as people aren't using another engine for their own templates. That's where we'll have problems, but maybe we should tackle that issue later. 


Sent from Mailbox for iPhone


On Sun, Mar 17, 2013 at 11:43 AM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote:

I have been reading and watching the way how torquebox are dealing with gems (http://torquebox.org/2x/maven-mechanics/). From my point of view I think that we don't have to overcomplicated by mirroring rubygems if we only need 3 gems (Asciidoctor, Coderay and Tilt). So in my opinion we need something pretty much simple. I have seen some people that are using Gradle to download gems and put it into a jar, so I think I will start working in this approach, we can always shift to the torquebox one, but for now I think it is enough.

Alex.


2013/3/16 lightguard.jp [via Asciidoctor :: Discussion] <[hidden email]>

Do some research around point one and see what others are doing. There's also the approach [torquebox](http://www.torquebox.org) is taking. They have mirrored rubygems.org and wrapped everything in a jar. If that works, that would be the most ideal way, I think. If not, then using bundler to automatically fetch the gems may be another way to go. The main thing is to get the gems unpacked and in the LOAD_PATH for JRuby. 


Second point: there's no reason to worry about bugging me, it's all collaborative and part of the fun of OSS!


Sent from Mailbox for iPhone


On Sat, Mar 16, 2013 at 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




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-tp25p54.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
+----------------------------------------------------------+



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-tp25p56.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
mm yes that's true, well for now we can start with this simple approach and when I stay more updated with the project, ruby code, ... then we can decide to change or not depending on the requirements of users.



2013/3/17 lightguard.jp [via Asciidoctor :: Discussion] <[hidden email]>

That works fine, as long as people aren't using another engine for their own templates. That's where we'll have problems, but maybe we should tackle that issue later. 


Sent from Mailbox for iPhone


On Sun, Mar 17, 2013 at 11:43 AM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote:

I have been reading and watching the way how torquebox are dealing with gems (http://torquebox.org/2x/maven-mechanics/). From my point of view I think that we don't have to overcomplicated by mirroring rubygems if we only need 3 gems (Asciidoctor, Coderay and Tilt). So in my opinion we need something pretty much simple. I have seen some people that are using Gradle to download gems and put it into a jar, so I think I will start working in this approach, we can always shift to the torquebox one, but for now I think it is enough.

Alex.


2013/3/16 lightguard.jp [via Asciidoctor :: Discussion] <[hidden email]>

Do some research around point one and see what others are doing. There's also the approach [torquebox](http://www.torquebox.org) is taking. They have mirrored rubygems.org and wrapped everything in a jar. If that works, that would be the most ideal way, I think. If not, then using bundler to automatically fetch the gems may be another way to go. The main thing is to get the gems unpacked and in the LOAD_PATH for JRuby. 


Second point: there's no reason to worry about bugging me, it's all collaborative and part of the fun of OSS!


Sent from Mailbox for iPhone


On Sat, Mar 16, 2013 at 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




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-tp25p54.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
+----------------------------------------------------------+



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-tp25p56.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-tp25p57.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?

LightGuardjp

+1


Sent from Mailbox for iPhone


On Sun, Mar 17, 2013 at 12:06 PM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote:

mm yes that's true, well for now we can start with this simple approach and when I stay more updated with the project, ruby code, ... then we can decide to change or not depending on the requirements of users.



2013/3/17 lightguard.jp [via Asciidoctor :: Discussion] <[hidden email]>

That works fine, as long as people aren't using another engine for their own templates. That's where we'll have problems, but maybe we should tackle that issue later. 


Sent from Mailbox for iPhone


On Sun, Mar 17, 2013 at 11:43 AM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote:

I have been reading and watching the way how torquebox are dealing with gems (http://torquebox.org/2x/maven-mechanics/). From my point of view I think that we don't have to overcomplicated by mirroring rubygems if we only need 3 gems (Asciidoctor, Coderay and Tilt). So in my opinion we need something pretty much simple. I have seen some people that are using Gradle to download gems and put it into a jar, so I think I will start working in this approach, we can always shift to the torquebox one, but for now I think it is enough.

Alex.


2013/3/16 lightguard.jp [via Asciidoctor :: Discussion] <[hidden email]>

Do some research around point one and see what others are doing. There's also the approach [torquebox](http://www.torquebox.org) is taking. They have mirrored rubygems.org and wrapped everything in a jar. If that works, that would be the most ideal way, I think. If not, then using bundler to automatically fetch the gems may be another way to go. The main thing is to get the gems unpacked and in the LOAD_PATH for JRuby. 


Second point: there's no reason to worry about bugging me, it's all collaborative and part of the fun of OSS!


Sent from Mailbox for iPhone


On Sat, Mar 16, 2013 at 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




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-tp25p54.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
+----------------------------------------------------------+



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-tp25p56.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-tp25p57.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
+----------------------------------------------------------+



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-tp25p58.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
Here is the link https://github.com/lordofthejars/asciidoctor-java-integration

At this time there is nothing, but this week I will try to upload a first working version (mostly as Maven plugin does), and I will use that state a as a baseline to start working.

Alex.
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 mojavelinux
Hello,

I have got a first pre-version of Asciidoctor-Java-Integration, but before updating github and starting working on how to update gems (fetching or retrieving like Torque does), I was wondering next question:

Do we need to offer methods for modifying documents like def<<(block) or  insert(i, block) , or simply we must offer methods for converting asciidoc documents to String/File of configured backend?

What is your opinion? I think that this project will be mostly used as a way to render asciidoc documents directly from Java (call it Maven, jBake, Spring Web, ...), but not as a way of modifying already parsed documents.

But of course I would like to know your opinion, before jumping to next step.

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

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

LightGuardjp
Just focus on rendering AsciiDoc documents for now, if there's a need for the other, then we can look at it. I suggest the scope for the current project stay very small.


On Tue, Mar 26, 2013 at 2:30 PM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote:
Hello,

I have got a first pre-version of Asciidoctor-Java-Integration, but before updating github and starting working on how to update gems (fetching or retrieving like Torque does), I was wondering next question:

Do we need to offer methods for modifying documents like def<<(block) or  insert(i, block) , or simply we must offer methods for converting asciidoc documents to String/File of configured backend?

What is your opinion? I think that this project will be mostly used as a way to render asciidoc documents directly from Java (call it Maven, jBake, Spring Web, ...), but not as a way of modifying already parsed documents.

But of course I would like to know your opinion, before jumping to next step.

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-tp25p68.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
How weird, I was investigating the AsciiDoc format today for a work related use and thought it would be great if I could add support for the format to JBake, get home and discover somebody has already had the same idea!!

Happy to help if I can?
Reply | Threaded
Open this post in threaded view
|

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

LightGuardjp
I think what we're looking for initially are some other use cases to make sure we have them covered with either this project or the maven one.


On Tue, Mar 26, 2013 at 5:50 PM, jonbullock [via Asciidoctor :: Discussion] <[hidden email]> wrote:
How weird, I was investigating the AsciiDoc format today for a work related use and thought it would be great if I could add support for the format to JBake, get home and discover somebody has already had the same idea!!

Happy to help if I can?


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-tp25p70.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
In reply to this post by jonbullock
Hello,

nice to hear news from you, in reality I was thinking about adding support for asciidoc format to jBake and also adding an embedded Jetty so you could do something like awestruct -d, which starts a server serving generated site.

Now about asciidoc-java-integration, I am currently working with the integration between JRuby and Java, so we can use the asciidoc gem inside Java without having to install any gem (it will be stored inside jar). First step of this project is really simple, only rendering asciidoc files, not manipulating them programmatically, so at this point the project is not quite big. I think you could really help us when the first version of this project is released (not far away from now I wish), because it would be at that point, when you are using it (for example to integrate it to jBake), that you could provide us a really good feedback about the API, if it easy to use, etc,...

If you want you can start inspecting code here https://github.com/lordofthejars/asciidoctor-java-integration Of course I have made some changes which I will push today, but the public interface remains untouched, so you can take an overview of the project.

For now that's all the news I have, of course we can continue talking by email (or other forum) about jBake and new features to add.

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

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

jonbullock
I'll add the Jetty idea to the roadmap, it's something I hadn't considered but should be quite straight forward to add in. I'm also looking at creating a JBoss Forge plugin thanks to a bit prodding from Dan yesterday.

Sounds like the initial use case and focus of this project matches perfectly what I'd be looking for from a JBake perspective, I'd be more than happy to try it out and provide feedback. I'll start by having a look at the code.

Regards,
Jon
Reply | Threaded
Open this post in threaded view
|

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

asotobu
Cool :D

about forge plugin, I have developed one Forge plugin for NoSQLUnit, If you want you can take a look, you will see how to manage with files, resources, and write tests,

nice to see you are onboard too.


2013/3/27 jonbullock [via Asciidoctor :: Discussion] <[hidden email]>
I'll add the Jetty idea to the roadmap, it's something I hadn't considered but should be quite straight forward to add in. I'm also looking at creating a JBoss Forge plugin thanks to a bit prodding from Dan yesterday.

Sounds like the initial use case and focus of this project matches perfectly what I'd be looking for from a JBake perspective, I'd be more than happy to try it out and provide feedback. I'll start by having a look at the code.

Regards,
Jon


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

LightGuardjp
We just have to keep this jar / repo clean of any other dependencies save jruby and what's needed for asciidoctor so the maven and gradle plugins can still use it.


On Wed, Mar 27, 2013 at 1:56 PM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote:
Cool :D

about forge plugin, I have developed one Forge plugin for NoSQLUnit, If you want you can take a look, you will see how to manage with files, resources, and write tests,

nice to see you are onboard too.


2013/3/27 jonbullock [via Asciidoctor :: Discussion] <[hidden email]>
I'll add the Jetty idea to the roadmap, it's something I hadn't considered but should be quite straight forward to add in. I'm also looking at creating a JBoss Forge plugin thanks to a bit prodding from Dan yesterday.

Sounds like the initial use case and focus of this project matches perfectly what I'd be looking for from a JBake perspective, I'd be more than happy to try it out and provide feedback. I'll start by having a look at the code.

Regards,
Jon


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-tp25p73.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
+----------------------------------------------------------+



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-tp25p74.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 think that Jonathan was talking about creating another project, not inside asciidoctor-java-integration, which I totally agree with your that should contain as less dependencies as possible.


2013/3/27 lightguard.jp [via Asciidoctor :: Discussion] <[hidden email]>
We just have to keep this jar / repo clean of any other dependencies save jruby and what's needed for asciidoctor so the maven and gradle plugins can still use it.


On Wed, Mar 27, 2013 at 1:56 PM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote:
Cool :D

about forge plugin, I have developed one Forge plugin for NoSQLUnit, If you want you can take a look, you will see how to manage with files, resources, and write tests,

nice to see you are onboard too.


2013/3/27 jonbullock [via Asciidoctor :: Discussion] <[hidden email]>

I'll add the Jetty idea to the roadmap, it's something I hadn't considered but should be quite straight forward to add in. I'm also looking at creating a JBoss Forge plugin thanks to a bit prodding from Dan yesterday.

Sounds like the initial use case and focus of this project matches perfectly what I'd be looking for from a JBake perspective, I'd be more than happy to try it out and provide feedback. I'll start by having a look at the code.

Regards,
Jon


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-tp25p73.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
+----------------------------------------------------------+



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-tp25p74.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-tp25p75.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?

LightGuardjp
In that case, +1.


On Wed, Mar 27, 2013 at 2:26 PM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote:
I think that Jonathan was talking about creating another project, not inside asciidoctor-java-integration, which I totally agree with your that should contain as less dependencies as possible.


2013/3/27 lightguard.jp [via Asciidoctor :: Discussion] <[hidden email]>
We just have to keep this jar / repo clean of any other dependencies save jruby and what's needed for asciidoctor so the maven and gradle plugins can still use it.


On Wed, Mar 27, 2013 at 1:56 PM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote:
Cool :D

about forge plugin, I have developed one Forge plugin for NoSQLUnit, If you want you can take a look, you will see how to manage with files, resources, and write tests,

nice to see you are onboard too.


2013/3/27 jonbullock [via Asciidoctor :: Discussion] <[hidden email]>

I'll add the Jetty idea to the roadmap, it's something I hadn't considered but should be quite straight forward to add in. I'm also looking at creating a JBoss Forge plugin thanks to a bit prodding from Dan yesterday.

Sounds like the initial use case and focus of this project matches perfectly what I'd be looking for from a JBake perspective, I'd be more than happy to try it out and provide feedback. I'll start by having a look at the code.

Regards,
Jon


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-tp25p73.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
+----------------------------------------------------------+



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-tp25p74.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-tp25p75.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
+----------------------------------------------------------+



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-tp25p76.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
Oh yeah I meant a different project all together, sorry for hijacking the thread!
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

Guys, this is great work! I'm thrilled by the progress and collaboration that's happening. I'm following along with great interest.

Speaking of dependencies, I'd like to suggest adding a few more to the minimal set. If you're going to include Tilt (which is not required unless you have your own templates) you likely need haml too. Personally, I'm more a fan of Slim, and the backends repo has a full set of templates using both.

I also strongly recommend adding, and using by default, erubis. It's turbo-charged ERB. I *always* use it when running Asciidoctor.

In all, here are the gems I recommend including...they are all small:

- erubis
- haml (4.0.1)
- slim (2.0.0.pre6, trust me, it's stable)
(Slim will pull in temple, which is the parser for Slim)

That way, you really won't have many cases (for a while at least) when another gem is needed.

Keep up the great work and collaboration. This is awesome!

-Dan

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

On Mar 27, 2013 3:41 AM, "asotobu [via Asciidoctor :: Discussion]" <[hidden email]> wrote:
Hello,

nice to hear news from you, in reality I was thinking about adding support for asciidoc format to jBake and also adding an embedded Jetty so you could do something like awestruct -d, which starts a server serving generated site.

Now about asciidoc-java-integration, I am currently working with the integration between JRuby and Java, so we can use the asciidoc gem inside Java without having to install any gem (it will be stored inside jar). First step of this project is really simple, only rendering asciidoc files, not manipulating them programmatically, so at this point the project is not quite big. I think you could really help us when the first version of this project is released (not far away from now I wish), because it would be at that point, when you are using it (for example to integrate it to jBake), that you could provide us a really good feedback about the API, if it easy to use, etc,...

If you want you can start inspecting code here https://github.com/lordofthejars/asciidoctor-java-integration Of course I have made some changes which I will push today, but the public interface remains untouched, so you can take an overview of the project.

For now that's all the news I have, of course we can continue talking by email (or other forum) about jBake and new features to add.

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-tp25p72.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 jonbullock

No, thank you for *joining* this thread!

-Dan

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

On Mar 27, 2013 2:31 PM, "jonbullock [via Asciidoctor :: Discussion]" <[hidden email]> wrote:
Oh yeah I meant a different project all together, sorry for hijacking the thread!


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-tp25p78.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
In reply to this post by mojavelinux
That works for me, just a few extra lines in the gemfile.


On Wed, Mar 27, 2013 at 2:47 PM, mojavelinux [via Asciidoctor :: Discussion] <[hidden email]> wrote:

Guys, this is great work! I'm thrilled by the progress and collaboration that's happening. I'm following along with great interest.

Speaking of dependencies, I'd like to suggest adding a few more to the minimal set. If you're going to include Tilt (which is not required unless you have your own templates) you likely need haml too. Personally, I'm more a fan of Slim, and the backends repo has a full set of templates using both.

I also strongly recommend adding, and using by default, erubis. It's turbo-charged ERB. I *always* use it when running Asciidoctor.

In all, here are the gems I recommend including...they are all small:

- erubis
- haml (4.0.1)
- slim (2.0.0.pre6, trust me, it's stable)
(Slim will pull in temple, which is the parser for Slim)

That way, you really won't have many cases (for a while at least) when another gem is needed.

Keep up the great work and collaboration. This is awesome!

-Dan

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

On Mar 27, 2013 3:41 AM, "asotobu [via Asciidoctor :: Discussion]" <[hidden email]> wrote:
Hello,

nice to hear news from you, in reality I was thinking about adding support for asciidoc format to jBake and also adding an embedded Jetty so you could do something like awestruct -d, which starts a server serving generated site.

Now about asciidoc-java-integration, I am currently working with the integration between JRuby and Java, so we can use the asciidoc gem inside Java without having to install any gem (it will be stored inside jar). First step of this project is really simple, only rendering asciidoc files, not manipulating them programmatically, so at this point the project is not quite big. I think you could really help us when the first version of this project is released (not far away from now I wish), because it would be at that point, when you are using it (for example to integrate it to jBake), that you could provide us a really good feedback about the API, if it easy to use, etc,...

If you want you can start inspecting code here https://github.com/lordofthejars/asciidoctor-java-integration Of course I have made some changes which I will push today, but the public interface remains untouched, so you can take an overview of the project.

For now that's all the news I have, of course we can continue talking by email (or other forum) about jBake and new features to add.

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



--
123