Tako Schotanus

> WDYT of this I'm afraid that this could lead to ambiguities. There are source files that won't have any `//` lines (JBang doesn't require a source file to have...

Btw, a good point _against_ the use of `//INCLUDE` would be that the implementation would become more complex. We'd have to create a temporary file containing the source of both...

In fact let's forget `//INCLUDE` because I just realized it would mean that we'd probably get all kinds of problems with `package` and `import` keywords appearing in the wrong place...

So my final design suggestion would be to use `//IMPORT` on files that follow the same rules we use for source files. That way we can simply reuse the current...

Perhaps an easier way would be to adapt the [getLines()](https://github.com/jbangdev/jbang/blob/main/src/main/java/dev/jbang/source/ScriptSource.java#L115) method to recursively return all `//` lines from the parent file and all imported files. NB: It should only return...

Btw @maxandersen , I see that integrations get passed the original source file and have to do their own comment parsing if they want to read any `//` lines. That...

> I can see it would useful to have access to additional data but I would say we should pass that in as additonal data - like we do pass...

> We can also add meaning to the extension and only allow .jbang, .java,.kt to somewhat limit/guide usage I think this again leads to ambiguities. We already allow source files...

> Wouldn't be a problem. No extension is fine. It won't be a problem if we just assume that you could include/import any file with `//` lines in it (ie...

Can't really test it right now because I don't have a JAR with multiple mains at hand, but can you try with the `--main` option?