Nextflow DSL AST magic is applied to groovy classes under lib.

[vruano]

Bug report

In a pipeline a have a bunch of support groovy code that I place under lib as .groovy class source files. Some of this classes override equals, hashCode and other methods as I think they are allowed to do in order to provide a consistent behaviour based on their intended semantics.

In some of the pipeline runs (we don't know exactly what makes it happens some time and sometimes now) we ha a compilation time failure like this one

ERROR ~ file:/somewhere-under-the-rainbow/lib/ClassA.groovy: 202: Identifier `equals` is reserved for internal use @ line 202, column 17.
           @Override
                           ^

To be more precise the error occurs in an static inner class declared like this:

// lib/ClassA.groovy

@Immutable
@MapConstructor(post = { assert .... })
@EqualsAndHashCode
class ClassA implements CacheFunnel {
...
     @EqualsAndHashCode
     static class ClassB implements CacheFunnel {
     ....
     // line 202:
         @Override 
         boolean equals(Object obj) {
         ...
         } 
     }
}

I hope that the schematic pseudo code captures enough detail.

The exception that result in the error message above makes reference to Nextflow DSL Parser:

nextflow.exception.ScriptCompilationException: file:/somewhere-under-the-rainbow....
        at nextflow.script.ScriptParser.parse0(ScriptParser.groovy:196)
        at nextflow.script.ScriptParser.parse(ScriptParser.groovy:206)
        at nextflow.script.ScriptParser.runScript(ScriptParser.groovy:221)
        at nextflow.script.IncludeDef.memoizedMethodPriv$loadModule0PathMapSession(IncludeDef.groovy:140)
        at nextflow.script.IncludeDef.access$0(IncludeDef.groovy)
       ...
Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
      file:/somewhere-under-the-rainbow ...
at org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:292)
        at org.codehaus.groovy.control.CompilationUnit$IPrimaryClassNodeOperation.doPhaseOperation(CompilationUnit.java:980)
        at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:692)
        at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:666)
        at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:373)
        at groovy.lang.GroovyClassLoader.lambda$parseClass$2(GroovyClassLoader.java:316)
        ....
       ... 132 frames omitted.

Looking into the latest nextflow code I find the error message formatting message in NextflowDSLImpl.groovy line 1327.

So it seems that Nextflow's DSL handling no only processes workflow and process definition files (.nf usually) but also .groovy files under lib, is that correct.

Would it make sense to exclude supporting .groovy files under libs from DSL processing? Again this is an intermittent problem so perhaps is all resulting from a glitch.

Expected behavior and actual behavior

The expected behavior is that I'm allowed to overwrite method in .groovy classes especially since these are supporting classes and not nextflow scripts.

The actual behavior is that sometimes there are compilation issues due what it seems to be non-specific application of the DSL processing of those groovy files.

Steps to reproduce the problem

Unfortunately at this point I don't have a small/simple setup that reproduces the error consistently.

Program output

(Copy and paste the output produced by the failing execution. Please highlight it as a code block. Whenever possible upload the .nextflow.log file.)

Environment

• Nextflow version: 24.04.4
• Groovy version: 4.0.21
• Java version: OpenJDK 64-Bit Server VM 17.0.3+6-LTS
• Operating system: Linux
• Bash version: GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu)

Additional context

Nothing to report.

[bentsherman]

I think you're right, it looks like NextflowDSLImpl is also applied to Groovy classes in the lib directory.

I don't think there is an easy way to fix this in the old parser, because AST transforms are applied to all compiled classes and lib classes are added to the same compilation path as Nextflow scripts

However, it looks like the new parser doesn't have this problem, because it applies all DSL transforms before adding in the lib classes. So you should be able to work around this issue by using 25.04 and setting NXF_SYNTAX_PARSER=v2.

[vruano]

Thanks @bentsherman. Unfortunatelly I'm not in a position to request a nextflow version upgrade at this point. Would translate those groovy into good-old plain java classes help?

[bentsherman]

You would need to move those classes into a plugin to make it work