Asciidoctor :: Discussion

Asciidoctor Diagram with Maven / Java

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

domgold

Asciidoctor Diagram with Maven / Java

While playing with the Asciidoctor Diagram extension and especially the maven example, I was thinking that there could be a much simpler setup if there were a jar packaged version of Asciidoctor Diagram including an ExtensionRegistry service entry (org.asciidoctor.extension.spi.ExtensionRegistry) to automatically load it if it is on the classpath. The jar could be published to Maven Central. That way we could just add Asciidoctor Diagram as an additional dependency to the Maven plugin.

If you feel like this is a good idea, I would be happy to contribute code.
Do you think this would fit into the existing Asciidoctor Diagram project or should it have its own project ?

Cheers
Dominik

mojavelinux

Re: Asciidoctor Diagram with Maven / Java

Administrator

Dominik,

I agree. This has very much been the vision all along. It definitely should be as easy as adding a single jar file.

What I'm not sure about is where to manage this integration code. Instinct tells me that we should have "J" projects (either as subprojects or top-level repositories) for each Ruby project. Thus, we would have asciidoctorj-diagram. Alex has been talking about structuring the AsciidoctorJ project to accommodate these subprojects (such as asciidoctorj-epub3), so it might be reasonable to put it there. However, since Pepijn maintains Asciidoctor Diagram, it may make sense to keep it a separate project (either a subproject of asciidoctor-diagram or a new repository asciidoctorj-diagram).

My recommendation is to prototype the code in a repository under your username named asciidoctorj-diagram and we'll figure out where to put the code once we move it into the Asciidoctor organization. That way, we don't hold up prototyping.

Cheers,

-Dan

On Fri, Nov 14, 2014 at 3:02 PM, domgold [via Asciidoctor :: Discussion] <[hidden email]> wrote:

While playing with the Asciidoctor Diagram extension and especially the maven example, I was thinking that there could be a much simpler setup if there were a jar packaged version of Asciidoctor Diagram including an ExtensionRegistry service entry (org.asciidoctor.extension.spi.ExtensionRegistry) to automatically load it if it is on the classpath. The jar could be published to Maven Central. That way we could just add Asciidoctor Diagram as an additional dependency to the Maven plugin.

If you feel like this is a good idea, I would be happy to contribute code.
Do you think this would fit into the existing Asciidoctor Diagram project or should it have its own project ?

Cheers
Dominik

If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Asciidoctor-Diagram-with-Maven-Java-tp2460.html

To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML

Dan Allen | http://google.com/profiles/dan.j.allen

domgold

Re: Asciidoctor Diagram with Maven / Java

Dan,

I set up a prototype here: https://github.com/domgold/asciidoctorj-diagram

It is based on a Maven build.
I added one integration test for the moment, which is pretty much the diagram example from the asciidoctor-maven-examples, using asciidoctorj-diagram instead.

The setup is pretty simple. What do you think about creating a repo named `asciidoctorj-extension-packaging` or something like that. This repo might contain a Maven parent project containing the basic build structure, and one child project for each re-packaged extension/converter. To start with that might include: asciidoctorj-diagram, asciidoctorj-epup, asciidoctorj-pdf, asciidoctor-latex.

- Dominik

LightGuardjp

Re: Asciidoctor Diagram with Maven / Java

I may be completely off base here, our maybe just late to the party, but couldn't asciidoctorj use a service loader to pickup all the extensions and load them that way?

On Sun, Nov 16, 2014 at 14:51 domgold [via Asciidoctor :: Discussion] <[hidden email]> wrote:

Dan,

I set up a prototype here: https://github.com/domgold/asciidoctorj-diagram

It is based on a Maven build.
I added one integration test for the moment, which is pretty much the diagram example from the asciidoctor-maven-examples, using asciidoctorj-diagram instead.

The setup is pretty simple. What do you think about creating a repo named `asciidoctorj-extension-packaging` or something like that. This repo might contain a Maven parent project containing the basic build structure, and one child project for each re-packaged extension/converter. To start with that might include: asciidoctorj-diagram, asciidoctorj-epup, asciidoctorj-pdf, asciidoctor-latex.

- Dominik

If you reply to this email, your message will be added to the discussion below:

http://discuss.asciidoctor.org/Asciidoctor-Diagram-with-Maven-Java-tp2460p2466.html

To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML

mojavelinux

Re: Asciidoctor Diagram with Maven / Java

Administrator

On Sun, Nov 16, 2014 at 4:17 PM, LightGuardjp [via Asciidoctor :: Discussion] <[hidden email]> wrote:

couldn't asciidoctorj use a service loader to pickup all the extensions and load them that way?

Sure, but this isn't just about detecting, it's also about bundling. We want to bundle the RubyGems just like we do in AsciidoctorJ, except we don't want to bloat that JAR file.

There is an argument that it shouldn't be necessary to bundle the RubyGems, because the build tool should be able to handle it. That's the direction that the JRuby Gradle Plugin is going. However, I think we are going to have people in both camps, so we should support both approaches.

We are really just feeling around this for the moment. I would refrain from publishing anything to Maven Central until we get an idea of how it feels to consume them. Let's get the packaging right, then start publishing it. Those interested can test it locally without any problem.

-Dan

Dan Allen | http://google.com/profiles/dan.j.allen

mojavelinux

Re: Asciidoctor Diagram with Maven / Java

Administrator

In reply to this post by domgold

Looks good. Certainly is simpler than what is described here: http://mrhaki.blogspot.com/2014/11/awesome-asciidoctor-use-asciidoctor.html (though the JRuby Gradle Plugin is indeed very powerful). There's a lot to be said for just being able to depend on a jar file.

On Sun, Nov 16, 2014 at 2:51 PM, domgold [via Asciidoctor :: Discussion] <[hidden email]> wrote:

It is based on a Maven build.

You might find it easier to use the very powerful JRuby Gradle Plugin, which Schalk works on. Especially if the goal is to consume the generated artifact from Maven Central or jCenter, there's no reason to get stuck using Maven here.

-Dan

Dan Allen | http://google.com/profiles/dan.j.allen

mojavelinux

Re: Asciidoctor Diagram with Maven / Java

Administrator

In reply to this post by domgold

I'm definitely interested to hear from Alex. Alex, does this align with what you were planning, or do you recommend a different direction?

-Dan

On Sun, Nov 16, 2014 at 2:51 PM, domgold [via Asciidoctor :: Discussion] <[hidden email]> wrote:

Dan,

I set up a prototype here: https://github.com/domgold/asciidoctorj-diagram

It is based on a Maven build.
I added one integration test for the moment, which is pretty much the diagram example from the asciidoctor-maven-examples, using asciidoctorj-diagram instead.

The setup is pretty simple. What do you think about creating a repo named `asciidoctorj-extension-packaging` or something like that. This repo might contain a Maven parent project containing the basic build structure, and one child project for each re-packaged extension/converter. To start with that might include: asciidoctorj-diagram, asciidoctorj-epup, asciidoctorj-pdf, asciidoctor-latex.

- Dominik

If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Asciidoctor-Diagram-with-Maven-Java-tp2460p2466.html

To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML

Dan Allen | http://google.com/profiles/dan.j.allen

domgold

Re: Asciidoctor Diagram with Maven / Java

In reply to this post by mojavelinux

I think you're right that the build tool should be able to handle this. But even if there should be support for something like that in Maven in the near future, there would still be plenty of projects using the 'old' aproach which relies on transitive jar dependencies. So I think getting those gems into jars is a 'necessary evil', in order to get more people into the 'asciidoctor boat'.

- Dominik

Le 17 nov. 2014 08:47, "mojavelinux [via Asciidoctor :: Discussion]" <[hidden email]> a écrit :

On Sun, Nov 16, 2014 at 4:17 PM, LightGuardjp [via Asciidoctor :: Discussion] <[hidden email]> wrote:
couldn't asciidoctorj use a service loader to pickup all the extensions and load them that way?

Sure, but this isn't just about detecting, it's also about bundling. We want to bundle the RubyGems just like we do in AsciidoctorJ, except we don't want to bloat that JAR file.

There is an argument that it shouldn't be necessary to bundle the RubyGems, because the build tool should be able to handle it. That's the direction that the JRuby Gradle Plugin is going. However, I think we are going to have people in both camps, so we should support both approaches.

We are really just feeling around this for the moment. I would refrain from publishing anything to Maven Central until we get an idea of how it feels to consume them. Let's get the packaging right, then start publishing it. Those interested can test it locally without any problem.

-Dan

--
Dan Allen | http://google.com/profiles/dan.j.allen

If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Asciidoctor-Diagram-with-Maven-Java-tp2460p2470.html

To unsubscribe from Asciidoctor Diagram with Maven / Java, click here.
NAML

mojavelinux

Re: Asciidoctor Diagram with Maven / Java

Administrator

> I think getting those gems into jars is a 'necessary evil', in order to get more people into the 'asciidoctor boat'.

Agreed.

I want to reiterate that we should be publishing one AsciidoctorJ artifact per gem in the Asciidoctor ecosystem. In other words:

* asciidoctor => asciidoctorj (of course, we'll have a Ruby / Nashorn impl split here, but same idea)

* asciidoctor-pdf => asciidoctorj-pdf

* asciidoctor-epub3 => asciidoctorj-epub3

* asciidoctor-diagram => asciidoctorj-diagram

* ...

I don't think we should be bundling everything up in the main AsciidoctorJ jar because then we get a problem of bloat (the AsciidoctorJ jar is now 27MB). I'm okay with an asciidoctorj-all jar that has the whole ecosystem in it, but we need the individual artifacts too. I'm pretty sure this is the direction we are headed in.

I think that all the bundling can happen as submodules in the main AsciidoctorJ repository, except for perhaps Asciidoctor Diagram. I'm not sure whether that should be a separate repository, but it sort of feels like it should be (as you have setup here). Time will tell us what the right choice is. We can always change if we didn't get it right.

Cheers,

-Dan

On Mon, Nov 17, 2014 at 1:14 AM, domgold [via Asciidoctor :: Discussion] <[hidden email]> wrote:

I think you're right that the build tool should be able to handle this. But even if there should be support for something like that in Maven in the near future, there would still be plenty of projects using the 'old' aproach which relies on transitive jar dependencies. So I think getting those gems into jars is a 'necessary evil', in order to get more people into the 'asciidoctor boat'.

- Dominik

Le 17 nov. 2014 08:47, "mojavelinux [via Asciidoctor :: Discussion]" <[hidden email]> a écrit :

On Sun, Nov 16, 2014 at 4:17 PM, LightGuardjp [via Asciidoctor :: Discussion] <[hidden email]> wrote:
couldn't asciidoctorj use a service loader to pickup all the extensions and load them that way?

Sure, but this isn't just about detecting, it's also about bundling. We want to bundle the RubyGems just like we do in AsciidoctorJ, except we don't want to bloat that JAR file.

There is an argument that it shouldn't be necessary to bundle the RubyGems, because the build tool should be able to handle it. That's the direction that the JRuby Gradle Plugin is going. However, I think we are going to have people in both camps, so we should support both approaches.

We are really just feeling around this for the moment. I would refrain from publishing anything to Maven Central until we get an idea of how it feels to consume them. Let's get the packaging right, then start publishing it. Those interested can test it locally without any problem.

-Dan

--
Dan Allen | http://google.com/profiles/dan.j.allen

If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Asciidoctor-Diagram-with-Maven-Java-tp2460p2470.html

To unsubscribe from Asciidoctor Diagram with Maven / Java, click here.
NAML

If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Asciidoctor-Diagram-with-Maven-Java-tp2460p2473.html

To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML

Dan Allen | http://google.com/profiles/dan.j.allen