Re: [DISCUSS] Python processor dependency management

Joe, In this scenario we are talking about very similar use cases for these processors, which would result in very similar processor code. Probably similar properties, similar functions used by all of these processors. That would result in a common codebase, which after some refactoring would resu

Re: [DISCUSS] Python processor dependency management

Gabor Thanks. While I understand the logical grouping *these all do doc parsing things* why is it important for them to be in the same package? Why not have separate document parsing packages each which can be built/deployed separately? Thanks On Tue, Sep 24, 2024 at 9:29 AM Gábor Gyimesi wrot

Re: [DISCUSS] Python processor dependency management

David, Joe, You are right, it's easier to understand such a use case with an example. We currently have a ParseDocument processor in our python extensions with PLAIN_TEXT, HTML, MARKDOWN, PDF, WORD, EXCEL, POWERPOINT input format support, using the unstructured library on its own or through langch

Commit messages in the mono-repo of nifi.git

Team, NIFI-13762 is a good example but we need to try and remember to have good commit messages. The repo as a whole is for nifi itself, minifi (java), c2, the registry, etc.. While the context can always be assumed to be nifi if committing for registry or minifi or the c2 protocol the commit me

Re: [DISCUSS] Python processor dependency management

Gabor, On a similar note, it would be helpful to provide a concrete example. Unlike Java NARs, Python Processors do not have the same concept of multiple layers of parent class loaders right now. Virtual environments provide dependency sharing, but there isn't the same concept of sharing dependen

Re: [DISCUSS] Python processor dependency management

Gabor Can you please describe a specific case or cases where ProcessorA and ProcessorB should be in the same package/module and yet have such vastly different (100s of MB or even GB) of dependency requirements? Thanks Joe On Tue, Sep 24, 2024 at 7:32 AM Ferenc Gerlits wrote: > Hi Gabor, > > I

Re: [DISCUSS] Python processor dependency management

Hi Gabor, I like this approach, and I think the restriction you propose (that all utility files in the package use the same dependencies, and extra dependencies for processor A are only used in ProcessorA.py) is reasonable. I would be happy to implement this if there are no objections. Thanks, F

Re: [VOTE] Release Apache NiFi NAR Maven Plugin 2.1.0 (RC1)

+1 (non-binding) - went through the verification guide - verified signatures and hashes - verified successful build Environment: - macOS Version 14.3.1 - OpenJDK Runtime Environment Zulu21.28+85-CA (build 21+35) - Apache Maven 3.9.6 Thanks for RMing David! Regards, Mark Pierre Villard ezt írt

Re: [VOTE] Release Apache NiFi NAR Maven Plugin 2.1.0 (RC1)

+1 binding Confirmed the proper behavior when building NiFi while referencing nifi-api 2.0.0 Thanks, Pierre Le mar. 24 sept. 2024 à 12:06, Ferenc Kis a écrit : > +1 (non-binding) > > * ran through the release verification guide > * verified signatures and hashes > * successfully built built ni

Re: [VOTE] Release Apache NiFi NAR Maven Plugin 2.1.0 (RC1)

+1 (non-binding) * ran through the release verification guide * verified signatures and hashes * successfully built built nifi-nar-mavan-plugin and installed the jar into local maven repository * built NiFi from the latest main using the nifi-nar-mavan-plugin 2.1.0 * created simple flow, all looke

Re: Inquiry regarding feasibility of enabling NewRelic APM for Nifi workflows

Hi Murugan, Are you running the container in Kubernetes? If so you might want to consider the Prometheus Agent for Kubernetes from New Relic rather than adding the agent to the Docker image. This does assume that your Docker image is exposing a Prometheus metrics endpoint. https://docs.newrelic