As discussed before, there will be at least 2 ways developers can work with JavaFX 11 and beyond: 1. use the standalone SDK, with platform-specifc distributions 2. use artifacts on (remote) repositories
For the second option, we have to distinguish between build systems (e.g. maven/gradle) and repositories (e.g. maven central). When we put artifacts on remote repositories (e.g. maven central), the build systems will download them, analyse the dependencies, and transitively download other dependencies. Build systems at the very least allow developers to compile Java code, so they have the notion of classpath/modulepath. With the work done in PR#83 ( https://github.com/javafxports/openjdk-jfx/pull/83) we are ready to upload artifacts to remote repositories. While it is working with both maven and gradle, I'm not 100% happy yet, but I don't think there is a perfect solution. Maven and gradle rely on the concept of a pom file to define dependencies, while the Java Module System depends on a module-info file. While those 2 concepts target different aspects of the lifecycle, there is overlap. If we offer 2 options (standalone SDK and remote artifacts), the most important requirement is that developers can easily switch between these options without changing a single line of code in a .java file. As a consequence, the module-info.java need to work with standalone SDK's and remote artifacts. If an application declares a requirement on javafx.controls, that should be in its module-info.java. Next, when the javafx controls module is installed, its module-info.class should be independent on how it is installed (either available in the SDK or via a remote repository) As long as maven or gradle don't analyse module-info files inside jars, we have to use the pom dependencies to make sure maven/gradle understand that using javafx.controls implies using javafx.graphics. So far no problems, this can be automated (see https://github.com/javafxports/openjdk-jfx/pull/83/files#diff-c197962302397baf3a4cc36463dce5eaR1583) in our build.gradle. The pom files will have a dependency for every project dependency. The difficulty is in handling platform-specific installations in a standardized way, taking into account the existing reality. Some JavaFX modules require platform-dependent native libraries, and/or contain platform-specific class files (e.g. d3d files only make sense on windows). In the standalone SDK's, this is solved by having completely separate downloads for each platform. The way we did it in PR #83 is more or less similar: we have different artifacts for the different platforms. where we use a classifier for determining which platform is needed. This ensures that if you depend on e.g. javafx.controls for linux, the build system (maven/gradle) will also make sure to download javafx.graphics for linux. This information is in the pom.xml, as the module-info.java is platform-independent. We have a parent file called javafx.pom ( https://github.com/javafxports/openjdk-jfx/pull/83/files#diff-767d20a82f9dd4b7e319feefc33b89e6) that sets the classifier to ${javafx.platform} which is initialized to ${ os.name}. That parameter is available on maven, so if you use maven and don't do a cross-platform build, not specifying a platform will download the artifacts for your specific platform. If you're using gradle, or want to do a cross-platform build. you have to specify the platform you want to use. It seems to me this system is most close to what developers currently are used to. - Johan