Recent build changes

Talk about the Ultimate Question of Life, The Universe, and Everything
devster
Posts: 417
Joined: 06 Jun 2017, 22:56

Recent build changes

Post by devster »

Hello, I'll start by saying that I know building from source is unsupported and I'm not asking for support.
There have also been questions about the legality of a private build (albeit not appropriately phrased in my opinion), but as far as I can see this is allowed by the license, provided I bought one, which I have (lifetime even).

The build has been difficult, but possible, api keys were absent but I could provide my own and I could fill in the url.data.

Recently, however, my CI pipeline broke down after a few changes, mainly commits d14af0ce479b85e310ec1a888abe7c3754a068e3 and fa9793f37f10522fa1eab4a72341bb14f542aa1f which made the process much harder.
From what i can gather it seems key bits of the build process (ivy.xml and jre management) were moved to another repo, which, however, I'm unable to find. I also realized some useful build files (makefile, makefile.variables, profile.properties, .project, .classpath, .settings, .externalToolBuilders) are not included in the main repo.

So I would like to know whether there is a way to retrieve them?
Personally I would like to still have the option of a personal build, given the software is currently hosted on an open source platform. Similar softwares do provide this option (Sonarr, Radarr, SickChill, CouchPotato, Kodi, etc.).
I only work in black and sometimes very, very dark grey. (Batman)
User avatar
rednoah
The Source
Posts: 22898
Joined: 16 Nov 2011, 08:59
Location: Taipei
Contact:

Re: Recent build changes

Post by rednoah »

Oh, sorry to break your build setup. I didn't know anybody was actually building from source. I've changed a lot on my build, but a lot of that isn't really compatible with sharing publicly on GitHub (without additional effort).

The best way going forward is using the binaries I started publishing every other day:
https://get.filebot.net/filebot/BETA/

I have a lot of extra files on my development machine, IDE configuration files, helper scripts, etc. But these are not convenient for sharing as they change every day and contain sensitive information (i.e. code signing, ssh access, api tokens, etc).

It seems you are primarily missing the filebot-lib project (i.e. all the 3rd party binaries and related scripts) which currently isn't available on GitHub. I could send you a copy (~100 MB) but going forward keeping your own builds going probably will require significant investment of time and effort on your end, so I recommend just using the latest official beta builds, which will always be kept on the latest working revision.
:idea: Please read the FAQ and How to Request Help.
devster
Posts: 417
Joined: 06 Jun 2017, 22:56

Re: Recent build changes

Post by devster »

No worries, I always knew this could happen even if I don't particularly like the approach.
I will move to published binaries, as I don't see useful having a one-off copy of evolving data, but I hope you will consider the points below.

For the sake of argument (and everything that follows is strictly personal opinion), I would say that the repo as is on github seems too incomplete, there are too many crucial bits missing.
I would consider helper scripts and IDE config files as part of the project, as they are used for development, and in this case building as well, but the biggest part now seem to be the dependencies.
As I mentioned before, similar software hosted on GitHub provides most/all the information required to build it; I don't pretend to know much about software development but ease of build/test seems pretty important to attract possible contributors and they seem to manage the separation of secrets from their build systems so I wouldn't see a specific reason for not doing it. This would also have the side effect that Travis and AppVeyor, for example, offer free plans for open source, which could be a solid advantage.

From my perspective, the main argument would be the possibility to keep using the software should you decide to stop development in the future, for any reason. Another reason was my attempt (with little success) to use BellSoft Liberica alpine images for much smaller builds (JDK for alpine is around 40 Mb), as well as trying to figure out how the thing works.
I only work in black and sometimes very, very dark grey. (Batman)
User avatar
rednoah
The Source
Posts: 22898
Joined: 16 Nov 2011, 08:59
Location: Taipei
Contact:

Re: Recent build changes

Post by rednoah »

devster wrote: 09 Jun 2019, 08:23 For the sake of argument (and everything that follows is strictly personal opinion), I would say that the repo as is on github seems too incomplete, there are too many crucial bits missing.
Admittedly, the public GitHub repository is primarily intended for the purpose of documentation and education at this point.

devster wrote: 09 Jun 2019, 08:23 I would consider helper scripts and IDE config files as part of the project, as they are used for development, and in this case building as well, but the biggest part now seem to be the dependencies.
If it was just ivy.xml dependencies I probably wouldn't have bothered, but I was quite unhappy with having 100+ MB of binaries checked in as well, and de-coupling specific versions of dependencies (Java, Groovy, MediaInfo, etc) from the build just makes things easier when doing lots of builds for lots of platforms.

devster wrote: 09 Jun 2019, 08:23 As I mentioned before, similar software hosted on GitHub provides most/all the information required to build it; I don't pretend to know much about software development but ease of build/test seems pretty important to attract possible contributors and they seem to manage the separation of secrets from their build systems so I wouldn't see a specific reason for not doing it.
Easy reproducible builds that work out of the box for new developers are doable, just a lot of extra work, and definitely worth it if the project relies on attracting new committers. FileBot has never had any 3rd party contributors, even when it was completely free and open and building was just a matter of doing git clone && ant run (builds were easy when there was just a single filebot.jar)

devster wrote: 09 Jun 2019, 08:23 From my perspective, the main argument would be the possibility to keep using the software should you decide to stop development in the future, for any reason.
Well, you'd always have access to the existing binaries and services. IMHO, in the case of my sudden death, being able to easily rebuild filebot.jar from source will be the least of your problems. If anything, I'd wish for someone to take over and provide packages for end-users on all platforms, and that would most certainly be a serious commitment of time and effort, with hunting down a few jars to make the code compile being fairly negligible.


:idea: I've spent 30 min rewriting this paragraph. I don't really have a good answer for you here. It's complicated. FileBot is highly dependent on online services and has its own set of online services (and not just for license validation either). Last week you may have had a false sense of security by being able to build the jar yourself. This week maybe less so. Either way, you were never really protected against the event of my untimely demise. You probably wouldn't notice for 1-2 years, but then things would break in strange unexpected ways. Keeping things going past that point would require someone get seriously intimate with the code and related services.


devster wrote: 09 Jun 2019, 08:23 Another reason was my attempt (with little success) to use BellSoft Liberia alpine images for much smaller builds (JDK for alpine is around 40 Mb), as well as trying to figure out how the thing works.
I suspect the problem isn't building FileBot (i.e. the platform-independent Java byte code) for Alpine, but building all the native dependencies for Alpine. (which is hard, which is why I used to just dump Debian binaries into GitHub repository, instead of building from source)


:idea: My java-installer is using the BellSoft Liberica JDK for armv7, aarch64 and x86 Linux builds and I'm not away of any fundamental issues running Java code on these platforms.


:idea: GraalVM native-image builds are on the horizon, but making it work for FileBot for all platforms will be very difficult and time-consuming.
:idea: Please read the FAQ and How to Request Help.
devster
Posts: 417
Joined: 06 Jun 2017, 22:56

Re: Recent build changes

Post by devster »

rednoah wrote: 09 Jun 2019, 11:31 Easy reproducible builds that work out of the box for new developers are doable, just a lot of extra work, and definitely worth it if the project relies on attracting new committers. FileBot has never had any 3rd party contributors, even when it was completely free and open and building was just a matter of doing git clone && ant run (builds were easy when there was just a single filebot.jar)
Easy and reproducible builds should be something useful for anyone, and again, useful also because there are services who provide building infrastructure for free. Until recently I could do ant resolve + ant portable, I don't really see a downside. I accept your conclusion, I'm just having a difficult time figuring out the reasoning behind it, especially since several commits lately are related to it.
Regarding contributors I think the landscape changed a bit since 2007. A major driver for Sonarr and Radarr usage for example seem to be https://linuxserver.io container images which make them fairly easily accessible (and their heavy focus on WebUI).
It seems a catch-22 scenario.
rednoah wrote: 09 Jun 2019, 11:31 If anything, I'd wish for someone to take over and provide packages for end-users on all platforms, and that would most certainly be a serious commitment of time and effort, with hunting down a few jars to make the code compile being fairly negligible.

... You probably wouldn't notice for 1-2 years, but then things would break in strange unexpected ways. Keeping things going past that point would require someone get seriously intimate with the code and related services.
This is actually a good argument for having everything available, from what I can see they don't just build filebot.jar.
Regarding related services, excluding the databases (TVDB, TMDB, etc.), leaves out https://api.filebot.net/v5/data (replaceable by -Durl.<file> options even at runtime) and scripts, a compressed jar file. Is there more?
rednoah wrote: 09 Jun 2019, 11:31 I suspect the problem isn't building FileBot (i.e. the platform-independent Java byte code) for Alpine, but building all the native dependencies for Alpine. (which is hard, which is why I used to just dump Debian binaries into GitHub repository, instead of building from source)
Actually the issue is only with platforms other than x86_64, alpine has OpenJDK 12 and OpenJFX 12 only on that arch, while for the others it only has OpenJDK 11 (as well as MediaInfo, chromaprint, ffmpeg, etc.), but without OpenJFX. At least this is what I gathered.

P.S. I was thinking more about the risk of you getting bored with it, nothing worse.
I only work in black and sometimes very, very dark grey. (Batman)
User avatar
rednoah
The Source
Posts: 22898
Joined: 16 Nov 2011, 08:59
Location: Taipei
Contact:

Re: Recent build changes

Post by rednoah »

devster wrote: 09 Jun 2019, 12:57 This is actually a good argument for having everything available, from what I can see they don't just build filebot.jar.
Regarding related services, excluding the databases (TVDB, TMDB, etc.), leaves out https://api.filebot.net/v5/data (replaceable by -Durl.<file> options even at runtime) and scripts, a compressed jar file. Is there more?
I have a Synology NAS who's sole purpose (other than testing Synology NAS) to keep those updated. Incremental updates only take a few minutes, but building from scratch would take a few weeks. That's been running smoothly for years though, so I myself forget how things work. If debug logging is enabled, then you should have a pretty good idea what's going in and out. I think a notable recent addition is the thumbnail index. This one might also take a week or two to build from scratch. This stuff is all pretty hacky, but it works, so I don't touch it.

:!: I forgot about the script jar. That one is code signed so you can't build a working one yourself, without also replacing the public key that's baked into the filebot jar. You can always clone the scripts from GitHub though. There's no build or dependencies so switching to local scripts would be easy.

devster wrote: 09 Jun 2019, 12:57 Actually the issue is only with platforms other than x86_64, alpine has OpenJDK 12 and OpenJFX 12 only on that arch, while for the others it only has OpenJDK 11 (as well as MediaInfo, chromaprint, ffmpeg, etc.), but without OpenJFX. At least this is what I gathered.
The problem of having one big fat repository is that you can't build the CLI without also building the GUI, which means you can't build with a headless JRE because AWT / Swing / JavaFX / etc will be missing. The good thing is that since it's Java, and all compiled for Java 11, so you can take the jar build from any platform, and use it on any other platform. Currently, all builds are targeted at Java 11 for compatibility reasons since that's the LTS, except for the Java 8 backwards compatibility builds of course, i.e. the portable package should work out of the box, as far as FileBot and Java code is concerned, with the caveat of optional native dependencies (i.e. libmediainfo.so and friends) possibly not working.

devster wrote: 09 Jun 2019, 12:57 I was thinking more about the risk of you getting bored with it, nothing worse.
If that were to happen, I could just dump everything on GitHub and let the community figure it out. But as long as I'm around to maintain things and pay bills, things will continue to run smoothly indefinitely, no worries there, especially with the new license system, which is aimed at steady long-term revenue.
:idea: Please read the FAQ and How to Request Help.
devster
Posts: 417
Joined: 06 Jun 2017, 22:56

Re: Recent build changes

Post by devster »

rednoah wrote: 09 Jun 2019, 16:30 I have a Synology NAS who's sole purpose (other than testing Synology NAS) to keep those updated. Incremental updates only take a few minutes, but building from scratch would take a few weeks. That's been running smoothly for years though, so I myself forget how things work. [...] This stuff is all pretty hacky, but it works, so I don't touch it.
Now I'm even more convinced a proper pipeline would help. Also a build on a provider likely wouldn't take that long.
I'm still lost on the motivation, why not have a solid build pipeline, especially for the jar, which as you say is platform-independent?
I mean, it's not like it's not being executed every couple of days to create new beta versions.
rednoah wrote: 09 Jun 2019, 16:30 The problem of having one big fat repository is that you can't build the CLI without also building the GUI, which means you can't build with a headless JRE because AWT / Swing / JavaFX / etc will be missing.
I think this was mentioned at some point in the past, but you also said that decoupling it would take massive amount of work. In that case I'd probably vote for a persistent process with an API / WebUI.
I only work in black and sometimes very, very dark grey. (Batman)
User avatar
rednoah
The Source
Posts: 22898
Joined: 16 Nov 2011, 08:59
Location: Taipei
Contact:

Re: Recent build changes

Post by rednoah »

Both of these things basically boil down to lots of not-so-fun work with no tangible benefits for end users. It's like destroying a puzzle, and then putting it back together, but better this time. If things break and require a serious make over, I'll think about doing it in a more reproducible way. I'm just pretty sure you'd be the only person in the world interested in that. :lol:


EDIT:

Notably, you are the only person who ever contributed useful code, and that was probably after your CI already didn't work anymore. :lol:
:idea: Please read the FAQ and How to Request Help.
devster
Posts: 417
Joined: 06 Jun 2017, 22:56

Re: Recent build changes

Post by devster »

Sorry, been out of commission for a few days.
rednoah wrote: 09 Jun 2019, 17:29 Notably, you are the only person who ever contributed useful code, and that was probably after your CI already didn't work anymore. :lol:
That's probably the height of my abilities. Also something that can be decoupled from FileBot, I don't see people contributing to the main code.

Anyway, I'll adapt to the new state of things and hope it will never become a new Deluge situation.
Thank you.
I only work in black and sometimes very, very dark grey. (Batman)
User avatar
rednoah
The Source
Posts: 22898
Joined: 16 Nov 2011, 08:59
Location: Taipei
Contact:

Re: Recent build changes

Post by rednoah »

What's happening with Deluge?
:idea: Please read the FAQ and How to Request Help.
devster
Posts: 417
Joined: 06 Jun 2017, 22:56

Re: Recent build changes

Post by devster »

Single developer for the whole project, tried Patreon, had some issues and development of new v2 stalled for years.
Now he just released new versions, but many changed clients which is unfortunate, the daemon + thin client I think is a very good model.
I only work in black and sometimes very, very dark grey. (Batman)
User avatar
rednoah
The Source
Posts: 22898
Joined: 16 Nov 2011, 08:59
Location: Taipei
Contact:

Re: Recent build changes

Post by rednoah »

That's a sad story. I tried Patreon as well. It just doesn't really for software products. At least it's still around. Sickrage died from one day to the next when the developer moved on.

On the bright side, FileBot chose a different path forward. Since FileBot doesn't rely on donations anymore, and introduced a sustainable sales model instead, you don't have to worry about FileBot falling into disarray anytime soon. ;)
:idea: Please read the FAQ and How to Request Help.
devster
Posts: 417
Joined: 06 Jun 2017, 22:56

Re: Recent build changes

Post by devster »

SickRage story is a bit more complex.

echel0n forked SickBeard and created SickRage, to which a lot of people were contributing. He then disappeared for a while and the other devs kept going.

Then he came back and tried a hostile takeover which triggered the revocation of his commit access. He forked again with the same name but adding bitcoin miners to the website and the web interface.
He also sent a DMCA request to GitHub citing copyright infringement (but it's GPL, so that got bounced).

Devs split off in 2 directions: Medusa and the renamed SickChill to avoid further meddling by echel0n.

Because of all the ruckus many switched to Sonarr, but alternatives didn't die as Sonarr doesn't yet do symlinks, which for torrents are very useful.
I only work in black and sometimes very, very dark grey. (Batman)
User avatar
rednoah
The Source
Posts: 22898
Joined: 16 Nov 2011, 08:59
Location: Taipei
Contact:

Re: Recent build changes

Post by rednoah »

Wow. I had no idea. I completely missed all that drama! I just noticed a few competitors have come and gone over the years, though I usually don't notice until years after the fact, cause I personally don't really use any of them. I occasionally check things out when people need help with FileBot integration.

The tree of evolution there is interesting though!
:idea: Please read the FAQ and How to Request Help.
Nonlo
Posts: 3
Joined: 04 Jul 2019, 13:58

Re: Recent build changes

Post by Nonlo »

devster wrote: 15 Jun 2019, 19:18 SickRage story is a bit more complex.

echel0n forked SickBeard and created SickRage, to which a lot of people were contributing. He then disappeared for a while and the other devs kept going.

Then he came back and tried a hostile takeover which triggered the revocation of his commit access. He forked again with the same name but adding bitcoin miners to the website and the web interface.
He also sent a DMCA request to GitHub citing copyright infringement (but it's GPL, so that got bounced).

Devs split off in 2 directions: Medusa and the renamed SickChill to avoid further meddling by echel0n.

Because of all the ruckus many switched to Sonarr, but alternatives didn't die as Sonarr doesn't yet do symlinks, which for torrents are very useful.
I did not even think that such interesting vicissitudes occur)
kim
Power User
Posts: 1251
Joined: 15 May 2014, 16:17

Re: Recent build changes

Post by kim »

Did you completely remove the source code now ?
(if so, I really don't like this move)
User avatar
rednoah
The Source
Posts: 22898
Joined: 16 Nov 2011, 08:59
Location: Taipei
Contact:

Re: Recent build changes

Post by rednoah »

Yes, I've refactored things into a couple of private repositories, so I stopped commiting into the public one a few weeks ago.

I don't mind sending you a source tarball thought if you want, but what do you need it for anyway? As documentation for internals?

I'm surprised somebody even noticed. Nobody seemed to contribute or comments on anything.
:idea: Please read the FAQ and How to Request Help.
devster
Posts: 417
Joined: 06 Jun 2017, 22:56

Re: Recent build changes

Post by devster »

kim wrote: 09 Jul 2019, 14:24 Did you completely remove the source code now ?
(if so, I really don't like this move)
Neither do I, but it was just a matter of time.
rednoah wrote: 09 Jul 2019, 16:38 I'm surprised somebody even noticed. Nobody seemed to contribute or comments on anything.
Maybe, but I routinely used it to check how bindings were defined for example, or which changes were made to APIs and scrapers.
I only work in black and sometimes very, very dark grey. (Batman)
kim
Power User
Posts: 1251
Joined: 15 May 2014, 16:17

Re: Recent build changes

Post by kim »

"Nobody seemed to contribute or comments on anything."
You are wrong here, I did many times, just not directly.
I/We use this forum for that.
If I was a better programmer I wound add directly to source code,
but it's your code and you are way better to make changes then I.

Pro source code:
e.g. how would I know that Filebot is only checking for 7 digit IMDb id and that this could be a problem in the future if no source code?
or that something is missing from "pattern.video.source" or "pattern.video.tags"
or when api's "downloaded" 0 bytes files, I compiled the source code to confirm the fix was to change http to https.
or missing/basic support for "{info.adult}", spokenLanguages or AlternativeTitles
or that Filebot is using old api info on themoviedb
and more...

Over the years I have looked at the source code MANY times to:
1. learn from it
2. To get access to internal stuff to "hack" and make it do what I need it to do,
without up to date source code, I can't do this.
3. I look at the bindings also
4. etc.

Why I use Filebot:
1. I can customize it to what I want/need with the help from e.g. source code.
2. To learn java/groovy e.g from source code.
3. I feel like I'm part of something to help make it better and can see the changes in the source code I helped with or requested.

So no source code = not happy :(
User avatar
rednoah
The Source
Posts: 22898
Joined: 16 Nov 2011, 08:59
Location: Taipei
Contact:

Re: Recent build changes

Post by rednoah »

1.
It's always a compromise. I'd be nice if it could just be open and free, but I do have a business to run, and unfortunately there's bad actors that don't use the source like you do, and do this or that instead.

:idea: A shoutout to Phoenix09 here because he actually respected the license change. A reason the source was available for so long despite going commercial and the obvious dangers that entails.


2.
The API docs include source attachments, so sources relevant to format and script development are available:
https://www.filebot.net/docs/api/

:idea: If you need help with "How to do A?" then ask so I know there's a use case, so that I can introduce well-defined standard API for scripting. That would be preferred over accessing internals which are subject to change.


3.
Users report bugs. Developers look into them and fix them. Indeed, users have contributed much in terms of bug reports and feature requests. And I'm committed to read and resolve all bug reports. User do what users do best. Developers do what developers do best.

:idea: If something doesn't work, report it, and I'll fix it and release an update, probably even on the same day. Same for new features. Same for additional logging. I'll do the work for you. That's what you pay me for. ;)


4.
kim wrote: 09 Jul 2019, 21:04 1. I can customize it to what I want/need with the help from e.g. source code.
2. To learn java/groovy e.g from source code.
3. I feel like I'm part of something to help make it better and can see the changes in the source code I helped with or requested.
That is indeed unfortunate, and I'm sorry to take this from you.

All supporting tools that enhance FileBot (rather than replace) will remain open of course:
https://github.com/filebot/scripts


5.
Let's try closed-source for a while and see what happens. Maybe there are many unforeseen disadvantages. I'd be happy to change my mind on this one if it makes sense from a business perspective.
:idea: Please read the FAQ and How to Request Help.
devster
Posts: 417
Joined: 06 Jun 2017, 22:56

Re: Recent build changes

Post by devster »

I don't believe there are disadvantages for you, the only disadvantage is for us.
We bought a license for an open source software which became closed source.
Nothing we can do either, despite its flaws, it's still one of the most comprehensive tools to rename media.

A small compromise could be to leave a non-updated version of the repo on GitHub, archived.
I only work in black and sometimes very, very dark grey. (Batman)
User avatar
rednoah
The Source
Posts: 22898
Joined: 16 Nov 2011, 08:59
Location: Taipei
Contact:

Re: Recent build changes

Post by rednoah »

Well, for people here just ask and I'll mail you a tarball of the latest.

In general, no source means no excuse for lack of documentation. So if there's anything you need, just ask and I'll write related documentation.
:idea: Please read the FAQ and How to Request Help.
ZGab
Posts: 17
Joined: 09 May 2016, 20:35

Re: Recent build changes

Post by ZGab »

I agree kim and devster.

We've paid a licence for the product to help you on your work on this stuff, you really deserve it. Much greetings on you've accomplished !
This licence was acquired on Patreon as a support for your hard development support, at this moment it was not question about closing the OpenSource resources.
Since few month you are about deconstruct the conditions on what we have contribute.
Please do not go on the way of the deconstruction of trust.

The visibility of the source and the possibility for developers to get, modify and build the code in complete respect of your original terms is in my own mind the warranty of a global understanding of what you are doing and an important value of your product.

I understand that some projects as you mentioned upper make you mad rage. It's shame and your licence must cover your ownership.
Note: I think you can report to Microsoft the first case as an usurpation, they are aware about such situation.

I've nothing to advice to you, but as a faithful user and supporter of FileBot I can just tell my disappointment and kind of frustration about what is coming...

Note: whatever, I will respect your choice, and I thank you again for the great job you are doing
kim
Power User
Posts: 1251
Joined: 15 May 2014, 16:17

Re: Recent build changes

Post by kim »

Why is this still up ?
"File Bot - Intelligent software For FFmpeg"
"Release date
6/5/2018"
btw: does not look like it works anyway
"Does not work at all I get a Malformed URL exception error..."
In general, no source means no excuse for lack of documentation.
This will take you a looong time make properly. Even if the info is on this forum, it can be very difficult find what you need.

Filebot has been open source 10+ years ?
If someone wanted to take/copy your hard work they would have done it already.
In your own words it would take at least 30+ min. to compile the first time (hours/days for a noob, if ever) + there was missing stuff from source code a long time AND don't forget the new license stuff (maybe hours to bypass this ?)
I think most people would just use an alternative software https://alternativeto.net/software/filebot/ if they want it free.

Anyway, I do not think the source code (program) is the product, it's way to complex to maintain/update without better documentation.
The product is YOU and the very good support you provide (this is what people will pay for), because it's so complex ;)

Maybe go a other way, no license key, no support / no access to source code ?
User avatar
rednoah
The Source
Posts: 22898
Joined: 16 Nov 2011, 08:59
Location: Taipei
Contact:

Re: Recent build changes

Post by rednoah »

Writing lots of docs is easy. Writing docs that container neither too little nor too much information as to make them useful is the tricky part here. Lots of users have never seen a command-line before. Others are Groovy developers feel right at home with Groovy expressions.

Plus, 95% of FileBot code is useless even for the most advanced scripting needs. It makes sense to identify those 5% and refactor those into a stable API and open-source it.

Do you have your custom scripts on GitHub? What internal FileBot APIs do you use?

(Note that JPMS modularization coming in future releases might make it impossible to access internal APIs anyway unless explicitly declared; GraalVM ahead-of-time-compilation might make certain internal APIs nonexistent at runtime; but that's a greater Groovy / Java 11 / GraalVM topic for another day; but knowing what internal stuff is being used would be extremely helpful with ensuring future backwards compatibility)


Based on posts here, I can only identify 1 internal API that might benefit from a public API:
* FileBot Cache API
:idea: Please read the FAQ and How to Request Help.
Post Reply