Filebot with OpenJDK 11 + OpenJFX

[rayfun]

Hi,

I'm a web dev not a Java pro and I'm trying to understand how OpenJFX is used with building Filebot and how this plays together with OpenJDK.
If I understand correctly from my searches, JavaFX 11 is not something that you install with a JDK/JRE anymore but it should come with a project-based, local dependency of the project and is then compiled with it.
So Filebot would need to locally get JavaFX and compile it's code by specifying a module path and set of modules as described in https://openjfx.io/openjfx-docs/#install-javafx. Is that correct?
The dependencies to JavaFX were added but then removed again. I don't quite understand why.
I assume Filebot does not work with Java 11 yet?

Thanks for your help,
rayfun

[rednoah]

Java 11 support is work-in-progress.

What OS are you using? How did you install FileBot?

The TAR is built for Java 8, so you can just use the Oracle Java 8 which includes JavaFX:
viewtopic.php?f=11&t=6057

Alternatively, the DEB and SNAP packages include their own private Oracle JRE 10 with JavaFX so you shouldn't need to worry about installing Java at all:
viewtopic.php?f=11&t=6028

[rayfun]

I'm on Ubuntu 16.04 and building from source as I like to learn how things work. Potentially maybe help with some small contributions some time
I know that I can get all the other release packages but my drive is to do it my self

So am I correct that you would have to get OpenJFX on a project basis and then compile using that?
Wasn't adding these JavaFX dependencies in ivy.xml a step into that direction?

[rednoah]

Unfortunately, Apache Ivy doesn't really work at all for platform-dependent Maven dependencies, and JavaFX is extremely platform-dependent, and Ivy will just get you the compile-time stubs.

You'll need to download the JavaFX SDK from the Gluon guys, and then somehow make it work. Managed to make it run in Eclipse. Ant build is completely broken currently.


EDIT:

TL;DR Right now is a really bad time to start hacking, since the Java 11 / Modularization / OpenJDK / OpenJFX / JavaFX eviction from the JDK basically broke everything, and tooling doesn't really work out of the box right now neither.

[devster]

Hello, apologies for jumping in. I believe I managed to create a stable (kinda) CI pipeline for FileBot, however I'd like confirmation of 2 things.
A profile.settings file is required for the build, could you please confirm these are the only items inside?

Code: Select all

apikey.fanart.tv: <key>
apikey.thetvdb: <key>
apikey.themoviedb: <key>
apikey.omdb: <key>
apikey.acoustid: <key>
apikey.anidb: <whateverthisis
apikey.opensubtitles: <whateverthisis>

jfx.path: /opt/javafx-sdk-11.0.2/lib
url.data: <unknown>

the jfx.path is customized on the setup I'm using, and I removed the other values.
Second question, would it be ok to use the values extracted from the Mac or portable version?

[rednoah]

Ideally, if you create your own builds, then using your own API keys would be appreciated.

I recommend using the binary builds though. Any particular reason you need to build from source?

[devster]

Not particularly, no, I used to do it to work around linux arm32v7 and arm64v8 OpenJDK instead of Oracle JDK when Raspberry didn't have their own distribution, then I wanted to use OpenJDK 11, now I moved to Jenkins.
I found container images and distributions from Liberica including OpenJFX for Raspberry Pi which seem to work well.

I was missing apikey.google.geocode , I likely won't be needing it though.

[rednoah]

Yeah, that one is new and AFAIK only used if you rename photos and use the location binding.

I'm currently adding new binaries builds to the official download. If there's any particular binary format useful to you then maybe we can add that.

My official docker image currently just uses the apt repository to install the deb.

Maybe the key issue is official filebot docker images for arm architecture? I'll look into adding that with next release.

[devster]

Nono, no issues whatsoever, especially now, building a new image with the portable download would be fairly easy, just

Code: Select all

FROM alpine as alpine
RUN apk add -U --no-cache tar xz
ADD https://get.filebot.net/filebot/FileBot_4.8.5/FileBot_4.8.5-portable.tar.xz /tmp/FileBot_4.8.5-portable.tar.xz
RUN mkdir /filebot && tar -xvf /tmp/FileBot_4.8.5-portable.tar.xz -C /filebot

FROM openjdk:11-jdk-slim
COPY --from=alpine /filebot /filebot

I can deal with library dependencies the same way and just use the platform-agnostic jar.
I'm becoming more interested in a pure REST API. Using docker means that every action is easier if it's a network action, sending requests to containers or cluster of containers is as simple as curl http://<service|container_name>/<api_endpoint>. This means also post-processing scripts from one container running nzbget/transmission to another running FileBot would be massively simpler.
There is filebot-node obviously, but it seems more geared toward Synology (look and feel) and manual use, not programmatic use.

[rednoah]

For sure, FileBot Node is just a dumb web interface for making amc calls.

Alpine had been suggested before, but I think I ran into lots of issues getting native dependencies working, so I gave up on that at the time.

[devster]

The biggest issue with alpine (and also the main reason it's very small) is musl-libc as standard library, it requires recompilation of basically everything.
In the example above I'm just using it as a build step, final image would be debian-based.