scalacenter/bloop

Jean-Luc Deprez

@spangaer

if I'm not mistaken bloopInstall should generate json files in .bloop of the depending project, also for the source dependencies, but it no longer seems to do that

now, whether I use an older version or sbt 1.4.9 + bloop 1.4.8, nothing really seems to make it work

if I use SBT metals it finds the project refs just fine. I can even navigate to the source, that is not in mapped in to the workspace, without issues.

Jean-Luc Deprez

@spangaer

only sbt debug adaptor doesn't look to respect the setting ThisBuild / run / javaHome when forking the new process and that again brings me in to trouble

Vadim Chelyshov

@dos65

@spangaer The problem might be not related to the bloop setting you mentioned. As I see it's true by default - https://github.com/scalacenter/bloop/blob/master/integrations/sbt-bloop/src/main/scala/bloop/integrations/sbt/SbtBloop.scala#L142

Jean-Luc Deprez

@spangaer

just thought of something, would it make a difference if I add the bloop plugin to the depended project?

Jean-Luc Deprez

@spangaer

and the answer is -> yes (I figured it out when I was building a reproducer)
well, that was painful :|

I must have added it back then, while experimenting with this feature, but never have committed it.

Jean-Luc Deprez

@spangaer

So for Google, a small recap
For bloop source dependencies to work, the bloop sbt plugin needs to be defined in both the depending as the dependency sbt project.
Once configured bloopInstall on the depending project will generate <project>.json files for the dependency projects in the depending project .bloop folder.

Jean-Luc Deprez

@spangaer

Thanks for your responses btw!

Dan Gravell

@gravelld

I'm trying to install and compile some Scala projects which are part of a Gradle multi module build. End result is I want to use Metals, but Metals isn't playing nice, so I thought trying to compile via bloop might be a good first step to work out what is happening.

I have installed bloop. However, when I run the compile I just get nothing:

$ bloop compile com.elsten.google.gson
$

I'm guessing this is a common issue but I can't find any docs about this...

$ cat .bloop/com.elsten.google.gson.json 
{
    "version": "1.4.0",
    "project": {
        "name": "com.elsten.google.gson",
        "directory": "/home/gravelld/git-repo/com.elsten.google.gson",
        "workspaceDir": "/home/gravelld/git-repo/elsten-software_bliss",
        "sources": [
            "/home/gravelld/git-repo/com.elsten.google.gson/src/main/java"
        ],
        "dependencies": [

        ],
        "classpath": [

        ],
        "out": "/home/gravelld/git-repo/elsten-software_bliss/.bloop/com.elsten.google.gson/build",
        "classesDir": "/home/gravelld/git-repo/elsten-software_bliss/.bloop/com.elsten.google.gson/build/classes",
        "resources": [
            "/home/gravelld/git-repo/com.elsten.google.gson/src/main/resources"
        ],
        "java": {
            "options": [
                "-source",
                "1.8",
                "-target",
                "1.8",
                "-h",
                "/home/gravelld/git-repo/com.elsten.google.gson/build/generated/sources/headers/java/main",
                "-g",
                "-sourcepath",
                "-proc:none",
                "-XDuseUnsharedTable=true"
            ]
        },
        "platform": {
            "name": "jvm",
            "config": {
                "home": "/usr/lib/jvm/adoptopenjdk-11-hotspot-amd64",
                "options": [

                ]
            },
            "mainClass": [

            ],
            "classpath": [

            ]
        },
        "tags": [
            "library"
        ]
    }
}

Dan Gravell

@gravelld

$ bloop compile --verbose com.elsten.google.gson
[D] Loading workspace settings from bloop.settings.json
[D] Computing sources and classpath hashes for com.elsten.google.gson
[D] Scheduling compilation for com.elsten.google.gson...
[D] Ignoring analysis for com.elsten.google.gson, directory /home/gravelld/git-repo/elsten-software_bliss/.bloop/com.elsten.google.gson/build/classes-empty-com.elsten.google.gson is missing
[D] Increasing counter for /home/gravelld/git-repo/elsten-software_bliss/.bloop/com.elsten.google.gson/build/classes-empty-com.elsten.google.gson to 5
[D] Recording new last successful request for com.elsten.google.gson associated with /home/gravelld/git-repo/elsten-software_bliss/.bloop/com.elsten.google.gson/build/classes-empty-com.elsten.google.gson
[D] Elapsed: 10.682663 ms

$ bloop compile --debug com.elsten.google.gson
Unrecognized log context: com.elsten.google.gson

Tomasz Godzik

@tgodzik

@gravelld this might have something to do with the support for java only projects

there is some work being done scalameta/metals#2520

but it's not finished

but it seems that Bloop itself compiles it correctly?

are there class files in .bloop/com.elsten.google.gson/build/classes-empty-com.elsten.google.gson ?

Dan Gravell

@gravelld

Thanks - that folder doesn't exist:

$ ls .bloop/com.elsten.google.gson/build/classes-empty-com.elsten.google.gson 
ls: cannot access '.bloop/com.elsten.google.gson/build/classes-empty-com.elsten.google.gson': No such file or directory

It suggests that in the verbose compilation above:

[D] Ignoring analysis for com.elsten.google.gson, directory /home/gravelld/git-repo/elsten-software_bliss/.bloop/com.elsten.google.gson/build/classes-empty-com.elsten.google.gson is missing

Not sure what this is to do with Java only projects? The project I'm trying to compile is not dependent on any source projects, Java or otherwise:

apply plugin: 'scala'
apply plugin: 'maven-publish'

version = '0.1'

dependencies {

    compile libraries.scala_library
    compile libraries.gson

}

In the root project, we do add the java plugin to sub-projects:

allprojects {

    apply plugin: 'java'
    apply plugin: 'bloop'
        ...

So com.elsten.google.gson is both a Java, Scala and bloop project.

Tomasz Godzik

@tgodzik

are there any classfiles at all in .bloop folder?

Dan Gravell

@gravelld

Nope:

$ find .bloop/ -name *.class
$

Dan Gravell

@gravelld

Here's what I have in the build folder:

$ tree .bloop/com.elsten.google.gson/build/
.bloop/com.elsten.google.gson/build/
└── bloop-bsp-clients-classes
    ├── classes-bloop-cli
    └── classes-Metals-m_RT1-QXSXi0_gWM4JP_2g==

And no classes in there, as above.

Tomasz Godzik

@tgodzik

ok, that one is pretty weird. It seems like Bloop is misbehaving in this case

Are you able to compile any Scala targets?

and do they produce anything?

it's kind of unexpected that nothing would get produced

could you maybe report the issue in Bloop itself? One of the contributors might be able to help more with the Gradle build

I also added some questions in the Metals issue, we could discuss it more there

Ievgen Medvediev

@eugenemedvediev

Please help me to setup bloop with support of debugging user code.
I have bloop installed through cs.

bloop v1.4.8

Using Scala v2.12.8 and Zinc v1.3.0-M4+46-edbe573e
Running on Java JRE v1.8.0_281 (/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home)
  -> Doesn't support debugging user code, runtime doesn't implement Java Debug Interface (JDI).
Maintained by the Scala Center (Jorge Vicente Cantero, Martin Duhem)

also I use graalvm-ce-java11:21.0.0 through cs:

❯ cs java --jvm graalvm-ce-java11:21.0.0 --env
export JAVA_HOME="/Users/ievgen/Library/Caches/Coursier/jvm/graalvm-ce-java11@21.0.0/Contents/Home"

~/projects/scalapi/smartmeter
❯ java --version
openjdk 11.0.10 2021-01-19
OpenJDK Runtime Environment GraalVM CE 21.0.0 (build 11.0.10+8-jvmci-21.0-b06)
OpenJDK 64-Bit Server VM GraalVM CE 21.0.0 (build 11.0.10+8-jvmci-21.0-b06, mixed mode, sharing)

According to documentation I set custom javaHome in ~/.bloop/bloop.json:

❯ bat ~/.bloop/bloop.json
───────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
       │ File: /Users/ievgen/.bloop/bloop.json
───────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   1   │ {
   2   │   "javaHome": "/Users/ievgen/Library/Caches/Coursier/jvm/graalvm-ce-java11@21.0.0/Contents/Home"
   3   │ }
───────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Ievgen Medvediev

@eugenemedvediev

still bloop about shows that it uses JRE v1.8.0
and during executing run command from nvim-dap I have this error message:

Run bloop about for more information about the current JDK runtime.
        at scala.meta.internal.metals.BuildServerConnection$$anonfun$1.applyOrElse(
BuildServerConnection.scala:237)
        at scala.meta.internal.metals.BuildServerConnection$$anonfun$1.applyOrElse(
BuildServerConnection.scala:229)
        at scala.concurrent.Future.$anonfun$recoverWith$1(Future.scala:417)
        at scala.concurrent.impl.Promise.$anonfun$transformWith$1(Promise.scala:41)
        ... 4 more

Tomasz Godzik

@tgodzik

@eugenemedvediev did you restart Bloop after changing bloop.json ?

Dan Gravell

@gravelld

Thanks @tgodzik - I'm not able to compile any scala targets. I opened #1488 .

Ievgen Medvediev

@eugenemedvediev

@tgodzik yes, I did :MetalsRestartServer ( in nvim-metals ). And still I have the same error message.
I think bloop about somehow should catch my currend jdk. How exactly bloop decides with what java should it work?

Chris Kipp

@ckipp:matrix.org

[m]

If you are using nvim-metals @eugenemedvediev you should actually just be able to set the javaHome https://github.com/scalameta/nvim-metals/blob/94ecdde0a0a72665f61cf00a428e7236f3da236e/doc/metals.txt#L244-L250 setting which will tell Metals which to use

for example in your project you should be able to do a bloop exit, change the setting, restart the server, and then it will both start Metals and Bloop with that java home that you passed in

Anton Sviridov

@velvetbaldmime:matrix.org

[m]

I want to publish bloop locally, but after 1) checking out 2) initialising the submodules I get this:

[warn] There may be incompatibilities among your library dependencies; run 'evicted' to see detailed eviction warnings.
/tmp/tmp.zMH6hQoO24/bloop/frontend/src/test/resources/cross-test-build-scalajs-0.6/build.sbt:43: error: not found: value bloopMainClass
  bloopMainClass in (Compile, run) := Some("hello.DefaultApp")
  ^
/tmp/tmp.zMH6hQoO24/bloop/frontend/src/test/resources/cross-test-build-scalajs-0.6/build.sbt:47: error: not found: value bloopMainClass
  bloopMainClass in (Compile, run) := Some("hello.App"),
  ^

Is there an extra step? I tried it on a clean copy as well, to same result

Seems like this only happens if I just start sbt - sbt bloopInstall and sbt scripted both commands work, just can't get into the shell

Tomasz Godzik

@tgodzik

@velvetbaldmime:matrix.org might make sense to remove those project, I think they should get recreated on start

frontend/src/test/resources

alternatively, it can get recreated from git

Anton Sviridov

@velvetbaldmime:matrix.org

[m]

Should I read much in seemingly unrelated build failure? I can see master also failed recently, and what I get on my PR is gradle stuff

Tomasz Godzik

@tgodzik

yeah, that's msot likely unrelated. I need to tidy up there

Ievgen Medvediev

@eugenemedvediev

@tgodzik @ckipp:matrix.org problem solved automagically after restart of my mac, bloop about fetched correct version of jdk. So dap works in nvim-metals. I am happy

Thank you for help

Where communities thrive

People

Repo info

Activity