IIRC the removal of these engines was mostly due to lack of use or at least the perception thereof. If JRuby is being used by the community actively, I'm happy to revisit that discussion. Luaj's JSR-223 interface left something to be desired, but JRuby just needed a system variable set or something like that.
For the groovyx bundle, because it is Groovy-specific I tend to think we could make better use of that than ExecuteScript, especially if we do get rid of all the engines. We have a Groovy-specific processor, a "real" Python SDK, and no more Nashorn. Perhaps we move all the scripted components to the Groovy bundle, although I believe some folks still make use of Jython for these. Of course if we reinstate JRuby for ExecuteScript it's probably best to keep things the way they are, or create a jruby bundle. The original scripting bundle was aiming to support several engines, but if it turns out only one or two will be useful, it may not be worth shoehorning all that JSR-223 logic when engine-specific components could be simpler, more easily maintained, and allow for the idioms of the language to be better used (as is done in the groovyx bundle). Just my two cents, looking forward to everyone's thoughts! - Matt On Sun, Nov 5, 2023 at 8:31 PM Mike Thomsen <mikerthom...@gmail.com> wrote: > > https://issues.apache.org/jira/browse/NIFI-11646 > > I get the removal of Lua, but not the removal of JRuby. It's a clean > reimplementation of Ruby native to the JVM and AFAICT is pound for pound as > actively maintained as Groovy. > > Also, at this point, does it make sense to even keep the groovyx bundle > rather than deprecate it for 2.X?
