Maven Central release requires a `osgi.platform` in a maven/gradle

[Rojods]

First, thanks a lot for the effort in releasing the artefacts to Maven Central since 2.3.0! I am sure it will help Klighd gain more critical mass in the long run!

Now, when I tried to fetch the latest standalone variant of the artifacts (as instructed, so I hope), I got an error:

Execution failed for task ':java-graphviz:compileJava'.
> Could not resolve all files for configuration ':java-graphviz:compileClasspath'.
   > Could not find org.eclipse.platform:org.eclipse.swt.${osgi.platform}:3.124.0.
     Searched in the following locations:
       - https://repo.maven.apache.org/maven2/org/eclipse/platform/org.eclipse.swt.${osgi.platform}/3.124.0/org.eclipse.swt.${osgi.platform}-3.124.0.pom
      If the artifact you are trying to retrieve can be found in the repository but without metadata in 'Maven POM' format, you need to adjust the 'metadataSources { ... }' of the repository declaration.
     Required by:
         project :java-graphviz > de.cau.cs.kieler.klighd:de.cau.cs.kieler.klighd.standalone:2.3.0.v20230606 > de.cau.cs.kieler.klighd:de.cau.cs.kieler.klighd:2.3.0.v20230606 > org.eclipse.platform:org.eclipse.swt:3.124.0

This makes me think that the variable osgi.platform would be trivially substituted in the original OSGi framework of Klighd, but here fails to succeed. I could try setting this in gradle somehow so that the variable gets substituted, but then I do not know the correct substitution.

Hope this is an easy fix either in the publishing flow or locally on my side!

PS:

The project that I handle and tries now to use the artifacts is ForSyDe IO.

[NiklasRentzCAU]

For this I can refer you over to the Lingua Franca project, they currently also use the Maven artifacts of KLighD to build a standalone application using the offscreen renderer with SWT. See this PR: lf-lang/lingua-franca#1713 From what they did for this substitution I guess looking at this and this change may solve your problem.

[Rojods]

@NiklasRentzCAU , thanks a lot! It has indeed solved the problem locally. On a side note, is it intentional that the "standalone" version of the tools requires SWT? I would have first thought that the standalone parts of the toolchain would be independent of a widget framework like SWT, but I I od not know if there are fundamental coupling between parts of Klighd and SWT :).

In any case, here are the additional lines (based on the PR changes) aside from the dependency that lead to a correct build, for future reference:

var os = org.gradle.nativeplatform.platform.internal.DefaultNativePlatform.currentOperatingSystem;
var arch = org.gradle.nativeplatform.platform.internal.DefaultNativePlatform.currentArchitecture.getName().replace("-", "_");
// due to the origin in an eclipse environment, the KIELER toolset requires SWT to be present
// this version must match wahtever the latest standalone Klighd is using
var swtVersion = "3.124.0"

configurations.all {
    resolutionStrategy {
        dependencySubstitution {
            // The maven property ${osgi.platform} is not handled by Gradle
            // so we replace the dependency, using the osgi platform from the project settings
            if (os.isWindows()) {
                substitute module('org.eclipse.platform:org.eclipse.swt.${osgi.platform}') using module("org.eclipse.platform:org.eclipse.swt.win32.win32.$arch:$swtVersion")
            }
            else if (os.isLinux()) {
                substitute module('org.eclipse.platform:org.eclipse.swt.${osgi.platform}') using module("org.eclipse.platform:org.eclipse.swt.gtk.linux.$arch:$swtVersion")
            }
            else if (os.isMacOsX()) {
                substitute module('org.eclipse.platform:org.eclipse.swt.${osgi.platform}') using module("org.eclipse.platform:org.eclipse.swt.cocoa.macosx.$arch:$swtVersion")
            } else {
                throw new GradleException("Your operating system ${os} is not supported")
            }
        }
    }
}

We could close this issue if you wish, but I would highly recommend this to be documented somewhere easily reachable as more people ought to have this problem besides me and the LF people!

[NiklasRentzCAU]

The standalone version does not directly require SWT; the core 'klighd' artifact from its transient dependencies requires SWT and therefore the standalone package does so too. You are right, in a standalone application and especially in the core component there should not be platform-dependent dependencies to SWT. However, KLighD was designed with SWT so deeply ingrained that is is practically impossible to completely remove SWT without rewriting the entire core of the project. Therefore we implemented SWT mock code that has the same API but no functionality, which will be pulled instead of the real SWT artifacts when implementing a language server with KLighD. As other non-language-server standalone applications mostly use the SWT-dependent offscreen-renderers (as you do as well), we left the dependency in there.

I will leave this issue open as a reminder to further document this in the Wiki and maybe provide a solution directly in the dependency management of the standalone package, such that SWT can be pulled again without your workaround (if even possible with Maven directly). I also added a hint to this issue and its solution in the last release notes.