[automation] Ignore relative lib directories for scripts

[jpg0]

ScriptFileWatcher can now be configured to ignore specific, relative directories. This is used so that it can ignore "node_modules" which is what JS is hardcoded to use as a library path.

(Note that this also disables generic library tracking, and instead leaves specific enablement up to script engine providers. I will re-enable this in the JS add-on.)

This change is required to allow JS scripts to use relative paths for libraries, to allow general support for 3rd party libraries and tooling.

Signed-off-by: Jonathan Gilbert jpg@trillica.com

[kaikreuzer]

The PR build failure seems to be related, but I am not sure whether this is because it still has some outdated infos for the Karaf features. Wdyt? Is the build working locally for you?

[jpg0]

Build works for me, and I changed nothing related to the build and/or features/osgi. I've re-pushed (with no real changes) to try another build...

[jpg0]

...rebased from latest main to try to rerun the build...

[kaikreuzer]

Sorry, I had to revert this, since there is indeed still a OSGi service dependency to DependencyTracker, which is no longer an OSGi service.

[jpg0]

@kaikreuzer you're right, apologies for that. What I am trying to do here is the minimum amount of change to allow a more flexible layout for JS scripting. The issue is that currently openHAB prescribes a single file layout arrangement for all scripting languages:

• Multiple source directories (all directories under automation/jsr233 inc. subdirectories)
• Multiple libraries directories (all directories under automation/lib inc. subdirectories)
• Mixing of all language sources and libs within these directories
  So far, this has been acceptable (although I would say not ideal), but it makes things really hard for JS, particularly the 2nd point.

My personal feeling is that we should separate languages entirely (e.g. automation/jython, automation/js etc), because I think it's pretty unlikely that polyglot rules will be a priority (and can still be supported anyway), then optimise each layout for the language that it's targeting (and allow each language plugin to configure how it expects file to be laid out).

Anyway, I'm reluctant to introduce such a significant change at this point, which is why I'm making more minor changes. I'll redo this PR to pull dependency tracking out of ScriptFileWatcher (the dependency you identified) and have language plugins process the script dependencies. A little more complex, but not much.

[kaikreuzer]

My personal feeling is that we should separate languages entirely

I agree, that would be a cleaner approach.

I'm reluctant to introduce such a significant change at this point

Maybe we could go there in two steps: First is to additionally support automation/js for JS rules and encourage users to move to this new structure. Second step would then be to drop support of the automation/jsr223 folder. Wdyt?

I'll redo this PR to pull dependency tracking out

Great, thanks!

[jpg0]

Yes - this would be a much better approach. I have never liked the deep hierarchy for scripts and libraries, and also wondered why users really need to see the jsr233 name.

In fact, I believe that @csowada already has a forked implementation that has done something like this. @csowada how far off to what we are discussing here are your changes? I'm thinking that we would:

• Leave the current JS impl unchanged so the existing scripts don't break
• Have the JS engine plugin to configure it's own ScriptFileWatcher and ScriptLibraryWatcher to support a parallel implementation in automation/js (and automation/js/node_modules)

[csowada]

Hello @jpg0 ,

here is my change commit csowada/openhab2-addons@0b19023

But I think it is not compatible with the latest changes and it is a quick-and-dirty implementation. The main problem was that class ScriptFileWatcher is internal. So it was not possible to inherit the class and I had to double the code.

But this implementation is working here since several months.