Automatic arch support

[ia3andy]

Hello Javet team,

In the Quarkus eco-system we have the https://github.com/quarkiverse/quarkus-web-bundler which allows to seamlessly bundle scripts and styles. It relies on esbuild-java and mvnpm that we created for this purpose.

We are working on improving our esbuild-java tooling to use javet. It previously used the native esbuild CLI but wasn't supporting plugins. Our POC is working and we will probably continue on this road.

The issue now is that we don't want to include all arch as dependencies because of the size.

Using arch based profiles with dependencies works using Maven, but it doesn't with Gradle.

It seems gradle provides it's own system using configurations and attributes, I've tried this but I am not very familiar with Gradle:

val linuxX86 = configurations.create("linuxX86_64") {
    isCanBeResolved = false
    isCanBeConsumed = true
    attributes {
        attribute(
            org.gradle.nativeplatform.OperatingSystemFamily.OPERATING_SYSTEM_ATTRIBUTE,
            objects.named("linux")
        )
        attribute(
            org.gradle.nativeplatform.MachineArchitecture.ARCHITECTURE_ATTRIBUTE,
            objects.named("x86_64")
        )
    }
}

val macosArm64 = configurations.create("macosArm64") {
    isCanBeResolved = false
    isCanBeConsumed = true
    attributes {
        attribute(
            org.gradle.nativeplatform.OperatingSystemFamily.OPERATING_SYSTEM_ATTRIBUTE,
            objects.named("macos")
        )
        attribute(
            org.gradle.nativeplatform.MachineArchitecture.ARCHITECTURE_ATTRIBUTE,
            objects.named("aarch64")
        )
    }
}

dependencies {
    add("linuxX86_64", "com.caoccao.javet:javet-node-linux-x86_64:4.1.3")
    add("macosArm64", "com.caoccao.javet:javet-node-macos-arm64:4.1.3")
}

Would you consider making something like this part of your implementation since you are using Gradle as build system? Or at least in a specific artifact such as com.caoccao.javet:javet-node-auto-arch or similar?

Thanks for your library.

[ia3andy]

FYI, I would be happy to contribute this if you think it is a good idea..

[caoccao]

In Gradle, you get this out-of-box. Please review this doc.

import org.gradle.internal.os.OperatingSystem

val os = OperatingSystem.current()
val arch = System.getProperty("os.arch")
val version = "4.1.5"
val isI18n = false
val isNode = false
val i18nType = if (isI18n) "-i18n" else ""
val jsRuntimeTimeType = if (isNode) "node" else "v8"
val osType = if (os.isWindows) "windows" else
    if (os.isMacOsX) "macos" else
    if (os.isLinux) "linux" else ""
val archType = if (arch == "aarch64" || arch == "arm64") "arm64" else "x86_64"
implementation("com.caoccao.javet:javet:$version")
implementation("com.caoccao.javet:javet-$jsRuntimeTimeType-$osType-$archType$i18nType:$version")

[ia3andy]

What I mean is, I believe this could be achieved at Javet level. The user would just have to add the dependency without any extra configuration both on Gradle or Maven.

This also allow using Javet in a library, because you can't expect the users of the library to add this extra config to their project.

[caoccao]

I doubt that because i18n cannot be handled this way.

[ia3andy]

I doubt that because i18n cannot be handled this way.

Any reason why?

In Maven, the arch based profile are working transitively. In Gradle, it's the same but using the attribute like I mentioned in the issue.

So in the end it will be the exact same as adding the arch dependency in your pom or gradle build file, is there anything different about i18n types?

[caoccao]

Also, the majority of Javet users sometimes build their applications for Windows or MacOS on Linux. They can explicitly declare the dependencies.

Javet tends to be as less intrusive as possible. If you want that feature, you may create a config only project with the resolution algorithm you want and let people reference your project.

[ia3andy]

@caoccao I am not sure you understood what I am suggesting.

I am not saying to change the current approach, adding an extra module that allow user to make it automatic is just easier to use, it would work on windows, mac and linux.

If a user wants to add the specific dependency, it would of course still be possible.

The resolution algorithm I am suggesting for this new module is a standard resolution algo that would work on any arch.

[ia3andy]

Maybe I am missing something, that's also a possibility :)

[ia3andy]

I will create a module in our project to do this, I'll ping you when it's available (if I manage to make it work because I am not 100% sure about Gradle yet) and you can decide whether it's worth integrating.

[caoccao]

I appreciate that if you could create a PoC project demonstrating the idea and I would validate it with some common use cases. And yes, if it worked well, why not include it.