You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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...
The text was updated successfully, but these errors were encountered:
[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)
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...The text was updated successfully, but these errors were encountered: