-
Notifications
You must be signed in to change notification settings - Fork 120
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AsciidoctorJ failOnWarnings Exception not propagated when executed programatically via gradle-tooling-api #377
Comments
Whilst I ponder the solution, can you have alook what happens when you set I am asking that as this runs the process in the same JVM as Gradle itself and I am curious how that would affect your UX ? |
Thank you for your quick reply. Somehow this totally breaks the setup and I can't really tell why this is happening..
On the off chance that this helps you, our previous solution looked like this: We where scanning the stdout for warnings and threw a GradleException. Running via Java Binding the trace then looked like:
|
Ah, you are building PDFs. Should have paid more attention to it the first message. Yes, Anyhow, I can see two possible implementations: A: Wrap this javaexec in a B: Catch eny exceptions at this point in the remote process and serialise the exception chain back to the main process. (More complex). |
Also on option B above, we'll have an issue if the exception raised in the external process is not on the classpath on the calling Gradle process. |
Will settle for a quick fix for the 2.3.0 release. |
Will be in 2.3.0. |
@ysb33r Thank you, just found time to test the 2.3.0 release. Sadly this doesn't fix our issue. Calling from terminal
When calling from Java
|
So it fails because you get an If that is the case I cannot do anything about it, because Gradle wraps up any external exception and rethrows it as an |
No, the problem is that the The exception you're catching at Line 1004 in ce97e38
org.gradle.process.internal.ExecException and doesn't contain any information about why exactly the build failed, no?
|
So you actually would need solution B from #377 (comment) to be implemented? |
Yes, something like that. We'd definitely need a way to tell why exactly the external process failed.
Would it be possible to at least copy the message of the original Exception (or the stacktrace as String)? Or how would you handle the Exception not being on the classpath otherwise? |
I guess using |
We want to ignore build fails in our application triggered by asciidoctor warnings. But the exception delivered by Gradle is too generic.
Our code calls the asciidoctor build via something like this, using
org.gradle:gradle-tooling-api
:I've activated the new "fail on warnings" functionality discussed in #255 and asciidoctor/asciidoctor-maven-plugin#261.
Exception when called via Java bindings:
Exception when running from the command line:
It would be really helpful if you could get this
org.asciidoctor.gradle.remote.AsciidoctorRemoteExecutionException
in the exception chain when executing via the Java bindings.The text was updated successfully, but these errors were encountered: