Updating to newer JCEF versions & project future

[Osiris-Team]

There is an alternative project similar to pandomium by @FriwiDev, but with a much newer version of JCEF here:
https://github.com/jcefmaven/jcefmaven

Currently, newer JCEF releases cause blank pages and page loading errors on pandomium.
They also only support (compared to older releases) fewer operating systems.
That's why we will stay on the current JCEF version until an actual working JCEF version is released.
If you want to try out the old broken Pandomium release with a newer JCEF version yourself here you go:
https://github.com/dzikoysk/pandomium/releases/tag/1.1.1-JCEF-v1.0.10-92.0.25%2Bgd15cfa8%2Bchromium-92.0.4515.131

[FriwiDev]

Im currently working on building newer jcef versions for all platforms on github actions. Im still working on a maven integration, but builds are finished so far. Please note that I plan to move the jcefmaven/jcefbuild repository to jcefmaven/jcefmaven in the future, to migrate my old setup towards the new setup, so download paths will change. Apart from that the first part of the build chain should be stable. Sadly, you will obviously need to adapt your download code in your builder. To help with building upon jcef, I provide a "build_meta.json" file with a lot of useful data to go along with the build.

Check it out here: https://github.com/jcefmaven/jcefbuild/releases

[dzikoysk]

Interesting, thanks for details!

Also, I think that in the future we may need some kind of patching mechanism to jcef artifacts, so we can modify its sources to fix things like #81 and open some internals as it was in the past when I was building these builds on my own.

[FriwiDev]

The repository is designed to offer the option to compile custom source repositories with github actions by just forking and changing the build parameters. Alternatively one can compile local for their own distribution using 3 easy compile scripts. On macos dependencies need to be manually installed, on win + linux the setup runs on docker to provide a reliable build system.

[Osiris-Team]

@FriwiDev Already did that. See Pandomium-Builder and the github action for further details

[FriwiDev]

Your maven support seems nice. Changing the download paths to use the new builds should be easy with it. But I guess it would be nice to separate jcef and pandomium in maven. The base library should be available as stand-alone with the option to use easy wrappers from pandomium which then just depends on it. At least that would be my setup of choice.

The main problem of JCEF right now is that it is not easy to compile and use. Without these struggles, it would become a major library for interface design and layout in Java, or at least the base for this. Pandomium is a step in the right direction, but it currently does not support all OS and architecture combinations. I would be suggesting the following plans to make this happen:

1. Provide builds for all 9 distribution types provided by spotify: Windows (i386, amd64, aarch64/arm64), Linux (i386, amd64, arm/v7, aarch64/arm64) and OSX (amd64, arm64). I am currently able to build all of them with github actions (apart from linux/arm/v7, which I'm still working on).
2. Find a way to also dynamically load the macos version outside of a bundle. If we have to, we could fork JCEF to fix the discovery of module resources ourselves. This may be useful anyways to provide new features for pandomium in the future.
   3a. Make it easily useable (most likely with pandomium)
   3b. Maybe provide a JavaFX node for JCEF to enable embedding in modern applications.

Do you think this strategy makes sense? I would greatly appreciate any feedback and help :)

[dzikoysk]

Imo providing standalone Maven builds without Pandomium does not really make sense as Pandomium api is optional, tiny and mostly about the launch process to at least try to fix this messed up procedure provided by cef + jcef.

Supporting all archs would be great, I failed in the past as this project was created before GitHub even had GitHub Actions, so without a macOS it was pretty much impossible to cover it, especially that it was hard to build even on Windows those days.

Speaking of improving JCEF itself, well, it's quite complex project and I never wanted to modify it on my own, so I always considered patches (through scripts, for some cases git patches also could work) as a batter way to go.

Currently I'm also focused on other projects, so I'm not that active. Mostly @Osiris-Team is working on this lately, but I'm open to suggestions and if you need something, let me know :)

I had also plans to move this project to the Pandomium organization, so if you'd like to join forces we can also discuss this. I've seen a few small projects addressing JCEF lately, but I still think it would be great to focus on just one tool just like it works in other languages.

• https://github.com/cztomczak/cefpython
• https://github.com/cefsharp/CefSharp
• etc.

[Osiris-Team]

Yeah I guess it would be better to get the JCEF source and build it manually instead of relying on the jcefbuilds repo.
Maybe then we could actually build for macos too?

[dzikoysk]

jcefbuilds repo is mostly about setting up GitHub Actions to build these natives, so in the end it could be even forked in case of a need for any custom modifications, but I don;t think we need this now.

[FriwiDev]

@Osiris-Team @dzikoysk I'm now providing maven artifacts on the central repository that support linux, windows and macosx out of the box. Check them out: https://github.com/jcefmaven/jcefmaven :)

I decided to pull through with my own artifacts in order to have a clean and minimalistic setup as the base around jcef (all api calls apart from initialization are still jcef calls). I think this is the best approach, so other projects can focus on the wrappers and not the actual building and deploying.

[Osiris-Team]

@FriwiDev Nice great work!

[Osiris-Team]

The repo of @FriwiDev does exactly what pandomium does + has newer version + supports more platforms.
Wouldnt it be better to make pandomium repo read-only and add a link to friwidevs repo? @dzikoysk

[dzikoysk]

Nice, but I'm using this internally in some of my legacy projects, so it doesn't really make sense for me to archive this for now. Also, there are people who still use this, so we need a place where they can go back and ask/report some stuff - it wouldn't be possible in archive mode.

Anyway I'm glad that there's someone that still works on such solution as I'm not longer that active in this area due to other projects. I'll redirect some old, future related, issues here.