If we deprecate ExecuteScript, I think we need to have groovyx be ready to function as a drop-in replacement if it's not there already.
On Sun, Nov 5, 2023 at 9:21 PM Matt Burgess <mattyb...@apache.org> wrote: > 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? >
