Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Administrator
|
And one more thing about the Java integration. You could create a native Ruby extension in Java, which will get used when running under JRuby. Otherwise, you just fall back to jar -jar or however else you decided to invoke the JVM from C Ruby. https://blog.jcoglan.com/2012/08/02/your-first-ruby-native-extension-java That may remain a stretch goal for now, but eventually it would be cool to use the most optimal approach to keep rendering fast. On Fri, Feb 7, 2014 at 5:14 PM, Dan Allen <[hidden email]> wrote:
... [show rest of quote] -- Dan Allen | http://google.com/profiles/dan.j.allen |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
I agree reaching 1.0 is something that never happens if you start with 0.x numbering. I’ve been down that road myself too. I’m going to double-check JRuby support and get at least one proper test written and then I’m ok with a 1.0 alpha release. JRuby is kind of important since the colleagues at work mainly use that. Most of our engineers are windows users and getting MRI (and a native extension building toolchain) setup in windows is just a pain. For the unit test, what I had in mind was to write assertions against the structure of the Document object; not the rendered output. The rationale being that the logic of the block processor works at the Asciidoctor DOM level so testing that should be sufficient. Asciidoctor’s test suite already exercises DOM to HTML conversion so I don’t think it’s necessary to duplicate tests for that portion of the processing pipeline. Does that make sense? Pepijn On 08 Feb 2014, at 01:20, mojavelinux [via Asciidoctor :: Discussion] <[hidden email]> wrote:
... [show rest of quote] |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Administrator
|
Pepijn,
I saw the updates with the JRuby support. Nice work! I agree about the importance of JRuby. In Asciidoctor, JRuby support is paramount, both because of AsciidoctorJ and because Asciidoctor aims to run wherever Ruby runs. And I agree, using JRuby on Windows is the simplest way to get Ruby running there.
> For the unit test, what I had in mind was to write assertions against the structure of the Document object; not the rendered output. > The rationale being that the logic of the block processor works at the Asciidoctor DOM level so testing that should be sufficient.
> Asciidoctor’s test suite already exercises DOM to HTML conversion so I don’t think it’s necessary to duplicate tests for that portion of the processing pipeline. > Does that make sense? Now that you mention it, that makes total sense! Asciidoctor doesn't yet have a document query API, but we're working on one in this issue: https://github.com/asciidoctor/asciidoctor/issues/862. It's pretty easy to add in if you want to create something within the test.
Btw, I've ported the extension to the extension APIs coming in 1.5.0. It was pretty straightforward. I'll push up the branch as soon as I finish merging in the new extension APIs to master.
Cheers! -Dan |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Dan,
I modified the JRuby pull request a bit further this weekend. The MRI and JRuby code paths are now identical with the MRI variant backed by Rjb. That unifies the plantuml invocation code and gets rid of the performance overhead of launching a new VM for each image. I wanted to check with you if using Rjb is ok? Works fine in isolation, but the downside of Rjb is that its VM instance is a global singleton. Pretty hard to manage if you have multiple gems that use Rjb. I deferred loading of Rjb to the latest possible point to mitigate this, but still a bit of a risk. Pepijn |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Administrator
|
On Mon, Feb 10, 2014 at 1:28 AM, pepijnve [via Asciidoctor :: Discussion] <[hidden email]> wrote:
Dan, Nice work! I wanted to check with you if using Rjb is ok? Works fine in isolation, but the downside of Rjb is that its VM instance is a global singleton. Pretty hard to manage if you have multiple gems that use Rjb. I deferred loading of Rjb to the latest possible point to mitigate this, but still a bit of a risk. It's hard for me to anticipate at this point. I image there will be other Ruby extensions that will need Java for one reason or another, but at this point we don't have a candidate for testing the coordination. Perhaps we can cross that bridge when we come to it (one of the great parts about open source...not all problems have to be solved right away :)). I think just having an rjb example in there will allow people to get familiar with it and ideas will pop out. Btw, I'd be happy to help you put together a short blog entry for asciidoctor.org to let people know about the extension and attract some contributors to it. Usually when I write a blog entry I just grab a bunch of paragraphs I've written on the list or in issues, revise it a bit, throw a screenshot in there and ship it. I could help revise it and tweak it too look nice in the asciidoctor.org layout. All you'd need to do is send a pull request as an AsciiDoc document. Here's an example to borrow from: https://github.com/asciidoctor/asciidoctor.org/blob/master/news/github-asciidoctor-0.1.4-upgrade-5-things-to-know.adoc NOTE: You don't need to worry about the "revdate" attribute. That's automatically generated. Cheers, -Dan |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
On 10-02-14 09:48, mojavelinux [via Asciidoctor :: Discussion]
wrote:
Sounds good to me. That would be fantastic. I'll try to come up with something this evening. Pepijn |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Alex, Dan,
I was thinking about adding ditaa and/or blockdiag support to the extension I already have, thereby turning it into an asciidoctor diagramming extension rather than just plantuml. Couple of questions came up right away. Ditaa is GPL licensed. I don't think that's compatible with asciidoctor's license. Any idea how to handle this? Would there be a preference for one big diagramming extension or many small ones? There's going to be lots of shared logic amongst these extensions if they're split up so in that case a gem containing an abstract implementation would make sense. What do you guys think about this? Btw the extension is at the point where I think it's ready for publishing. Just need to figure out how to generate the platform variants. I hope to get it out on ruby gems this evening and then I'll work on an accompanying blog post. Pepijn |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
About license, no idea sorry. About creating one or more extensions, in my opinion I would prefer more than one, but of course you have the knowledge of the whole picture. I say one extension for each one because each one renders diagrams in different way, plantUML is an old style and for example ditaa is more modern, so users can get confused on using same extension and receiving different output, but of course if you think it is better in only one, go ahead.
Alex |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
I think I was a bit imprecise in my single/multiple question. What I
had in mind was one or multiple gems. In terms of asciidoctor I
think multiple extensions is the way to go. I think we want distinct
block types for plantuml, ditaa, blockdiag, etc; not everything
under the same name. That way it's very clear from the asciidoc
source what you're actually doing.
If you have a look at the plantuml extension you'll see that only a small part is actually plantuml specific code. The rest is infrastructure code that computes code checksums, writes cache files, generates attribute values, writes the images to the correct location, etc. All that is pretty much independent of the diagram generator that is actually used. It feels wasteful to duplicate this boilerplate code multiple times. Keeping everything in a single gem is a simple way to make it possible to reuse the code. Alternatively this could be put in a separate gem that's a dependency of the other ones, but that feels a bit like overengineering to me. I think this boils down to 'do we want many tiny gems or one fat gem'? Pepijn On 12-02-14 10:39, asotobu [via
Asciidoctor :: Discussion] wrote:
About license, no idea sorry. About creating one or more extensions, in my opinion I would prefer more than one, but of course you have the knowledge of the whole picture. I say one extension for each one because each one renders diagrams in different way, plantUML is an old style and for example ditaa is more modern, so users can get confused on using same extension and receiving different output, but of course if you think it is better in only one, go ahead. |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Sorry for not have understood your post, yes now that I have read it more concise and with this clarification, you are totally right, we need this abstraction of this kind of extensions to not repeat one and one the same code. And more important that everybody would follow the same strategy. 2014-02-12 11:51 GMT+01:00 pepijnve [via Asciidoctor :: Discussion] <[hidden email]>: I think I was a bit imprecise in my single/multiple question. What I had in mind was one or multiple gems. In terms of asciidoctor I think multiple extensions is the way to go. I think we want distinct block types for plantuml, ditaa, blockdiag, etc; not everything under the same name. That way it's very clear from the asciidoc source what you're actually doing. ... [show rest of quote] +----------------------------------------------------------+ Alex Soto Bueno - Computer Engineer www.lordofthejars.com +----------------------------------------------------------+ |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Small update on the ditaa license front. I was looking at the old sourceforge repo which had GPLv2 as license. The newer github repo (https://github.com/stathissideris/ditaa) has it as LGPLv3 which should not be a problem (I think). Not sure if LGPL would allow embedding the jar in the gem though. I'll have a more in depth look at it this evening.
|
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Yes I agree that LGPLv3 should be enough, I don't know why not everybody follows dzslides license. The world should be easier.
|
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Could you guys have a look at https://github.com/asciidoctor/asciidoctor-plantuml/pull/12 ?
Proposal is to change the gem name to asciidoctor-diagrams since it then handles plantuml and ditaa. I'm planning on adding support for the blockdiag suite and raw graphviz .dot syntax as well. And then I'm done :) Figured out how to get the regular and jruby variant of the gem built in the meantime as well, so it's pretty much ready for publishing at this point. If the name change is ok, I would like to do that first though. Pepijn |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Administrator
|
In reply to this post by pepijnve
Licensing is an area where I feel pretty confident. Mixing licenses only becomes an issue when you are *modifying* the other project's source code. The license dictates what your obligations are with regard to those changes. All major open source licenses give you full rights to redistribute the original, unmodified binaries or source code. In our case, that's exactly what we are doing. The fact that we integrate with that unmodified code doesn't impose any sort of restrictions (or taint) our code, especially if its LGPL. -DanWhat is important is that we preserve any notices that come from the original project. That's where the attribution bit comes in. The way I've handled this is to create a section in the LICENSE file called "other licensed work" and clearly state the licenses for any projects we are using. See https://github.com/opendevise/asciidoctor-pdf/blob/master/LICENSE for an example. On Wed, Feb 12, 2014 at 9:50 AM, pepijnve [via Asciidoctor :: Discussion] <[hidden email]> wrote: Small update on the ditaa license front. I was looking at the old sourceforge repo which had GPLv2 as license. The newer github repo (https://github.com/stathissideris/ditaa) has it as LGPLv3 which should not be a problem (I think). Not sure if LGPL would allow embedding the jar in the gem though. I'll have a more in depth look at it this evening. -- Dan Allen | http://google.com/profiles/dan.j.allen |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Administrator
|
In reply to this post by pepijnve
Actually, the GPLv2 would be a problem, since to include any parts of a GPL program into a project means the whole thing has to be released on the GPL. This is where the LGPL differs. It's this clause that permits us to put the unmodified LGPL program in our gem. "A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License." Thus, if the license is LGPLv3, we are solid. On Wed, Feb 12, 2014 at 4:05 PM, Dan Allen <[hidden email]> wrote:
... [show rest of quote] -- Dan Allen | http://google.com/profiles/dan.j.allen |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Administrator
|
In reply to this post by pepijnve
Pepijn, Given that these extensions all follow a very similar pattern, it does make sense to group them. I would suggest the name asciidoctor-diagram (singular) instead of asciidoctor-diagrams (plural), though, as that seems to be the accepted naming pattern (though still subjective). Since each diagram tool has unique capabilities, I could see the need to have separate gems. However, we could start with a single gem and then branch out once we feel the friction of having them coupled, following the organic growth strategy. One thing I would change in the pull request though is to preserve the ability to import the extensions with and without auto-registration. Thus, I recommend the following structure under lib:
asciidoctor-diagram.rb asciidoctor-diagram/ extension.rb ditaa.rb ditaa/ extension.rb plantuml.rb plantuml/
extension.rb The "ditaa/extension.rb" and "plantuml/extension.rb" files have the implementation code. The "ditaa.rb" and "plantuml.rb" have the auto-register code for each extension. The "asciidoctor-diagram.rb" has the auto-register code for both. The "asciidoctor-diagram/extension.rb" just requires all the implementations without auto-registering. In this way, you can use this import to auto-register all: require 'asciidoctor-diagram' You can use this import to auto-register just plantuml:
require 'asciidoctor-diagram/plantuml' And you can use this import just to import the implementation code for plantuml: require 'asciidoctor-diagram/plantuml/extension' Make sense? On Wed, Feb 12, 2014 at 4:03 PM, pepijnve [via Asciidoctor :: Discussion] <[hidden email]> wrote: Could you guys have a look at https://github.com/asciidoctor/asciidoctor-plantuml/pull/12 ? -- Dan Allen | http://google.com/profiles/dan.j.allen |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Administrator
|
In reply to this post by pepijnve
Btw, fantastic job. You've really knocked this one out of the park! -DanOn Wed, Feb 12, 2014 at 4:31 PM, Dan Allen <[hidden email]> wrote:
... [show rest of quote] -- Dan Allen | http://google.com/profiles/dan.j.allen |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Administrator
|
In reply to this post by pepijnve
I have a question for you. If I were to release Asciidoctor 1.5.0.preview.2 this week, do you think we should release the asciidoctor-diagram gem linking against 1.5.0.preview.2, or do you think we should release against 0.1.4 and then do a separate release of the extension once 1.5.0 is out? The reason I ask is because a release linked against 0.1.4 won't run against 1.5.0 and vice versa. The real question might be, are you able to use Asciidoctor 1.5.0.preview.2 or do you still need to use 0.1.4?
On Wed, Feb 12, 2014 at 4:31 PM, Dan Allen <[hidden email]> wrote:
... [show rest of quote] -- Dan Allen | http://google.com/profiles/dan.j.allen |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
In reply to this post by mojavelinux
It’s a bit of a mess. The download link on the ditaa site refers you to sourceforge for the jar. The source code on sourceforge svn has a COPYING file that says it’s GPLv2. The source code on github however (https://github.com/stathissideris/ditaa) is LGPLv3 licensed. There’s no binary release of that version of the code though. That version of the source code has an unused bit of code to support custom shapes based on SVG input files. It uses the batik library for that which is a huge dependency; I don’t really want to bundle that in the gem. So I went ahead and forked the project, stripped out all the unneeded stuff and labeled that ‘ditaamini’. License is retained as LGPLv3 of course.
Forking is always a bit of a risk, but ditaa development seems to have completely stopped for a while so I think it’s a safe gamble for now. We can always switch back to the original if needed. Pepijn On 13 Feb 2014, at 00:15, mojavelinux [via Asciidoctor :: Discussion] <[hidden email]> wrote: > Actually, the GPLv2 would be a problem, since to include any parts of a GPL program into a project means the whole thing has to be released on the GPL. > > This is where the LGPL differs. It's this clause that permits us to put the unmodified LGPL program in our gem. > > "A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License." > > Thus, if the license is LGPLv3, we are solid. |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
In reply to this post by mojavelinux
I would be inclined to follow the asciidoctor stable/preview versioning. diagram 1.0 -> doctor 0.1.4; diagram 1.1.preview.1 -> doctor 1.5.0.preview.2. Would that be ok?
On 13 Feb 2014, at 00:37, mojavelinux [via Asciidoctor :: Discussion] <[hidden email]> wrote: > I have a question for you. If I were to release Asciidoctor 1.5.0.preview.2 this week, do you think we should release the asciidoctor-diagram gem linking against 1.5.0.preview.2, or do you think we should release against 0.1.4 and then do a separate release of the extension once 1.5.0 is out? The reason I ask is because a release linked against 0.1.4 won't run against 1.5.0 and vice versa. > > The real question might be, are you able to use Asciidoctor 1.5.0.preview.2 or do you still need to use 0.1.4? |
Free forum by Nabble | Edit this page |