Open galderz opened 3 years ago
Never mind, all working in latest release.
Actually, still happens in latest release.
The issue is in the native-image
invocation, it should be filtering out tar.gz
dependencies:
[jbang] native-image: /opt/graalvm-ce-java11-20.3.0/bin/native-image -H:+ReportExceptionStackTraces --enable-https --class-path=/home/g/.m2/repository/org/graalvm/nativeimage/svm/20.3.0/svm-20.3.0.jar:/home/g/.m2/repository/org/graalvm/nativeimage/svm-hosted-native-linux-amd64/20.3.0/svm-hosted-native-linux-amd64-20.3.0.tar.gz:/home/g/.m2/repository/org/graalvm/nativeimage/svm-hosted-native-darwin-amd64/20.3.0/svm-hosted-native-darwin-amd64-20.3.0.tar.gz:/home/g/.m2/repository/org/graalvm/nativeimage/svm-hosted-native-windows-amd64/20.3.0/svm-hosted-native-windows-amd64-20.3.0.tar.gz:/home/g/.m2/repository/org/graalvm/sdk/graal-sdk/20.3.0/graal-sdk-20.3.0.jar:/home/g/.m2/repository/org/graalvm/nativeimage/objectfile/20.3.0/objectfile-20.3.0.jar:/home/g/.m2/repository/org/graalvm/nativeimage/pointsto/20.3.0/pointsto-20.3.0.jar:/home/g/.m2/repository/org/graalvm/truffle/truffle-nfi/20.3.0/truffle-nfi-20.3.0.jar:/home/g/.m2/repository/org/graalvm/truffle/truffle-api/20.3.0/truffle-api-20.3.0.jar:/home/g/.m2/repository/org/graalvm/truffle/truffle-nfi-native-linux-amd64/20.3.0/truffle-nfi-native-linux-amd64-20.3.0.tar.gz:/home/g/.m2/repository/org/graalvm/truffle/truffle-nfi-native-linux-aarch64/20.3.0/truffle-nfi-native-linux-aarch64-20.3.0.tar.gz:/home/g/.m2/repository/org/graalvm/truffle/truffle-nfi-native-darwin-amd64/20.3.0/truffle-nfi-native-darwin-amd64-20.3.0.tar.gz:/home/g/.m2/repository/org/graalvm/compiler/compiler/20.3.0/compiler-20.3.0.jar -jar /home/g/.jbang/cache/jars/example.java.d12f7cf0cbc6169d2c6c8f0bf9e23e3479b32a871a7bcf5d492d5c052db2d981.jar /home/g/.jbang/cache/jars/example.java.d12f7cf0cbc6169d2c6c8f0bf9e23e3479b32a871a7bcf5d492d5c052db2d981.jar.bin
[jbang] log: /tmp/jbang7086977838214726527native-image
Error: Invalid or corrupt jarfile /home/g/.m2/repository/org/graalvm/nativeimage/svm-hosted-native-linux-amd64/20.3.0/svm-hosted-native-linux-amd64-20.3.0.tar.gz
Why are there tar.gz in the classpath dependencies to begin with ?
I definitely don't know how Maven categorizes its artifacts, but might this be because the .tar.gz contains platform binaries and are therefore be considered executable code?
Would be good with some test case?
@galderz do you have a jbang example that fails we can use as testcase ?
so .. i'm looking at //DEPS org.graalvm.nativeimage:svm:20.3.0
and for me if you don't want that on the classpath don't include it.
Are you in a case where you have that artifact as a transitive dependency on a project ?
also, I can't get it to fail:
///usr/bin/env jbang "$0" "$@" ; exit $?
//DEPS org.graalvm.nativeimage:svm:20.3.0
//DEPS log4j:log4j:1.2.17
import static java.lang.System.out;
import org.apache.log4j.Logger;
import org.apache.log4j.BasicConfigurator;
import java.util.Arrays;
class classpath_example {
static final Logger logger = Logger.getLogger(classpath_example.class);
public static void main(String[] args) {
BasicConfigurator.configure();
logger.info("Welcome to jbang");
Arrays.asList(args).forEach(arg -> logger.warn("arg: " + arg));
}
}
The above just works and that includes .tar.gz on the classpath:
{
"originalResource": "classpath_example.java",
"backingResource": "classpath_example.java",
"resolvedDependencies": [
"/Users/max/.m2/repository/org/graalvm/nativeimage/svm/20.3.0/svm-20.3.0.jar",
"/Users/max/.m2/repository/org/graalvm/nativeimage/svm-hosted-native-linux-amd64/20.3.0/svm-hosted-native-linux-amd64-20.3.0.tar.gz",
"/Users/max/.m2/repository/org/graalvm/nativeimage/svm-hosted-native-darwin-amd64/20.3.0/svm-hosted-native-darwin-amd64-20.3.0.tar.gz",
"/Users/max/.m2/repository/org/graalvm/nativeimage/svm-hosted-native-windows-amd64/20.3.0/svm-hosted-native-windows-amd64-20.3.0.tar.gz",
"/Users/max/.m2/repository/org/graalvm/sdk/graal-sdk/20.3.0/graal-sdk-20.3.0.jar",
"/Users/max/.m2/repository/org/graalvm/nativeimage/objectfile/20.3.0/objectfile-20.3.0.jar",
"/Users/max/.m2/repository/org/graalvm/nativeimage/pointsto/20.3.0/pointsto-20.3.0.jar",
"/Users/max/.m2/repository/org/graalvm/truffle/truffle-nfi/20.3.0/truffle-nfi-20.3.0.jar",
"/Users/max/.m2/repository/org/graalvm/truffle/truffle-api/20.3.0/truffle-api-20.3.0.jar",
"/Users/max/.m2/repository/org/graalvm/truffle/truffle-nfi-native-linux-amd64/20.3.0/truffle-nfi-native-linux-amd64-20.3.0.tar.gz",
"/Users/max/.m2/repository/org/graalvm/truffle/truffle-nfi-native-linux-aarch64/20.3.0/truffle-nfi-native-linux-aarch64-20.3.0.tar.gz",
"/Users/max/.m2/repository/org/graalvm/truffle/truffle-nfi-native-darwin-amd64/20.3.0/truffle-nfi-native-darwin-amd64-20.3.0.tar.gz",
"/Users/max/.m2/repository/org/graalvm/compiler/compiler/20.3.0/compiler-20.3.0.jar",
"/Users/max/.m2/repository/log4j/log4j/1.2.17/log4j-1.2.17.jar"
]
}
so please provide and actual usecase that fails - maybe you are using a specific javavm that are being picky ?
From official java docs https://docs.oracle.com/javase/7/docs/technotes/tools/windows/classpath.html:
"Classpath entries that are neither directories nor archives (.zip or .jar files) nor * are ignored."
Thus unless you can highlight a usecase that fails I feel the correct thing here is to close this as working as expected (i.e. user add dependency then he has a reason).
@maxandersen I might be misreading the issue, but I think @galderz mentions it's in the call the native-image
where things go wrong. So perhaps it's javac
that has no problem with it but only native-image
?
That could be - native-image
should fix its issue and if jbang needs fixing in call to native-image I wanna get the usecase where you ever ends up with tgz on the classpath without you specifying the the tgz dependency.
Yeah, it's the native-image
call that breaks here.
I'll open a new issue for native-image
and link it here.
Cool - we can fix it for the native image specific call if we must. But great if can be fixed upstream.
Still, what's the actual usecase where you have to include this dependency ?
@maxandersen Use SVM API directly, e.g. register reflection programmatically. You can do other stuff like substitute methods...etc.
The linked issue is closed as resolved so we probably need to test if this works now with the latest GraalVM ?
@galderz you able to verify this works ?
Not yet fully working, see https://github.com/oracle/graal/issues/3467.
JBang having issues with SVM dependencies:
The dependency is
//DEPS org.graalvm.nativeimage:svm:20.3.0
. JBang should be ignoring thattag.gz
file.