Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can we allow setting JavaFXPlatform? #99

Open
shahzaibj opened this issue Apr 28, 2021 · 9 comments
Open

Can we allow setting JavaFXPlatform? #99

shahzaibj opened this issue Apr 28, 2021 · 9 comments

Comments

@shahzaibj
Copy link

shahzaibj commented Apr 28, 2021

It seems platform is currently detected here: https://github.com/openjfx/javafx-gradle-plugin/blob/master/src/main/java/org/openjfx/gradle/JavaFXOptions.java#L60

Is setting this / overriding this currently supported? Didn't seem so from documentation.

Basically instead of detecting, can we make an option in the plugin configuration similar to how modules and version is configurable?

The idea is that a developer may be developing on platform A but wants to produce artifact for platform B.

For instance, someone may be writing code on Windows, but when they actually are about to produce an artifact by calling a gradle task such as assemble then they may change this to Linux or MacOs.

@abhinayagarwal
Copy link
Collaborator

Can you add a use-case for this request?

@shahzaibj
Copy link
Author

@abhinayagarwal Added use-case in the description:

The idea is that a developer may be developing on platform A but wants to produce artifact for platform B.

For instance, someone may be writing code on Windows, but when they actually are about to produce an artifact by calling a gradle task such as assemble then they may change this to Linux or MacOs.

@shahzaibj
Copy link
Author

@abhinayagarwal I've tried to address it myself here: #103

(I wasn't able to request review from anyone...I believe some permissions are needed to be able to do that)

@swende
Copy link

swende commented May 27, 2021

The possibility to configure the platform itself is really an essential feature.

For example, we want to build our JavaFX application automatically for different platforms. Since the whole thing is built via a cloud infrastructure on Linux servers, we would have to have a way to configure the target platform (mac, win, lin) for the individual builds.

What else would be needed to review and integrate that PULL request?

@nanodeath
Copy link

Want to +1 this with the same use case as others. I want to use something like TravisCI to generate artifacts for my application, but their Windows support is experimental, and their Windows+Java support is nonexistent; thus, it's impractical, and also somewhat pointless, to get my project to build inside a Windows virt.

But we're not actually compiling native code anyway, so I could just as easily generate the Windows build on the much-better supported Linux systems, except...there's no way to tell this plugin to actually build for a different OS.

@nanodeath
Copy link

For the extra impatient, this atrocity seems to work for me -- lets me specify an environment variable to change the platform. Note that it's written in build.gradle.kts, but I tried to keep it simple:

import org.openjfx.gradle.*

plugins {
    id("org.openjfx.javafxplugin") version "0.0.10"
    // ...
}

configure<JavaFXOptions> {
    version = "16"
    modules = listOf("javafx.controls", "javafx.swing")

    // Set JAVAFX_PLATFORM to "linux", "win", or "mac"
    val javafxPlatformOverride = System.getenv("JAVAFX_PLATFORM")
    if (javafxPlatformOverride != null) {
        val javafxPlatform: JavaFXPlatform = JavaFXPlatform.values()
            .firstOrNull { it.classifier == javafxPlatformOverride }
            ?: throw IllegalArgumentException("JAVAFX_PLATFORM $javafxPlatformOverride not in list:" +
                    " ${JavaFXPlatform.values().map { it.classifier }}")

        logger.info("Overriding JavaFX platform to {}", javafxPlatform)

        // Override the private platform field
        val platformField: Field = JavaFXOptions::class.java.getDeclaredField("platform")
        platformField.isAccessible = true
        platformField.set(this, javafxPlatform)

        // Invoke the private updateJavaFXDependencies() method
        val updateDeps: Method = JavaFXOptions::class.java.getDeclaredMethod("updateJavaFXDependencies")
        updateDeps.isAccessible = true
        updateDeps.invoke(this)
    }
}

@majerm
Copy link

majerm commented Jul 19, 2021

My solution before this is merged is to clone repository, publish to maven local repository and use modified version of plugin:

git clone git@github.com:openjfx/javafx-gradle-plugin.git
# after clone I change version in build.gradle to '0.0.11-LOCAL' and apply changes from pullrequest
cd javafx-gradle-plugin
./gradlew clean build
./gradlew publishToMavenLocal

and in target project in settings.gradle:

pluginManagement {
    plugins {
        id 'org.openjfx.javafxplugin' version '0.0.11-LOCAL'
        ....
    }
    repositories {
        mavenLocal()
        mavenCentral()
        gradlePluginPortal()
    }
}

@nanodeath
Copy link

I did run into a fundamental problem with this ask, unfortunately. As far as this plugin is concerned, the only difference between platforms is which native JARs get bundled in. If you're actually trying to ship nice installer-wrapped software, you might have to build on the native platform anyway.

I haven't used it before, but I was planning on using jpackage, the new self-contained application package that shipped with JDK 14. It says this on its docs:

Packaging Pre-Reqs

Application packages must be built on the target platform. The system used for packaging must contain the application, a JDK, and software needed by the packaging tool.

To package your application for multiple platforms, you must run the packaging tool on each platform. If you want more than one format for a platform, you must run the tool once for each format.

So, getting this plugin to built cross-platform might be moot if the next step has to be run on a particular platform. I'd expect most installer-generators to have to be run on their native platform, but I'd love to be proven wrong there.

@shahzaibj
Copy link
Author

shahzaibj commented Jul 19, 2021

@nanodeath We can specify targetPlatform using the Runtime Plugin (which internally uses JPackage). However, since it allows us to specify targetPlatform, therefore we can build the installer for any platform from any platform.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants