feel-scala
feel-scala copied to clipboard
camunda
Cross-compile to Javascript using Scala-JS
Description
This PR adds cross-compilation to Javascript using Scala-JS.
In order to do so, I needed to reintroduce SBT and change the directory structure to split into shared, jvm and js compatible files. Currently this branch doesn't build at all with Maven.
Related issues
closes https://github.com/camunda/feel-scala/issues/220
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.
Hi @saig0, I just rebased this branch on the newest master version and I noticed that the combination of renames (due to the different directory structure required to cross-build), changes in the code in this branch and changes in the master branch make this quite an effort... I'm not 100% done yet either, but that is the smaller issue.
I did some research again on whether it is possible to use Maven to compile Scala-js, and the short answer is "only if you hate yourself and want to have a really bad time" 😝 So the question would be: Is the capability to use FEEL in the browser important enough for you/Camunda to either maintain both a Maven and an SBT build, or switch to SBT completely? You mentioned that your current CI system is Maven based. Would it be an option to use Github Actions as CI system? I would be willing to set this up for you if it helps getting this branch merged. The last and imo worst option would be to maintain this as a fork or branch and we sync useful changes back and forth. Do you see any other options?
A useful intermediate step could be if I create a separate PR which uses a Scala-JS compatible logger. This is one of the bigger parts that ties FEEL to the JVM.
@nightscape thank you for the update :smile: :+1:
Is the capability to use FEEL in the browser important enough for you/Camunda to either maintain both a Maven and an SBT build, or switch to SBT completely?
Currently, we can't switch to SBT completely because of some Maven plugins that are required for releasing/deploying.
Would it be an option to use Github Actions as CI system?
Maybe. Currently, we migrate the build pipelines for the community projects to GitHub actions. Would it solve the problem with Maven and SBT?
A first option could be to use SBT for building the JS artifact only.
A useful intermediate step could be if I create a separate PR which uses a Scala-JS compatible logger.
The FEEL engine depends only on SLF4j. Is it not supported by Scala.js? Or, do you mean the runtime?
Please note that this feature is not important from Camunda's point of view at the moment. So, we might not want to change the infrastructure or codebase to keep it simple and maintainable. Or, if it doesn't fit to our projects that depends on the FEEL engine.
However, I really appreciate your research! :rocket:
Is the capability to use FEEL in the browser important enough for you/Camunda to either maintain both a Maven and an SBT build, or switch to SBT completely?
Currently, we can't switch to SBT completely because of some Maven plugins that are required for releasing/deploying.
Are these the ones from pom.xml or do you use additional ones?
For the ones from pom.xml there would be SBT alternatives afais.
Would it be an option to use Github Actions as CI system?
Maybe. Currently, we migrate the build pipelines for the community projects to GitHub actions. Would it solve the problem with Maven and SBT?
Not directly, but it would allow external contributors like me to make, test and create PRs for changes to the build process.
A first option could be to use SBT for building the JS artifact only.
That would be possible, but the overall directory structure would have to be modified (split into shared, jvm and js sources) and the Maven build adapted accordingly. That is possible and I could take care of it, but it would complicate the pom.xml a little and also require additional thinking on developer side which classes go into the jvm directory and which ones to shared.
A useful intermediate step could be if I create a separate PR which uses a Scala-JS compatible logger.
The FEEL engine depends only on
SLF4j. Is it not supported by Scala.js? Or, do you mean the runtime?
SLF4j is not supported on Scala-JS, but there are alternatives:
- https://github.com/scala-js/scala-js-java-logging is a
java.loggingcompatible API for Scala-JS. - https://wvlet.org/airframe/docs/airframe-log is a more modern Logging framework with additional capabilities like colors and source code locations.
- https://github.com/outr/scribe is a pure Scala implementation and claims to be super fast.
- https://github.com/jokade/slogging is a wrapper around other logging libraries like
SLF4jand also works on Scala-JS.
Please note that this feature is not important from Camunda's point of view at the moment. So, we might not want to change the infrastructure or codebase to keep it simple and maintainable. Or, if it doesn't fit to our projects that depends on the FEEL engine.
However, I really appreciate your research! 🚀
Good to know, thanks for the transparency. I would consider this to be beyond the research phase. There's definitely room for improvement and not everything that works on the JVM also works in the browser, but it is definitely usable. The question for me is how to make it maintainable and where to publish artifacts. I'm open to any suggestions here 😃
Are these the ones from pom.xml or do you use additional ones? For the ones from pom.xml there would be SBT alternatives afais.
Yes. But there is maybe more in the parent pom :thinking:
SLF4j is not supported on Scala-JS, but there are alternatives:
Interesting. SLF4j is required for the JVM part. If the JS part uses a different logging lib, like scribe , then it is okay.
The question for me is how to make it maintainable and where to publish artifacts. I'm open to any suggestions here
Good question. I'm also thinking about it :sweat_smile:
Hi @saig0, I just discovered this project which could solve the SBT vs. Maven problem: https://github.com/AugustNagro/sbt-delegate-maven-plugin It explicitly states as a use case
You'd like to use Scala.js or build for multiple platforms while keeping a Maven build definition.
Do you think this would be a viable option?
That looks interesting.
Do you think this would be a viable option?
I'm not sure. It is a new project with only a single contributor. However, if it works then it might be okay for the beginning.
@nightscape thank you for all your input and contribution. :medal_sports:
We decided to not follow this path anymore (see my comment). Instead, we built a new FEEL engine natively in JS.
Maybe, the JS FEEL engine could be useful for you too.
Hi @saig0, thanks for getting back! The project I was using FEEL for is currently on hold, but it might be an option to switch to the pure JS version once/if it gets resumed.