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

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

Open
Rojods opened this issue Jun 20, 2023 · 3 comments
Open

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

Rojods opened this issue Jun 20, 2023 · 3 comments
Assignees
Labels
question Further information is requested

Comments

@Rojods
Copy link

Rojods commented Jun 20, 2023

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 NiklasRentzCAU added the question Further information is requested label Jun 20, 2023
@NiklasRentzCAU NiklasRentzCAU self-assigned this Jun 20, 2023
@NiklasRentzCAU
Copy link
Member

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
Copy link
Author

Rojods commented Jun 20, 2023

@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
Copy link
Member

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.

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

No branches or pull requests

2 participants