Imports from JARs are no longer supported

[jchorl]

Bug report

Hi! In past versions of nextflow, I have been able to throw JARs in lib/ and import them, e.g. with:

#!/usr/bin/env nextflow
nextflow.enable.dsl = 2

import com.me.whatever.Me.MyClass

workflow {
	Channel.of(MyClass.FOO) | view
}

Expected behavior and actual behavior

On latest nextflow (unreleased), I'm getting:

Error testimports.nf:5:1: Groovy `import` declarations are not supported -- use fully-qualified name inline instead
│   5 | import com.me.whatever.Me.MyClass
╰     | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

From looking at the code, it looks like parsing logic may have changed around groovy libs. I'm loading java code that is auto-generated so I don't really have the luxury of using "just" groovy files.

I did get this to work with fully qualified paths:

workflow {
	Channel.of(com.me.whatever.Me.MyClass.FOO) | view
}

However in a sophisticated codebase, importing is really helpful. Using fully qualified names everywhere is toilsome, as is the migration!

Any chance you'd consider enabling import from JARs like on 25.10?

Steps to reproduce the problem

Unfortunately I don't have a JAR that I can post, but it should be pretty easy to just compile a standard java class.

Program output

See above

Environment

bash-4.2# ../build/releases/nextflow-25.12.0-edge-dist info
  Version: 25.12.0-edge build 0
  Created: 19-12-2025 11:56 UTC 
  System: Linux 6.8.0-90-generic
  Runtime: Groovy 4.0.30 on OpenJDK 64-Bit Server VM 21.0.10+7-LTS
  Encoding: UTF-8 (UTF-8)

[bentsherman]

Groovy imports were excluded from the strict syntax because they weren't really meant to be used in the Nextflow language. But I tried to make sure that every such exclusion in the strict syntax has a workaround, even if less convenient.

If you don't like having to use the fully-qualified name every time, you can always wrap things in helper functions, or even a plugin. The latter is probably the "right way" to do it, since you can include the JAR as a proper dependency. Especially if you tend to reuse this JAR across many pipelines, you don't have to maintain a copy of it in the lib directory of each pipeline