jbang icon indicating copy to clipboard operation
jbang copied to clipboard

Scripts and jars dependencies are not really resolved by `jbang info tools`

Open fbricon opened this issue 2 years ago • 9 comments

JBang scripts referencing remote scripts via //DEPS (since v0.109.0), can not work in the IDE until the first jbang build, as jbang info tools do not actually build those resolved dependencies

For instance, given this:

//DEPS https://github.com/jbangdev/jbang-catalog/blob/main/httpd.java

import java.io.IOException;

public class hello {

	public static void main(String[] args) throws IOException {
		httpd.main(new String[] { "--port=8080" });
	}
}

if you rm -rf ~/.jbang/cache/jars/httpd*, then you'll see info tools still returns the path to the resolved httpd jar:

➜  jbang info tools hello.java
{
  "originalResource": "hello.java",
  "backingResource": "/Users/fbricon/Dev/souk/bling/hello.java",
  "applicationJar": "/Users/fbricon/.jbang/cache/jars/hello.java.108756c565cca1f6552556c51fea51b3336e8fc6ca0952ae1f1cca2a05697e45/hello.jar",
  "dependencies": [
    "info.picocli:picocli:4.6.3"
  ],
  "resolvedDependencies": [
    "/Users/fbricon/.m2/repository/info/picocli/picocli/4.6.3/picocli-4.6.3.jar",
    "/Users/fbricon/.jbang/cache/jars/httpd.java.eb64871556b143b871ae3cbb0eeb4009b53fcfd854dc87b867e3dff4e7144448/httpd.jar"
  ],
  "availableJdkPath": "/Users/fbricon/.sdkman/candidates/java/17.0.7-tem",
  "compileOptions": [
    "-g"
  ],
  "sources": [
    {
      "originalResource": "hello.java",
      "backingResource": "/Users/fbricon/Dev/souk/bling/hello.java"
    }
  ]
}
➜  ls /Users/fbricon/.jbang/cache/jars/httpd.java.eb64871556b143b871ae3cbb0eeb4009b53fcfd854dc87b867e3dff4e7144448/httpd.jar
ls: /Users/fbricon/.jbang/cache/jars/httpd.java.eb64871556b143b871ae3cbb0eeb4009b53fcfd854dc87b867e3dff4e7144448/httpd.jar: No such file or directory

But after the actual JBang build, the jar will exist:

➜  jbang hello.java
[jbang] Building jar for httpd.java...
[jbang] Building jar for hello.java...
Hello again World!
usage: httpd [-h] [-b bind address] [-p port] [-d directory] [-o none|info]

Serves directory content over http.

➜  ls /Users/fbricon/.jbang/cache/jars/httpd.java.eb64871556b143b871ae3cbb0eeb4009b53fcfd854dc87b867e3dff4e7144448/httpd.jar
/Users/fbricon/.jbang/cache/jars/httpd.java.eb64871556b143b871ae3cbb0eeb4009b53fcfd854dc87b867e3dff4e7144448/httpd.jar

No, in the context of jbang-eclipse (prolly jbang-idea too), this will create a reference to an missing jar, which will prevent the project to build.

Expected behavior info tools should build the dependencies if needed

JBang version

[jbang] [0:643] jbang version 0.109.0 Cache: /Users/fbricon/.jbang/cache Config: /Users/fbricon/.jbang Repository:/Users/fbricon/.m2/repository 0.109.0`

fbricon avatar Jul 08 '23 12:07 fbricon

Does the missing jar itself make an error or is that it can't find the missing classes?

About building on info we need to be careful as we don't really want it to fail delivering the info if there a build errors.

maxandersen avatar Jul 08 '23 16:07 maxandersen

both Screenshot 2023-07-08 at 18 25 38

fbricon avatar Jul 08 '23 16:07 fbricon

BTW I can handle invalid URLs (bits not published yet) Screenshot 2023-07-08 at 18 28 44

fbricon avatar Jul 08 '23 16:07 fbricon

if you rm -rf ~/.jbang/cache/jars/httpd*, then you'll see info tools still returns the path to the resolved httpd jar:

Actually that's always the case, you could do the same for the hello script. Info tools will always return the path where the JAR is, or will be!

Also, info tools never builds, and that's on purpose, it will give you as much information as it can with the current situation.

If a build is necessary for the IDE to work then I'd test that all the resolvedDependencies are actually available and if not call jbang build.

quintesse avatar Jul 08 '23 20:07 quintesse

Could we have `jbang info tools --resolve" option or a "jbang resolve" command?

fbricon avatar Jul 08 '23 20:07 fbricon

--resolve option that would be a best efffort build of source deps makes sense to me.

maxandersen avatar Jul 08 '23 20:07 maxandersen

I still feel that --resolve is not a good option, we're already "resolving", all artifacts get downloaded. The thing that the option would do is to build any scripts that are mentioned in any //DEPS lines, but not the main script itself. It's just a very weirdly specific option: --build-dependencies-only.

quintesse avatar Aug 03 '23 00:08 quintesse

Conceptually how is it different from resolve of github urls triggering builds in jitpack ?

maxandersen avatar Aug 03 '23 04:08 maxandersen

Completely, there it's a black box, it's something that's done completely transparently. You just end up with artifacts in your MAVEN_REPO. Except for the time it might take the first time there's nothing that indicates anything special is going on.

Here we're triggering builds, things that have obvious side-effects. For example it means you need a proper JDK, so suddenly the info command might trigger the download and install of a JDK (which it has never done before) and then it might also trigger multiple builds (also not done before) but it then adds this special condition where we say: "oh but don't actually build the main script itself".

It's mainly that special condition that bothers me. I'd almost prefer adding a --dependencies-only flag to the build command, because that command at least is supposed to build things. But is it possible to add a --resolve flag to the info command that will build everything but the main script? Sure.

Edit: we'll also need to add a couple more flags to support the fact that we'd now need to be able to build and install JDKs, so things like --java and --jdk-providers.

quintesse avatar Aug 03 '23 09:08 quintesse