[
https://issues.apache.org/jira/browse/NIFI-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14995453#comment-14995453
]
Joseph Witt commented on NIFI-684:
----------------------------------
Two different concepts to keep in mind here.
# Finding the right abstraction / refactoring / backward compatibility in
general
All processors and extensions have a life cycle. Some will find a long life of
great use and others will be replaced with better abstractions and ideas. I am
glad there are folks out there who will fight for the right abstractions and I
will too. But, for me the majority of my focus will be on what we can do as a
community and framework to support the lifecycle differences that will
naturally occur. I think the extension registry is the answer to this. It
will decouple the release of 'NiFi' the framework and application from a given
instance/node/cluster and the extensions it takes advantage of at any given
time. Users can select what they need, let things die off that they don't, be
notified of items that are no longer supported or are deprecated, and unused
items will naturally fade away.
# Java's support for scripting languages on the JVM
I think many of us are familiar with what you're describing. Not clear on this
particular ticket since as of yet it is simply a proof of concept but in the
case of NIFI-935, and as currently undocumented, we are striving more than just
a way to run various scripts. The aim is to provide nice bindings not just to
run arbitrary scripts but rather to integrate them in a meaningful way into
NiFi. It would be unclear what the goals would be of arbitrary script
execution in the context of a NiFI flow. For those cases simply using
ExecuteCommand is likely sufficient. However in building processors for
specific scripting languages the aim is for example to write a NiFi processor
literally in Python (well Jython anyway) and have the relationships,
descriptions, etc.. all come through.
As for inline scripts and precompilation those certainly sound like good
options.
Thanks
Joe
> ExecuteGroovy proof of concept
> --------------------------------
>
> Key: NIFI-684
> URL: https://issues.apache.org/jira/browse/NIFI-684
> Project: Apache NiFi
> Issue Type: Task
> Reporter: Ricky Saltzer
> Assignee: Ricky Saltzer
> Attachments: ExecuteGroovy.java, TestExecuteGroovy.java,
> TestScript.groovy
>
>
> Following up on the email thread which described using a dynamic language to
> execute code, rather than requiring a custom NAR to be created each time.
> Using this JIRA to track some prototype code I wrote to allow Groovy to
> execute code inside a processor.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
