Should we actually have a ScriptBuildServer as a separate thing?

Why should we?
It's a capability that can be declared as supported via normal capabilities. Also, nothing stops someone to write a script wrapper for java which does a similar thing to what scala-cli does.

sure, I was just being cautious since we don't have too many server implementing this, but I guess it's totally fine if we add a capability

There is probably no clear line to cut between an capability and an extension. They mostly differ in how they get enabled. And this story isn't completely written for modularity.

@lolgab What stops us to use the wrapperSources to use for Java files right away. Is there anything Scala specific?

@lolgab What stops us to use the wrapperSources to use for Java files right away. Is there anything Scala specific?

I don't think anything stops us, but other than the javadoc maybe, there is nothing Scala specific in this PR, unless I'm wrong.

Great.

what happened to buildTargetInverseSources here?

Ops, reverting

Added it back

To me as uninvolved person the use case is not really clear. Can you explain a bit more what this means and why it warrants a separate request?

Basically scala scripts are not "real" scala code, they are text files that can become Scala code only after wrapping them with some code to make them real.

For example:

println("Hello world!")

doesn't compile in Scala.

But if you wrap the code with:

val top = s"""object main {
  def main(args: Array[String]): Unit = {
"""

and

val bottom = """  }
}
"""

it becomes valid Scala code.

Since it's not valid Scala code, IDEs can't parse them correctly, unless you tell them about this processing. scala-cli created this extension to have IDE supports on ammonite and scala-cli scripts.

Of course what I said should be better summarized and added to the documentation as javadcod and smithy comment.

why it warrants a separate request?

This I don't know. I'm just following what's there since this is already used by scala-cli as a bespoke extension. If this can be achieved in a better way, let me know, I'm happy to update the PR.
I'm not very familiar with the BSP protocol other than some bugfixes I did in the Mill's implementation.

These duplicate entries don't look right.

Also, boolean would be the better type here, since it can't be null.

This value is uninitialized, like all the others. Better use boolean for such simple on/off settings.

Do we really need to add a new request for this? Or should we consider "wrapped sources" as part of buildTarget/sources ?

I would rather go with the second option, and add the optional topWrapper, bottomWrapper to the SourceItem:

structure SourceItem {
  @required  
  uri: URI;
  @required   
  kind: SourceItemKind;
  @required  
  generated: boolean;
  // optional
  topWrapper: String;
  // optional
  bottomWrapper: String
}

Or even better:

structure SourceItem {
  @required  
  uri: URI;
  @required   
  kind: SourceItemKind;
  @required  
  generated: boolean;
  // optional
  wrapper: SourceWrapper;
}

structure SourceWrapper {
  @required  
  prefix: String;
  @required   
  suffix: String;
}

We also need to add generatedUri to have the link, right?

Oh yes I missed that part.

So it seems a "wrapped source" is the source of a generated source file. And we want to have the support of our IDE in it because it looks a lot like a Scala file.

But this seems to be a special case of something more general which are the source files of source generation. In this case it is an sc file that generates a Scala file, but it could also be a proto, json, smithy or twirl file that generates Scala code.

So can we generalize that request? Something like this maybe:

@jsonRequest("buildTarget/sourceGenerationSources")
operation BuildTargetSourceGenerationSources {
    input: SourceGenerationSourcesParams
    output: SourceGenerationSourcesResult
}

structure SourceGenerationSourcesItem {
  @required
  uri: String
  @required
  generatedUri: String
  // optional
  data: SourceGenerationSourcesItemData
}

// in the scala extension
@dataKind(kind: "wrapped-scala-source", extends: [SourceGenerationSourcesItemData])
structure WrappedScalaSource {
    @required
    prefix: String
   @required
    suffix: String
}