These are chat archives for nextflow-io/nextflow
@pditommaso Hi Paolo, so I've been experimenting with writing a groovy library of utility functions that I access using grape for use in our pipelines. I've got a proof of concept working, which is great, but I'm running into a problem with versions. Specifically, I have a dependency on
nextflow.script.WorkflowMetadata in my groovy code so I set up a dependency to nextflow in gradle build file. This is all fine, but the problem appears when the version of nextflow I use isn't identical to what I build the library with. I get errors like this:
N E X T F L O W ~ version 0.20.0 Launching main.nf ERROR ~ General error during conversion: Conflicting module versions. Module [groovy-nio is loaded in version 2.4.5 and you are trying to load version 2.4.7 groovy.lang.GroovyRuntimeException: Conflicting module versions. Module [groovy-nio is loaded in version 2.4.5 and you are trying to load version 2.4.7 at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl$DefaultModuleListener.onModule(MetaClassRegistryImpl.java:511) at org.codehaus.groovy.runtime.m12n.ExtensionModuleScanner.scanExtensionModuleFromProperties(ExtensionModuleScanner.java:80) at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.registerExtensionModuleFromProperties(MetaClassRegistryImpl.java:154) at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl$registerExtensionModuleFromProperties.call(Unknown Source) ...
I've tried using a dynamic dependency in the gradle build file (i.e.
io.nextflow:nextflow:0.+), but I still see the same behavior. Any ideas on how I might deal with this? We're pretty aggressive in upgrading to the latest version of nextflow, so trying to keep the library versions up-to-date would be a big hassle. Any ideas would be appreciated. Maybe there are other ways of "including" other groovy libraries beyond the grape grab jar route?