nsions in their own repo...
Great work David - thanks!
On Wed, Jun 26, 2024 at 2:36 PM David Handermann <
exceptionfact...@apache.org> wrote:
> Team,
>
> Thanks to collaboration with Joe Witt, the new nifi-python-extensions
> repository [1] is now populated with the initial se
Great work David - thanks!
On Wed, Jun 26, 2024 at 2:36 PM David Handermann <
exceptionfact...@apache.org> wrote:
> Team,
>
> Thanks to collaboration with Joe Witt, the new nifi-python-extensions
> repository [1] is now populated with the initial set of Python
> Processors.
>
> The repository inc
Team,
Thanks to collaboration with Joe Witt, the new nifi-python-extensions
repository [1] is now populated with the initial set of Python
Processors.
The repository includes a standard GitHub workflow for pull request
validation that checks license headers and Python code formatting.
The projec
Joe,
Thanks for raising the discussion, and thanks to everyone for the feedback
thus far. This tracks our previous discussion on the topic [1].
I am also strongly in favor of separating out extensions into their own
repositories for many of the reasons already mentioned. Starting with a
single de
Hi Joe, Arpad and all,
I'm strongly in favor of moving all Python components to a separate
repository. It could be called apache/nifi-python-extensions or
-components, and contain all Python components that this community
maintains. I would prefer that over a separate repo for each extension,
"I would suggest starting with
moving the Python ones to a dedicated repo, let's have a workflow
established and polished there, might follow with some Java ones in case it
works well."
Yeah kinda where my head is too
On Fri, Jun 21, 2024 at 2:07 PM Arpad Boda wrote:
> Joe,
>
> Interesting thou
Joe,
Interesting thoughts, I see a lot of pros and cons. Let me list the most
important ones of both:
+cves in extensions doesn't make nifi "vulnerable" automatically as they
live in a different repo.
+the responsibility of being up-to-date is being moved to the maintainers
of the given extension,
Team,
For the longest time we had all these Java based extensions and it was
often inconvenient for them to live within the codebase. Indeed it makes
the builds crazy long and it delays getting new components out. We had a
lot of work to do for this to be convenient and perhaps we still have gap
