jbangdev / jbang

Unleash the power of Java - JBang Lets Students, Educators and Professional Developers create, edit and run self-contained source-only Java programs with unprecedented ease.
https://jbang.dev
MIT License
1.43k stars 159 forks source link

pom dependency does import where it should do dependency include #1683

Open maxandersen opened 1 year ago

maxandersen commented 1 year ago

not sure how I missed this when I did pom dependency import.

truffle uses pom dependencies, which is handled as depend on the pom and get all its dependencies

// DEPS org.graalvm.polyglot:python-community:23.1.0@pom

unfortunately I missed that actually worked in maven and jbang currently used @pom to magically do that as a dependencymanagement import.

Meaning if we fix this, i.e. make // DEPS org.graalvm.polyglot:python-community:23.1.0@pom work as maven actually works we then need something like //DEPS(managed) org.graalvm.polyglot:python-community:23.1.0@pom we will break backwards compatibility on how pom deps works.

I'm inclined to think we'll need to break that backwards-compatibility but open to hear if some has suggestions on how to handle this in backwards compatability.

One stray thought is that since we need different kind of deps for build, runtime separation eventually ..maybe do:

//BDEPS for build dependencies, //RDEPS for runtime ...and those will treat @pom as include, rather than import...and thus:

//DEPS some.dep:4.2.3@pom (will be managed) //BDEPS my.app (will be included and get version from the managed)

downside is you can't then specify something that is both used at build and runtime....

....could also add a jbang --compatible flag of some sort that will keep the import behavior...

msgilligan commented 2 months ago

I think I'm running into this (or a related issue) while trying to use JBang to run the GraalWasm Demo.

///usr/bin/env jbang "$0" "$@" ; exit $?
//COMPILE_OPTIONS -source 21 --enable-preview
//RUNTIME_OPTIONS --enable-preview

//MODULE floyd
package floyd;

//DEPS org.graalvm.polyglot:wasm:24.0.2@pom
//DEPS org.graalvm.polyglot:polyglot:24.0.2
import org.graalvm.polyglot.*;
import org.graalvm.polyglot.io.ByteSequence;

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Paths;

public class GraalWasmDemo {
    void main() throws IOException {
        // Load the WebAssembly contents into a byte array
        byte[] binary = Files.readAllBytes(Paths.get("floyd.wasm"));

        // Setup context
        Context.Builder contextBuilder = Context.newBuilder("wasm").option("wasm.Builtins", "wasi_snapshot_preview1");
        Source.Builder sourceBuilder = Source.newBuilder("wasm", ByteSequence.create(binary), "example");
        Source source = sourceBuilder.build();
        Context context = contextBuilder.build();

        // Evaluate the WebAssembly module
        context.eval(source);

        // Execute the floyd function
        context.getBindings("wasm").getMember("example").getMember("_initialize").executeVoid();
        Value mainFunction =context.getBindings("wasm").getMember("example").getMember("floyd");
        mainFunction.execute();
        context.close();
    }
}

The output I get is:

[jbang] Building jar for GraalWasmDemo.java...
Exception in thread "main" java.lang.IllegalStateException: No language and polyglot implementation was found on the module-path. Make sure at last one language is added to the module-path. 
    at org.graalvm.polyglot.Engine$PolyglotInvalid.noPolyglotImplementationFound(Engine.java:2130)
    at org.graalvm.polyglot.Engine$PolyglotInvalid.buildSource(Engine.java:2217)
    at org.graalvm.polyglot.Engine$PolyglotInvalid.buildSource(Engine.java:2087)
    at org.graalvm.polyglot.Source$Builder.build(Source.java:920)
    at floyd.GraalWasmDemo.main(GraalWasmDemo.java:25)
maxandersen commented 2 months ago

Yeah. It was trying out Graal project that is the rare use of pom i spotted it too :/ really need to make it happen

For now the workaround is to include the pom + individual dependencies but without version.