While I do like the ExecuteScript processors as they are great at digging you out of a hole. The performance of them isn't that great.
That being said I would ve careful about dropping Lua support as there is a growing list of software that supports end user/administrator extensions via Lua for those that don't want to have to re-compile software themselves. On the other hand given that Jython doesn't yet have a Python 3 implementation it could be argued dropping Jython support is a must given that the Python 2.x line is basically end of life. Now I wonder if its worth re-factoring the ExecuteScript processors to be per language implementations inheriting from a common base like a few processors do already. Edward On Mon, 6 Nov 2023, 16:24 Matt Burgess, <mattyb...@apache.org> wrote: > I believe it is because in both ExecuteScript and ExecuteGroovyScript > you can do "regular" groovy, but EGS has extra built-ins such as easy > access to controller services, Groovy SQL stuff, etc, and we could > keep building it out. But IMO we'd have to port the rest of the > scripted components (ScriptedReader/Writer, etc.) over to the Groovy > bundle and make sure there's a drop-in replacement in the Python stuff > before we'd want to deprecate the scripted bundle. > > On the JRuby front, is that something you use actively? This question > is for you and the entire community of course. > > Regards, > Matt > > On Mon, Nov 6, 2023 at 7:12 AM Mike Thomsen <mikerthom...@gmail.com> > wrote: > > > > 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? > > > >
