lf-lang / lingua-franca

Intuitive concurrent programming in any language
https://www.lf-lang.org
Other
240 stars 63 forks source link

The import org.jetbrains cannot be resolved #572

Closed Soroosh129 closed 3 years ago

Soroosh129 commented 3 years ago

After merging in #566, I get the following error in org.lflang.TimeValue.java:

image
The import org.jetbrains cannot be resolved

Is a dependency missing?

lhstrh commented 3 years ago

I suppose it works for Gradle and Maven, but not for Eclipse. Or maybe this requires a new Oomph install? IDK...

Soroosh129 commented 3 years ago

I tried running the setup tasks again but the error persists. Isn't org.jetbrains.annotations an entirely new dependency? Is it used anywhere else? I don't see it in any of the pom.xml files.

lhstrh commented 3 years ago

The pom.xml has the Maven dependencies in it; Eclipse doesn't use Maven to build. Maybe we're better off removing these annotations for now? Or maybe @oowekyala or @a-sr can help?

Soroosh129 commented 3 years ago

I opened #573 with a fix for now since Eclipse was unusable.

cmnrd commented 3 years ago

Since the Maven build is based on the Eclipse configuration, I would expect that it would also fail. However, it's hard to notice these dependency issues if you only work with lfc and the gradle build. It is probably a mistake that we don't actually build lfc and Epoch in our CI workflow. Also I am wondering: is there a way to trigger the Eclipse build in CI so that we can test our developer setup?

a-sr commented 3 years ago

org.jetbrains.* looks like a package from the Kotlin library and hence will always cause an error in the developer Eclipse since we removed the broken Kotlin support. I guess same, as dependencies to Kotlin classes, jetbrains packages should not be used in classes that are developed within Eclipse. The build will probably work because we support Kotlin and its libraries in the gradle and maven build (see this comment) but we decided to keep the code base that is currently developed in Eclipse free of Kotlin dependencies (see PR #437). Since there is no proper provider for Kotlin/Jetbrains libraries in the Eclipse ecosystem, we cannot use these classes, unless we are willing to provides them ourself.

oowekyala commented 3 years ago

Since there is no proper provider for Kotlin/Jetbrains libraries in the Eclipse ecosystem, we cannot use these classes, unless we are willing to provides them ourself.

Do you have an estimation of how much work providing those classes ourselves would represent? Jetbrains already builds an OSGi bundle. Would we need to put that on an eclipse update site or something?

a-sr commented 3 years ago

Do you have an estimation of how much work providing those classes ourselves would represent? Jetbrains already builds an OSGi bundle. Would we need to put that on an eclipse update site or something?

I have done something like this before and it took me about half a day. What you want to do, is to setup a new repository with a plugin providing the libraries (either added into the repository in some version or automatically downloaded during the build process, which is more complicated). Then, you need to create a maven tycho build to create the update site, that you then publish. The side does not need to be at eclipse, it can be anywhere. For example, for the Klighd project we use Github Pages (https://kieler.github.io/KLighD/). On a first look, this project seems to aim at solving the same issue in an automated way. It might be worth a closer look.

I am not sure if the Kotlin OSGi bundle is actually related to our problem, it seems more like it enables the use of OSGi bundles in Kotlin projects.