Asciidoctor :: Discussion

Re: Strategy for providing asciidoctorj-pdf

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

mojavelinux

Re: Strategy for providing asciidoctorj-pdf

Administrator

On Sat, Aug 20, 2016 at 4:14 AM, Robert.Panzer [via Asciidoctor :: Discussion] <[hidden email]> wrote:

Lift the dependency on JRuby to 9000 at least for asciidoctorj-pdf and the distribution. (This would raise the Java requirement to 1.7 and JRuby 9000+Asciidoctorj doesn't work properly on Win now)

If we decide to take this path, it only further emphasizes why we need separate repositories for these modules. Just as Asciidoctor PDF has different requirements from core, AsciidoctorJ PDF could have different requirements. The distribution should also be a separate module so that it can select which components it wants to bundle. There may still be some implications we have to consider, but it would at least help us out of this rut.

-Dan

Dan Allen | @mojavelinux | https://twitter.com/mojavelinux

Robert.Panzer

Re: Strategy for providing asciidoctorj-pdf

Oh, just found the response here, seems like it wasn't attached to the original question.

Yeah, this option is reasonable.
It just makes me a bit afraid facing work on the publishing of the artifacts.

If we follow this path, do you think it still makes sense to publish the distribution under the same gav as the "base" jar?

Another point we would have to pay attention to is that we changed the jruby dependency from jruby-complete to jruby in asciidoctorj-1.6.0.
Should we go back to jruby-complete there again or expect the user to exclude one of the two dependencies when combining asciidoctorj 1.6.0 with asciidoctorj-pdf in a maven or grade build?

Cheers
Robert

mojavelinux

Re: Strategy for providing asciidoctorj-pdf

Administrator

On Fri, Sep 16, 2016 at 11:09 AM, Robert.Panzer [via Asciidoctor :: Discussion] <[hidden email]> wrote:

Should we go back to jruby-complete there again or expect the user to exclude one of the two dependencies when combining asciidoctorj 1.6.0 with asciidoctorj-pdf in a maven or grade build?

I think that the add-on modules like AsciidoctorJ PDF should mark JRuby as provided. Only asciidoctorj should pull in JRuby. In fact, I might even go so far as to say asciidoctorj should be marked provided to. That way, when you add the dependency on asciidoctorj-pdf, it just adds its own artifacts. You won't be able to add asciidoctorj-pdf without adding asciidoctorj too. We need to try to have less collisions.

-Dan

Dan Allen | @mojavelinux | https://twitter.com/mojavelinux

mojavelinux

Re: Strategy for providing asciidoctorj-pdf

Administrator

In reply to this post by Robert.Panzer

On Fri, Sep 16, 2016 at 11:09 AM, Robert.Panzer [via Asciidoctor :: Discussion] <[hidden email]> wrote:

It just makes me a bit afraid facing work on the publishing of the artifacts.

I understand that pain ;)

In the long run, it will be a lot less painful then trying to release artifacts with different versions out of the same repository.

-Dan

Dan Allen | @mojavelinux | https://twitter.com/mojavelinux

mojavelinux

Re: Strategy for providing asciidoctorj-pdf

Administrator

In reply to this post by Robert.Panzer

On Fri, Sep 16, 2016 at 11:09 AM, Robert.Panzer [via Asciidoctor :: Discussion] <[hidden email]> wrote:

If we follow this path, do you think it still makes sense to publish the distribution under the same gav as the "base" jar?

I don't see why not, but in the end, I don't think it really matters to the user one way or the other. As long as the zip file provides what is needed, it could come from Mars.

-Dan

Dan Allen | @mojavelinux | https://twitter.com/mojavelinux

Robert.Panzer

Re: Strategy for providing asciidoctorj-pdf

Sorry for my stupid questions.
Apparently I caught too much sun.

After all I guess we don't even need any dependency on jruby in asciidoctorj-pdf.
It should depend on asciidoctorj, and I even think it should depend on the same version, the ruby gem depends on, i.e. simply 1.5.0.

I could even lift the dependency on Prawn to 2.1.0 now, when we're talking about JRuby 9000 and Java 7 anyway, if you agree.