Going away from the uberjar approach?

[gsmet]

Hi,

The uberjar approach has its advantages but it's also a burden as it's quite hard to keep in sync with the asciidoctorj + asciidoctor-pdf releases.

Currently, for one of our extension to work, we would need the latest 1.6 alpha of asciidoctorj and the latest alpha of asciidoctor-pdf with the latest Ruby (and we might need to upgrade quickly if another bug is discovered).

I was thinking that maybe, instead of releasing an uberjar, we could release a simple jar for people willing to provide the required dependencies in the classpath: they could use the versions they'd like.

If the uberjar is necessary, we could provide both. The uberjar would be updated from time to time with the stable versions. Having also the uberjar would require the API used in the ant task to be stable though. Not sure it's the case.

[binout]

Hi,

It's a good idea. I propose to keep the uber jar :

• asciidoctor-ant-core.jar : the core jar without dependencies (so you can provide your own version of asciidoctorj)
• asciidoctor-ant-all.jar : the jar with all dependencies

I propose to provide these new artifacts in next release 1.5.4.

[gsmet]

I propose to provide these new artifacts in next release 1.5.4.

That would be really nice!

[abelsromero]

:+1: FYI: This was also suggested related to a Maven issue: https://github.com/asciidoctor/asciidoctor-maven-plugin/issues/298. So this will be a perfect time for this change.

By the way, about versions, AsciidoctorJ and the maven-plugin align versions with Asciidoctor (Ruby), so that 1.5.3 of the Java bridge(s) use Asciidoctor (ruby) 1.5.3, 1.5.4 uses 1.5.4...and so on. That makes easy to track the core version used, but it also means releasing versions only to update dependencies or skipping releases. For instance, the maven-plugin skipped 1.5.4 version and jumped from 1.5.3 to 1.5.5 for that reason. Do you think it makes sense to apply this here?

[gsmet]

Yes, Marko is working with us on Hibernate Validator and Bean Validation :).

If we keep the uberjar, I think it makes sense to have the same approach. If we drop it entirely, then it might be OK to stick to the major (I suppose the API would be stable) and have minor on our own.

AFAICS, @binout was willing to keep the uberjar so we should probably stick to the same approach as the maven plugin.

Advanced users would be able to try other versions on their own with the core jar.

[binout]

Just merged https://github.com/asciidoctor/asciidoctor-ant/pull/57

I'll release 1.5.4 this week-end.

[gsmet]

@binout

Nice, thanks!

By any chance, do you know which artifact is using slf4j? I don't see it as a dependency of either asciidoctorj or asciidoctorj-pdf.

I ask this question because I'm wondering if it should be embedded in the core artifact or not.

[binout]

I run test without slf4j and no nore warnings. Maybe it was used by a previous version of asciidoctorj.

So, i remove the dependency from uber jar and no more question for core artifact ;-)

[binout]

Release 1.5.4 done