Closed josteinaj closed 7 years ago
Could you please also attach the OBFL? The DTBook isn't that relevant here. You can produce it with the option "include OBFL".
Sure.
There's no output file since the job fails, but I can hack it out by enabling calash debug logging in etc/config-logback.xml and adding <p:identity><p:log port="result"/></p:identity>
in front of dotify:obfl-to-pef inside obfl-to-pef.xpl (it will then output to the console but not the job log).
I've attached the entire job log with debugging enabled, as well as the OBFL part as a separate file. I didn't pretty-print it (in case it matters).
By the way, I'm not sure if it's relevant to dotify, but just in case it is; these two modules do not start due to a restriction in the version of org.daisy.pipeline.braille.common:
lb
47|Installed | 50|DP2 Braille Modules :: texhyph-utils :: texhyph-saxon (2.0.1)
77|Installed | 50|DP2 Braille Modules :: libhyphen-utils :: libhyphen-saxon (2.1.0)
start 47
org.osgi.framework.BundleException: Unresolved constraint in bundle org.daisy.pipeline.modules.braille.texhyph-saxon [47]: Unable to resolve 47.0: missing requirement [47.0] osgi.wiring.package; (&(osgi.wiring.package=org.daisy.pipeline.braille.common)(version>=4.0.0)(!(version>=5.0.0)))
start 77
org.osgi.framework.BundleException: Unresolved constraint in bundle org.daisy.pipeline.modules.braille.libhyphen-saxon [77]: Unable to resolve 77.0: missing requirement [77.0] osgi.wiring.package; (&(osgi.wiring.package=org.daisy.pipeline.braille.common)(version>=4.0.0)(!(version>=5.0.0)))
Oh, right. Didn't think of that. So in the case of an error the include-obfl options isn't very useful 😞 . We should come up with a solution for that I think. Can we return part of the outputs and still let the job fail?
Anyway, thanks for the OBFL! It looks like there is a bug in css-to-obfl because there is a sequence which tries to use a layout-master called "master_" but it isn't defined. So this isn't a Dotify problem, although it would maybe be better to not throw a NullPointerException.
I didn't notice the issue with the saxon bundles yet but it also doesn't matter that much because those Saxon bindings are used anywhere. But that for letting me know anyway!
There's no way to provide output files when a job fails since a job failure is a fatal error. Maybe we could use the "VALIDATION_FAIL" status instead.
Is there a quick workaround I can use to get around the NPE for now? I'm getting either this NPE or a "translator not found" (or something) error every time I run a job locally now. I think the translator not found thing is something with how OSGi loads the modules since it only happens half the time, and this NPE seems to be thrown whenever it gets past the translator not found thing. I'll create another issue for the translator not found thing soon, next time I get that error (don't think there's an issue for it?).
This would probably be caught by OBFL validation as the master attribute on sequence is an idref, I think.
OK.
@josteinaj Could you try again with the latest master of pipeline-mod-braille? I have fixed a similar issue but I'm not sure it's the same as yours.
I never got around to trying this it seems.
@bertfrees the changes mentioned here are probably included in the mod-braille that is used in the super-project, right? Which would mean I'm already using them. I tried with the same input DTBook on the most recent nlb-version and there were no errors, so we can probably close this issue...
Attaching full job log and input XML. The relevant Exception is this:
Versions used:
pipeline-assembly @ 921a44fc402fb61b89bb3805ae39143b42fe0d10 (release 1.9.13) + included mod-nlb v1.8.0 for running the job.
...which means for dotify:
Log and input XML (.txt extension for githubs sake):