Using asciidoctorj-pdf from gradle

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Using asciidoctorj-pdf from gradle

elygre
I have a gradle-build that successfully creates a html document. When I try to also generate pdf, it fails.

Am I doing something obviously wrong here?

Eirik

Part of error:

:Documentation:asciidoctor FAILED                                                                                                                                                                                                  
                                                                                                                                                                                                                                   
FAILURE: Build failed with an exception.                                                                                                                                                                                           
                                                                                                                                                                                                                                   
* What went wrong:                                                                                                                                                                                                                 
Execution failed for task ':Documentation:asciidoctor'.                                                                                                                                                                            
> Cannot inherit from final class                                                                                                                                                                                                  
...
Caused by: java.lang.VerifyError: Cannot inherit from final class                                                                                                                                                                  
        at org.jruby.ext.zlib.JZlibDeflate.init(JZlibDeflate.java:118)                                                                                                                                                             
        at org.jruby.ext.zlib.JZlibDeflate.s_deflate(JZlibDeflate.java:75)                                                                                                                                                         
        at org.jruby.ext.zlib.JZlibDeflate$INVOKER$s$0$1$s_deflate.call(JZlibDeflate$INVOKER$s$0$1$s_deflate.gen)                                                                                                                  
        at org.jruby.internal.runtime.methods.JavaMethod$JavaMethodN.call(JavaMethod.java:665)                                                                                                                                     
        at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:206)                                                                                                                                           
        at org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:326)                                                                                                                                       
...

Partial build.gradle:

buildscript {
    dependencies {        
        classpath("org.asciidoctor:asciidoctor-gradle-plugin:1.5.2")
        classpath("org.asciidoctor:asciidoctorj-pdf:1.5.0-alpha.6")
    }
}

asciidoctorj {
    version = '1.5.2'
}

asciidoctor {
    logDocuments = true
    separateOutputDirs = false
    outputDir "$buildDir/documentation/html"
    backends = [ 'html5', 'pdf' ]                                                                                                                                                                                                  
    options     ruby: 'erubis'
    attributes  'source-highlighter': 'prettify',
                'spring-version' : project.version,
                revnumber : project.version
                // doctype: 'book',
}
Reply | Threaded
Open this post in threaded view
|

Re: Using asciidoctorj-pdf from gradle

abelsromero
I reproduced a project with your configuration and it worked for me.
The only thing I can think of is gradle itself,  what version of graddle are you using?

If it helps, here is the full configuration I used, notice the wrapper.

buildscript {
    repositories {
        jcenter()
    }

    dependencies {
        classpath("org.asciidoctor:asciidoctor-gradle-plugin:1.5.2")
        classpath("org.asciidoctor:asciidoctorj-pdf:1.5.0-alpha.6")
    }
}

apply plugin: 'org.asciidoctor.convert'

asciidoctorj {
    version = '1.5.2'
}

asciidoctor {
    logDocuments = true
    separateOutputDirs = false
    outputDir "$buildDir/documentation/html"
    backends = [ 'html5', 'pdf' ]
    options     ruby: 'erubis'
    attributes  'source-highlighter': 'prettify',
                'spring-version' : project.version,
                revnumber : project.version
                // doctype: 'book',
}

task wrapper(type: Wrapper) {
    gradleVersion = '2.1'
}
Reply | Threaded
Open this post in threaded view
|

Re: Using asciidoctorj-pdf from gradle

mojavelinux
Administrator
There are now a really nice set of example projects for using the Gradle plugin thanks to Danny Hyun and Rob Winch. Check them out here. It includes an Asciidoctor PDF example.


I think that will help you if you're still stuck.

Cheers,

-Dan

On Fri, Jan 30, 2015 at 12:33 AM, abelsromero [via Asciidoctor :: Discussion] <[hidden email]> wrote:
I reproduced a project with your configuration and it worked for me.
The only thing I can think of is gradle itself,  what version of graddle are you using?

If it helps, here is the full configuration I used, notice the wrapper.

buildscript {
    repositories {
        jcenter()
    }

    dependencies {
        classpath("org.asciidoctor:asciidoctor-gradle-plugin:1.5.2")
        classpath("org.asciidoctor:asciidoctorj-pdf:1.5.0-alpha.6")
    }
}

apply plugin: 'org.asciidoctor.convert'

asciidoctorj {
    version = '1.5.2'
}

asciidoctor {
    logDocuments = true
    separateOutputDirs = false
    outputDir "$buildDir/documentation/html"
    backends = [ 'html5', 'pdf' ]
    options     ruby: 'erubis'
    attributes  'source-highlighter': 'prettify',
                'spring-version' : project.version,
                revnumber : project.version
                // doctype: 'book',
}

task wrapper(type: Wrapper) {
    gradleVersion = '2.1'
}



If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Using-asciidoctorj-pdf-from-gradle-tp2731p2739.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: Using asciidoctorj-pdf from gradle

elygre
So, this relates to something in our bigger (parent) project. I don't know quite what, yet, but I currently have a gradle build that works when using "gradlew -u asciidoctor" (-u means "don't search for parent project") and fails when using "gradlew asciidoctor".

I'll be (slowly) tearing the parent project apart, but if anybody knows what kind of conflict this could be, I'd be more than grateful!

The innermost part of the stack trace is this:

Caused by: java.lang.VerifyError: Cannot inherit from final class
        at org.jruby.ext.zlib.JZlibDeflate.init(JZlibDeflate.java:118)
        at org.jruby.ext.zlib.JZlibDeflate.s_deflate(JZlibDeflate.java:75)
        at org.jruby.ext.zlib.JZlibDeflate$INVOKER$s$0$1$s_deflate.call(JZlibDeflate$INVOKER$s$0$1$s_deflate.gen)
        at org.jruby.internal.runtime.methods.JavaMethod$JavaMethodN.call(JavaMethod.java:665)
        at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:206)
        at org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:326)
        at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:170)
        at org.jruby.ast.CallOneArgNode.interpret(CallOneArgNode.java:57)
        at org.jruby.ast.NewlineNode.interpret(NewlineNode.java:105)
        at org.jruby.evaluator.ASTInterpreter.INTERPRET_METHOD(ASTInterpreter.java:74)




On Thu, Apr 2, 2015 at 12:51 AM mojavelinux [via Asciidoctor :: Discussion] <[hidden email]> wrote:
There are now a really nice set of example projects for using the Gradle plugin thanks to Danny Hyun and Rob Winch. Check them out here. It includes an Asciidoctor PDF example.


I think that will help you if you're still stuck.

Cheers,

-Dan

On Fri, Jan 30, 2015 at 12:33 AM, abelsromero [via Asciidoctor :: Discussion] <[hidden email]> wrote:
I reproduced a project with your configuration and it worked for me.
The only thing I can think of is gradle itself,  what version of graddle are you using?

If it helps, here is the full configuration I used, notice the wrapper.

buildscript {
    repositories {
        jcenter()
    }

    dependencies {
        classpath("org.asciidoctor:asciidoctor-gradle-plugin:1.5.2")
        classpath("org.asciidoctor:asciidoctorj-pdf:1.5.0-alpha.6")
    }
}

apply plugin: 'org.asciidoctor.convert'

asciidoctorj {
    version = '1.5.2'
}

asciidoctor {
    logDocuments = true
    separateOutputDirs = false
    outputDir "$buildDir/documentation/html"
    backends = [ 'html5', 'pdf' ]
    options     ruby: 'erubis'
    attributes  'source-highlighter': 'prettify',
                'spring-version' : project.version,
                revnumber : project.version
                // doctype: 'book',
}

task wrapper(type: Wrapper) {
    gradleVersion = '2.1'
}



If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Using-asciidoctorj-pdf-from-gradle-tp2731p2739.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:
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Using asciidoctorj-pdf from gradle, click here.
NAML
Reply | Threaded
Open this post in threaded view
|

Re: Using asciidoctorj-pdf from gradle

elygre
In reply to this post by mojavelinux
The problem occurs when using asciidoctorj-pdf in a gradle subproject, where the parent project has the nebula-info plugin applied.

I have created a small github project that demonstrates the problem, with build instructions showing both the succeeding and the failing build, ref https://github.com/elygre/asciidoctor-pdf-final-class.

It seems that nebula-info somehow inserts com.jcraft:jzlib:1.0.7 into the classpath; the log below (grep from "gradle --debug") is only present when the nebula plugin is loaded. This might be related, as the final class exception seems to relate to this.

> grep zlib g.out
12:26:15.831 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.resolveengine.graph.DependencyGraphBuilder] Visiting dependency com.perforce:p4java-jfrog:2011.1.297684(compile) -> com.jcraft:jzlib:1.0.7(dependency: com.jcraft#jzlib;1.0.7 {compile=[compile(*), master(*)], runtime=[runtime(*)]})
12:26:15.831 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.resolveengine.graph.DependencyGraphBuilder] Selecting new module version com.jcraft:jzlib:1.0.7
12:26:15.832 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.ivyresolve.RepositoryChainDependencyResolver] Attempting to resolve com.jcraft:jzlib:1.0.7 using repositories [maven]
12:26:15.835 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.ivyresolve.CachingModuleComponentRepository] Using cached module metadata for module 'com.jcraft:jzlib:1.0.7' in 'maven'
12:26:15.835 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.ivyresolve.RepositoryChainDependencyResolver] Using com.jcraft:jzlib:1.0.7 from Maven repository 'maven'
12:26:15.835 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.resolveengine.graph.DependencyGraphBuilder] Visiting dependency com.perforce:p4java-jfrog:2011.1.297684(runtime) -> com.jcraft:jzlib:1.0.7(dependency: com.jcraft#jzlib;1.0.7 {compile=[compile(*), master(*)], runtime=[runtime(*)]})
12:26:15.869 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.resolveengine.graph.DependencyGraphBuilder] Visiting configuration com.jcraft:jzlib:1.0.7(compile).
12:26:15.869 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.resolveengine.graph.DependencyGraphBuilder] Visiting configuration com.jcraft:jzlib:1.0.7(master).
12:26:15.869 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.resolveengine.graph.DependencyGraphBuilder] Visiting configuration com.jcraft:jzlib:1.0.7(runtime).
12:26:15.931 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.resolveengine.graph.ResolvedConfigurationDependencyGraphVisitor] Attaching com.jcraft:jzlib:1.0.7(compile) to its parents.
12:26:15.931 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.resolveengine.graph.ResolvedConfigurationDependencyGraphVisitor] Attaching com.jcraft:jzlib:1.0.7(master) to its parents.
12:26:15.931 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.resolveengine.graph.ResolvedConfigurationDependencyGraphVisitor] Attaching com.jcraft:jzlib:1.0.7(runtime) to its parents.
12:26:15.954 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.ivyresolve.CachingModuleComponentRepository] Found artifact 'jzlib.jar (com.jcraft:jzlib:1.0.7)' in resolver cache: .gradle\caches\modules-2\files-2.1\com.jcraft\jzlib\1.0.7\ba26d908c6eabe519ef645d81d4e267de7280f8f\jzlib-1.0.7.jar


Eirik

On Mon, Apr 13, 2015 at 8:24 PM Eirik Lygre <[hidden email]> wrote:
So, this relates to something in our bigger (parent) project. I don't know quite what, yet, but I currently have a gradle build that works when using "gradlew -u asciidoctor" (-u means "don't search for parent project") and fails when using "gradlew asciidoctor".

I'll be (slowly) tearing the parent project apart, but if anybody knows what kind of conflict this could be, I'd be more than grateful!

The innermost part of the stack trace is this:

Caused by: java.lang.VerifyError: Cannot inherit from final class
        at org.jruby.ext.zlib.JZlibDeflate.init(JZlibDeflate.java:118)
        at org.jruby.ext.zlib.JZlibDeflate.s_deflate(JZlibDeflate.java:75)
        at org.jruby.ext.zlib.JZlibDeflate$INVOKER$s$0$1$s_deflate.call(JZlibDeflate$INVOKER$s$0$1$s_deflate.gen)
        at org.jruby.internal.runtime.methods.JavaMethod$JavaMethodN.call(JavaMethod.java:665)
        at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:206)
        at org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:326)
        at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:170)
        at org.jruby.ast.CallOneArgNode.interpret(CallOneArgNode.java:57)
        at org.jruby.ast.NewlineNode.interpret(NewlineNode.java:105)
        at org.jruby.evaluator.ASTInterpreter.INTERPRET_METHOD(ASTInterpreter.java:74)




On Thu, Apr 2, 2015 at 12:51 AM mojavelinux [via Asciidoctor :: Discussion] <[hidden email]> wrote:
There are now a really nice set of example projects for using the Gradle plugin thanks to Danny Hyun and Rob Winch. Check them out here. It includes an Asciidoctor PDF example.


I think that will help you if you're still stuck.

Cheers,

-Dan

On Fri, Jan 30, 2015 at 12:33 AM, abelsromero [via Asciidoctor :: Discussion] <[hidden email]> wrote:
I reproduced a project with your configuration and it worked for me.
The only thing I can think of is gradle itself,  what version of graddle are you using?

If it helps, here is the full configuration I used, notice the wrapper.

buildscript {
    repositories {
        jcenter()
    }

    dependencies {
        classpath("org.asciidoctor:asciidoctor-gradle-plugin:1.5.2")
        classpath("org.asciidoctor:asciidoctorj-pdf:1.5.0-alpha.6")
    }
}

apply plugin: 'org.asciidoctor.convert'

asciidoctorj {
    version = '1.5.2'
}

asciidoctor {
    logDocuments = true
    separateOutputDirs = false
    outputDir "$buildDir/documentation/html"
    backends = [ 'html5', 'pdf' ]
    options     ruby: 'erubis'
    attributes  'source-highlighter': 'prettify',
                'spring-version' : project.version,
                revnumber : project.version
                // doctype: 'book',
}

task wrapper(type: Wrapper) {
    gradleVersion = '2.1'
}



If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Using-asciidoctorj-pdf-from-gradle-tp2731p2739.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:
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Using asciidoctorj-pdf from gradle, click here.
NAML
Reply | Threaded
Open this post in threaded view
|

Re: Using asciidoctorj-pdf from gradle

elygre
In reply to this post by mojavelinux
So, the problem is becoming clearer. I tried running gradle with -verbose:class, and now I see some probably vital differences between the working and the failing scenarios.

The working scenario loads com.jcraft.jzlib.ZStream from the jruby library itself:

[Loaded org.jruby.ext.zlib.ZStream from file:/.gradle/caches/modules-2/files-2.1/org.jruby/jruby-complete/1.7.16.1/b76682bd0966a31dab60dc5e275d8b28ac17c38f/jruby-complete-1.7.16.1.jar]
[Loaded com.jcraft.jzlib.ZStream from file:/.gradle/caches/modules-2/files-2.1/org.jruby/jruby-complete/1.7.16.1/b76682bd0966a31dab60dc5e275d8b28ac17c38f/jruby-complete-1.7.16.1.jar]

The failing scenario loads the same class from jzlib-1.0.7.jar:

[Loaded org.jruby.ext.zlib.ZStream from file:/.gradle/caches/modules-2/files-2.1/org.jruby/jruby-complete/1.7.16.1/b76682bd0966a31dab60dc5e275d8b28ac17c38f/jruby-complete-1.7.16.1.jar]
[Loaded com.jcraft.jzlib.ZStream from file:/.gradle/caches/modules-2/files-2.1/com.jcraft/jzlib/1.0.7/ba26d908c6eabe519ef645d81d4e267de7280f8f/jzlib-1.0.7.jar]

I guess I'd think that jruby should repackage their libraries to avoid this kind of problem, but aside from that remark I really don't know how to fix this, except to stop using either the nebula plugin or asciidoctor-pdf.

Eirik

On Tue, Apr 14, 2015 at 12:31 PM Eirik Lygre <[hidden email]> wrote:
The problem occurs when using asciidoctorj-pdf in a gradle subproject, where the parent project has the nebula-info plugin applied.

I have created a small github project that demonstrates the problem, with build instructions showing both the succeeding and the failing build, ref https://github.com/elygre/asciidoctor-pdf-final-class.

It seems that nebula-info somehow inserts com.jcraft:jzlib:1.0.7 into the classpath; the log below (grep from "gradle --debug") is only present when the nebula plugin is loaded. This might be related, as the final class exception seems to relate to this.


Reply | Threaded
Open this post in threaded view
|

Re: Using asciidoctorj-pdf from gradle

elygre
In reply to this post by mojavelinux
My apologies for turning this email thread into my own personal notepad, but this might be the last of the diagnostics:

* JRuby 1.7.16.1 uses (and bundles) jzlib 1.1.2 (ref https://github.com/jruby/jruby/blob/1.7.16.1/core/pom.xml)
* nebula-info, or its dependencies, introduces jzlib 1.0.7 on the classpath
* In jzlib 1.0.7, ZStream is a "public final class" (ref http://repo1.maven.org/maven2/com/jcraft/jzlib/1.0.7/jzlib-1.0.7-sources.jar)
* And then we (correctly) get "Cannot extend final class"

No idea how to fix it, though.

Eirik

On Tue, Apr 14, 2015 at 2:33 PM Eirik Lygre <[hidden email]> wrote:
So, the problem is becoming clearer. I tried running gradle with -verbose:class, and now I see some probably vital differences between the working and the failing scenarios.

The working scenario loads com.jcraft.jzlib.ZStream from the jruby library itself:

[Loaded org.jruby.ext.zlib.ZStream from file:/.gradle/caches/modules-2/files-2.1/org.jruby/jruby-complete/1.7.16.1/b76682bd0966a31dab60dc5e275d8b28ac17c38f/jruby-complete-1.7.16.1.jar]
[Loaded com.jcraft.jzlib.ZStream from file:/.gradle/caches/modules-2/files-2.1/org.jruby/jruby-complete/1.7.16.1/b76682bd0966a31dab60dc5e275d8b28ac17c38f/jruby-complete-1.7.16.1.jar]

The failing scenario loads the same class from jzlib-1.0.7.jar:

[Loaded org.jruby.ext.zlib.ZStream from file:/.gradle/caches/modules-2/files-2.1/org.jruby/jruby-complete/1.7.16.1/b76682bd0966a31dab60dc5e275d8b28ac17c38f/jruby-complete-1.7.16.1.jar]
[Loaded com.jcraft.jzlib.ZStream from file:/.gradle/caches/modules-2/files-2.1/com.jcraft/jzlib/1.0.7/ba26d908c6eabe519ef645d81d4e267de7280f8f/jzlib-1.0.7.jar]

I guess I'd think that jruby should repackage their libraries to avoid this kind of problem, but aside from that remark I really don't know how to fix this, except to stop using either the nebula plugin or asciidoctor-pdf.

Eirik


On Tue, Apr 14, 2015 at 12:31 PM Eirik Lygre <[hidden email]> wrote:
The problem occurs when using asciidoctorj-pdf in a gradle subproject, where the parent project has the nebula-info plugin applied.

I have created a small github project that demonstrates the problem, with build instructions showing both the succeeding and the failing build, ref https://github.com/elygre/asciidoctor-pdf-final-class.

It seems that nebula-info somehow inserts com.jcraft:jzlib:1.0.7 into the classpath; the log below (grep from "gradle --debug") is only present when the nebula plugin is loaded. This might be related, as the final class exception seems to relate to this.


Reply | Threaded
Open this post in threaded view
|

Re: Using asciidoctorj-pdf from gradle

elygre
In reply to this post by mojavelinux
So this is a class loading problem where the same library is included twice, with different versions. The workaround is outlined in http://discuss.gradle.org/t/dealing-with-plugin-classpath-conflicts/9162, and for this particular problem requires using the buildscript {} instead of plugins:

    dependencies {
        classpath ("com.netflix.nebula:gradle-info-plugin:2.2.0") {
            exclude group: "com.jcraft", module: "jzlib"
        }
    }

So, the problem is solved for me.

On the other hand, I'm thinking that jruby (jruby-all, if i recall correctly) might be partly to blame. It introduces com.jcraft-libraries without stating that dependency, so gradle is unable to solve the problem: If jruby had stated a dependency on com.jcraft:jzlib:1.1.2, then netbula-info would not pull in com.jcraft:jzlib:1.0.7, and there would be no problem.

Eirik


On Tue, Apr 14, 2015 at 2:45 PM Eirik Lygre <[hidden email]> wrote:
My apologies for turning this email thread into my own personal notepad, but this might be the last of the diagnostics:

* JRuby 1.7.16.1 uses (and bundles) jzlib 1.1.2 (ref https://github.com/jruby/jruby/blob/1.7.16.1/core/pom.xml)
* nebula-info, or its dependencies, introduces jzlib 1.0.7 on the classpath
* In jzlib 1.0.7, ZStream is a "public final class" (ref http://repo1.maven.org/maven2/com/jcraft/jzlib/1.0.7/jzlib-1.0.7-sources.jar)
* And then we (correctly) get "Cannot extend final class"

No idea how to fix it, though.

Eirik


On Tue, Apr 14, 2015 at 2:33 PM Eirik Lygre <[hidden email]> wrote:
So, the problem is becoming clearer. I tried running gradle with -verbose:class, and now I see some probably vital differences between the working and the failing scenarios.

The working scenario loads com.jcraft.jzlib.ZStream from the jruby library itself:

[Loaded org.jruby.ext.zlib.ZStream from file:/.gradle/caches/modules-2/files-2.1/org.jruby/jruby-complete/1.7.16.1/b76682bd0966a31dab60dc5e275d8b28ac17c38f/jruby-complete-1.7.16.1.jar]
[Loaded com.jcraft.jzlib.ZStream from file:/.gradle/caches/modules-2/files-2.1/org.jruby/jruby-complete/1.7.16.1/b76682bd0966a31dab60dc5e275d8b28ac17c38f/jruby-complete-1.7.16.1.jar]

The failing scenario loads the same class from jzlib-1.0.7.jar:

[Loaded org.jruby.ext.zlib.ZStream from file:/.gradle/caches/modules-2/files-2.1/org.jruby/jruby-complete/1.7.16.1/b76682bd0966a31dab60dc5e275d8b28ac17c38f/jruby-complete-1.7.16.1.jar]
[Loaded com.jcraft.jzlib.ZStream from file:/.gradle/caches/modules-2/files-2.1/com.jcraft/jzlib/1.0.7/ba26d908c6eabe519ef645d81d4e267de7280f8f/jzlib-1.0.7.jar]

I guess I'd think that jruby should repackage their libraries to avoid this kind of problem, but aside from that remark I really don't know how to fix this, except to stop using either the nebula plugin or asciidoctor-pdf.

Eirik


On Tue, Apr 14, 2015 at 12:31 PM Eirik Lygre <[hidden email]> wrote:
The problem occurs when using asciidoctorj-pdf in a gradle subproject, where the parent project has the nebula-info plugin applied.

I have created a small github project that demonstrates the problem, with build instructions showing both the succeeding and the failing build, ref https://github.com/elygre/asciidoctor-pdf-final-class.

It seems that nebula-info somehow inserts com.jcraft:jzlib:1.0.7 into the classpath; the log below (grep from "gradle --debug") is only present when the nebula plugin is loaded. This might be related, as the final class exception seems to relate to this.


Reply | Threaded
Open this post in threaded view
|

Re: Using asciidoctorj-pdf from gradle

mojavelinux
Administrator

On Sat, Apr 18, 2015 at 2:10 PM, elygre [via Asciidoctor :: Discussion] <[hidden email]> wrote:
So, the problem is solved for me.

I'm glad to hear you found a solution!
 

On the other hand, I'm thinking that jruby (jruby-all, if i recall correctly) might be partly to blame. It introduces com.jcraft-libraries without stating that dependency, so gradle is unable to solve the problem: If jruby had stated a dependency on com.jcraft:jzlib:1.1.2, then netbula-info would not pull in com.jcraft:jzlib:1.0.7, and there would be no problem.

I think the key here is that we should move from using jruby-complete to using an unbundled version of jruby so that we can clearly see the dependencies. This is always the risk of using shaded jars. We are discussing something similar in the following issue:


Probably best to proceed with that issue and it should resolve the issue downstream in the Gradle plugin.

Cheers,

-Dan

--