Dmitrii Naumenko

If we agree on this I could prepare a PR

@olafurpg Can private field removal break the clients? API will be unchanged: `getJars` public method will remain, though deprecated.

Ahh, I opened this repo for the first time and only saw `ch.epfl.scala.bsp4j.ScalaBuildTarget`. Now I also see `ScalaExtension.xtend` and `ch.epfl.scala.bsp.ScalaBuildTarget` Am I right that it's the main protocol description part...

Ok. Let's agree on what exactly to keep: `scaladocJars` (42 jars including duplicated duplicating scalacJars) or `scaladocExtraJars` ( (29 extra jars, which should be added to the scala compiler jars)

For Scala 2 it does, but the classpath just equals the compiler classpath. For Scala 3 it doesn't yet, because scaladoc generation is not supported yet: https://youtrack.jetbrains.com/issue/SCL-17219. >Maybe we can...

>That's also an option. So that implies that BSP implementations need to fix their implementation not to include redundant classpath jars to `ScalaBuildTarget.jars`?

still an issue in 1.4.0

Somehow similar issue in IntelliJ Scala Plugin: https://youtrack.jetbrains.com/issue/SCL-20122 (see the [comment](https://youtrack.jetbrains.com/issue/SCL-20122/Scala-comment-rendering-does-not-correctly-support-ScalaDoc-macr#focus=Comments-27-6030602.0-)) From https://docs.scala-lang.org/overviews/scaladoc/for-library-authors.html#macros >`@define ` **allows use of `$name`** in other Scaladoc comments **within the same source file** which will...

Looks like the specification implies that macro can be used in unrelated classes in the same file. There is nothing about inheritance. So you do not even need to inherit...

Faced same exception in 2.13.7. Can't create a minimum reproducible example yet.