Thanks Otto and David - I dont plan to solicit user input as the issue is
more of what the developers/maintainers are seeing. For anything we have
there is/was at least someone using it. But that has to be matched with
someone maintaining it as well. If there are pockets of use/maintenance
Thank you, guys.
Eduardo Fontes
On Thu, May 9, 2024 at 4:03 AM Pierre Villard
wrote:
> This will likely motivate a 1.26.1 release. I should be able to do that
> next week as I'm traveling for the rest of this week.
>
> Thanks,
> Pierre
>
> Le jeu. 9 mai 2024 à 05:01, Joe Witt a écrit :
>
> >
This will likely motivate a 1.26.1 release. I should be able to do that
next week as I'm traveling for the rest of this week.
Thanks,
Pierre
Le jeu. 9 mai 2024 à 05:01, Joe Witt a écrit :
> Eduardo
>
> Yes this was found/fixed today[1]
>
> Sorry for the trouble
>
> [1]
Eduardo
Yes this was found/fixed today[1]
Sorry for the trouble
[1] https://issues.apache.org/jira/browse/NIFI-13181
Thanks
Joe
On Wed, May 8, 2024 at 6:59 PM Eduardo Fontes
wrote:
> Hi!
>
> Someone with errors like that em Azure components in Nifi 1.26?
>
> java.lang.NoSuchMethodError:
>
Hi!
Someone with errors like that em Azure components in Nifi 1.26?
java.lang.NoSuchMethodError:
'com.microsoft.aad.msal4j.AbstractApplicationBase$Builder
com.microsoft.aad.msal4j.ConfidentialClientApplication$Builder.logPii(boolean)'
I see thar msal lib was updated since 1.25.
Best regards.
Hi,
I've created https://issues.apache.org/jira/browse/NIFI-13187 to suggest
some changes to modernize the Nifi Archetypes. Specifically:
Modernize Nifi's Java archetypes using Immutable Map, List utils
Provide more readable property and relationship names
Provide example of flow
Oh yeah, I do love this behavior of ProcessSession. And thanks for the
tip, it's easy to forget that there are efficiencies to be gained by using
different parts of an API.
-- Mke
On Wed, May 8, 2024 at 11:04 AM Mark Payne wrote:
> Yeah, that was something that kinda flew under the radar.
Thanks Joe! Then it's probably the same build issue we found with this
version.
Regards,
Gabor
On Wed, 8 May 2024 at 21:32, Joe Witt wrote:
> pkgutil --pkg-info=com.apple.pkg.CLTools_Executables
> package-id: com.apple.pkg.CLTools_Executables
> version: 15.3.0.0.1.1708646388
> volume: /
>
pkgutil --pkg-info=com.apple.pkg.CLTools_Executables
package-id: com.apple.pkg.CLTools_Executables
version: 15.3.0.0.1.1708646388
volume: /
location: /
install-time: 1710790868
sw_vers
ProductName: macOS
ProductVersion: 14.4.1
BuildVersion: 23E224
Thanks
Joe
On Wed, May 8, 2024 at 8:15 AM
For checking the xcode version you can use the following command:
$ pkgutil --pkg-info=com.apple.pkg.CLTools_Executables
And to check the macos version use the following command:
$ sw_vers
On Wed, 8 May 2024 at 16:35, Gábor Gyimesi wrote:
> The build output should be visible on the stdout and
Yeah, that was something that kinda flew under the radar. Definitely improved
the API.
Not really related, but on the note of things you may not realize, with that
code snippet :)
If you have access to update the processor mentioned here, you should avoid
using session.putAttribute many times.
The build output should be visible on the stdout and stderr channels so the
output should be visible above the python output. If it is hidden for some
reason when you use the python bootstrap, you could use the cmake commands
to rerun the build with the default extensions:
$ mkdir build && cd
Wow, thanks for this information! Just last week I saw code that modified
attributes in a stream:
flowFile.getAttributes().entrySet().stream().filter(e ->
e.getKey().startsWith("foo"))
.forEach(e -> session.putAttribute(flowFile, "original-" + e.getKey,
e.getValue()));
and I wondered how
Gabor - thanks. Can you share a specific command and/or file I can look at
which would have the good info?
On Wed, May 8, 2024 at 7:00 AM Gábor Gyimesi wrote:
> Hi Team,
>
> In light of the issues found on the MacOS platform I am canceling RC3 and
> will create RC4 once the issues are
Hi Team,
In light of the issues found on the MacOS platform I am canceling RC3 and
will create RC4 once the issues are resolved.
Two of the runtime issues have already been addressed by these 2 PRs:
https://github.com/apache/nifi-minifi-cpp/pull/1782
-1 (non-binding)
Verified signatures/hashes, compiled on macos 14.2.1 with xcode 15.1 and
deployed simple flow through c2 protocol,
but I have found the following on macos:
- getting errors running nifi python processors, due to python searching
for minifi_native.so
- minifi.plist is missing
+1 (non-binding)
-Verified signature, hashes and git commit hash
-Built it from source with default extensions on RockyLinux 9 (aarch64
and x86_64), macOS 14.3.1 (M1) and Windows 10 (x86_64) using the new
python based bootstrap
-Ran through a couple of C2 initiated flows
Everything worked as
Hi Joe,
Could you check the ninja output for the build error? The output you sent
is only the bootstrap script's traceback of the build step's failure, but
there should probably be an error in the build output as well starting with
"error: ".
BR,
Gabor
On Wed, 8 May 2024 at 02:26, Joe Witt
Hello
Sigs/Hashes are good.
Building source on macos I'm getting a build failure. The only option
selected was to skip tests otherwise left as defaults. Am following the
readme and release guide.
ninja: build stopped: subcommand failed.
Build was unsuccessful
Traceback (most recent call
Awesome Chris and David - both of those are done and dusted! Amazing.
Matt; Thanks yes for Hive it should just be simplifying/updating the
Iceberg dependency on Hive to the latest or even removing if not
necessary. Iceberg itself can be updated but my understanding is the 1.5.1
release has a
Team,
There has been a significant amount of progress on the new UI, and it
is now part of the default build in the main branch. There are a
couple more dependency updates to be incorporated, and I plan
initiating a release candidate build for 2.0.0-M3 in the next day or
two at the latest.
Joe,
Thanks for highlighting these areas to be updated. I was able to
address the QuestDB update with a couple minor adjustments, and
submitted a PR [1].
Regards,
David Handermann
[1] https://github.com/apache/nifi/pull/8773
On Tue, May 7, 2024 at 2:58 PM Chris Sampson
wrote:
>
> I’ll pick up
Joe,
Thanks for highlighting the Kafka Connect external module. I concur
with your evaluation, I have not observed community usage or
questions, so it seems best to remove from the main branch.
Regards,
David Handermann
On Tue, May 7, 2024 at 2:18 PM Otto Fowler wrote:
>
> I would say nuke it,
I’ll pick up the Elasticsearch dependency upgrade.
I’ll try to test it again OpenSearch as well, if for no reason other than to
prove either way whether the current NiFi components will work with the AWS
service, although I may not get to do that and instead testing will focus on
Elasticsearch
Yeah sorry - what I wrote for the Hive one was a bit nonsensical. I tried
to clarify it better in the JIRA.
Thanks
On Tue, May 7, 2024 at 12:38 PM Matt Burgess wrote:
> For [1] Hive 3 was removed in
> https://issues.apache.org/jira/browse/NIFI-12981, if you mean the Hive
> dependency from
For [1] Hive 3 was removed in
https://issues.apache.org/jira/browse/NIFI-12981, if you mean the Hive
dependency from Apache Iceberg we probably need a release from them that
brings in Hive 4 dependencies? Or do you suggest we bring the Hive
components back as long as we update the version?
I'll
I would say nuke it, as you are saying. I would also say you should cross
post this to users@ as they will have relevant input
On May 7, 2024 at 1:32:11 PM, Joe Witt (joew...@apache.org) wrote:
Team,
The only component remaining is kafka-connect in the nifi-external module.
As noted in [1] it
Yes, what you described is what was happening, Mark. I didn't display
all of the code to the session methods, and I did re-read the in-coming
flowfile for different purposes than I had already read and written it.
So, I wasn't helpful enough. In the end, however, I had forgotten,
immediately
Team,
We have made massive strides going from thousands of out of date libraries
to dozens in the 2.x line vs any prior releases. And we can/should stay on
top of these better going forward. A few key bits that are outstanding
with no obvious immediate work underway are as follows. If anyone
Russell,
May not be too bad to fix :)
Any time you use a method on ProcessSession to modify a FlowFile in some way
(such as putAttribute, putAllAttributes, write, removeAttribute,
removeAllAttributes, etc.) the ProcessSession returns to you a new FlowFile. So
you *should* write code such as:
Russ
FlowFile result = session.*write*( flowfile, new StreamCallback()
session.*read*( flowfile, new InputStreamCallback()
session.*removeAllAttributes*( result, keys );
session.*putAllAttributes*( result, attributes );
In /pom.xml/ I specify using NiFi framework libraries from 1.13.2.
There are peculiar reasons (that we are trying to fix) that inhibit us
from moving forward as all of our customer machines are running 1.1.2.
(Don't shoot me, I'm not DevOps, but just the guy who writes custom
processors.)
I
Team,
The only component remaining is kafka-connect in the nifi-external module.
As noted in [1] it does not see much active maintenance and I never see in
the apache community any questions/usage related either. Kafka is
currently on 3.7.0 and this component is Kafka 2.6 for example.
We should
+1 (binding)
Built on ubuntu, verified signature and checksums. All tests passed,
started and ran a simple flow with no issues.
Nice job, team!
On Tue, May 7, 2024 at 11:35 AM Gábor Gyimesi wrote:
> Hello,
>
> I am pleased to be calling this vote for the source release of Apache NiFi
> MiNiFi
Hello,
I am pleased to be calling this vote for the source release of Apache NiFi
MiNiFi C++ 0.99.0.
The source tarball, some binary builds, plus signatures and digests can be
found at:
https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/0.99.0/
The Git tag is minifi-cpp-0.99.0-RC3
The
Apache NiFi Community,
I am pleased to announce that the 1.26.0 release of Apache NiFi passes:
10 +1 (binding) votes
7 +1 (non-binding) votes
0 0 votes
0 -1 votes
Thanks to all who helped make this release possible!
The release artifacts will be published in the next 24 hours.
+1 (binding)
Went through the usual steps and verified the RC with a 3-nodes secured
NiFi cluster + secured NiFi Registry and some flows.
Closing the vote and proceeding with the release.
Thanks,
Pierre
Le lun. 6 mai 2024 à 19:05, Dan S a écrit :
> +1 (non-binding)
>
> Went through the
+1 (non-binding)
Went through the helper guide and did a clean build
Verified signatures and hashes
Built on Linux 4.18.0-513.24.1.el8_9.x86_64
Java version: Java openjdk version 17.0.11
Apache Maven 3.9.6
Verified tickets
[NIFI-12785] InvokeHTTP handler should not urlencode HTTP URL
+1 binding.
Thanks Pierre!
On Mon, May 6, 2024 at 8:08 AM Krisztina Zsihovszki
wrote:
> +1 (non-binding)
>
> - Verified signatures and hashes
> - Ran build using Maven 3.8.5 on macOS 13.5 with 8.0.392-zulu
> - Contrib check, unit tests passed
>
> Verified these tickets:
>
> [NIFI-12677] -
+1 (non-binding)
- Verified signatures and hashes
- Ran build using Maven 3.8.5 on macOS 13.5 with 8.0.392-zulu
- Contrib check, unit tests passed
Verified these tickets:
[NIFI-12677] - ExcelReader documentation gives an example of a non-existent
strategy
[NIFI-12960] - Support reading
+1 (binding)
verified signature, hashes, commit ID
had a glance at the README, LICENSE, NOTICE files
built on:
Apache Maven 3.9.6 Maven home:
/home/mwmoser/.m2/wrapper/dists/apache-maven-3.9.6/a53741d1
Java version: 1.8.0_412, vendor: Red Hat, Inc., runtime:
Martin Zink pointed out that using NiFi python processors with a virtualenv
crashes MiNiFi C++ on some specific Linux distributions and python versions
according to our Python version compatibility checks.
This seems to be a release blocking issue, described in the following Jira
ticket:
+1 (binding)
Verified signatures and hashes.
Built NiFi on Ubuntu 22.04 with Java 8 (Temurin 1.8.0_412+8) and Java 11
(Temurin 11.0.23+9), Maven 3.9.6 with empty local repo.
Ran flows for validating:
- NIFI-12837 Add DFS setting to smb processors
- NIFI-12732 ListS3 should reset its tracking
+1 (binding)
Ran through the release helper. Verified signatures and hashes.
Full clean build of RC with Java openjdk 11.0.23 2024-04-16 on macOS Sonoma
14.4.1 using the Maven Wrapper 3.9.6.
Ran a selection of processors/flows, primarily focussed on Elasticsearch
integration and HTTP
+1 binding
- Verified signatures and hashes
- Ran build using Maven Wrapper 3.9.6
- Ran build on Ubuntu 22.04 with Azul Zulu JDK 1.8.0-382 x86_64
Thanks Pierre!
Regards,
David Handermann
On Fri, May 3, 2024 at 7:47 AM Pierre Villard
wrote:
>
> Team,
>
> I am pleased to be calling this vote
+1 (non-binding)
- went through the helper guide,
- did a full build with contrib check
- verified signatures and hashes
Environment:
- macOS Version 14.3.1
- OpenJDK Runtime Environment (Zulu 8.62.0.19-CA-macos-aarch64) (build
1.8.0_332-b09)
- Apache Maven 3.9.6
Created and ran some simple
+1 (non-binding)
Went through the helper guide, local maven repo cleaned up, full clean
build with contrib check, verified signatures and hashes
Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584)
Maven home: /Users/fkis/.sdkman/candidates/maven/current
Java version: 1.8.0_362, vendor:
+1 (non-binding)
- Verified hashes and signatures
- Successfully built NiFi 1.26.0 with contrib-check in the following
environment:
- Ubuntu 22.04 6.5.0-26-generic
- openjdk 11.0.22 2024-01-16
OpenJDK Runtime Environment (build
11.0.22+7-post-Ubuntu-0ubuntu222.04.1)
OpenJDK 64-Bit
+1 (binding)
- Went through the helper guide, built on Ubuntu 24.04 LTS, and tested
on Ubuntu with Java 8 and Arch Linux with Java 22.
- Tested forwarding compressed logs from the MiNiFi C++ RC through HTTP,
and decompressing them on NiFi.
- Tested sending a flow definition from the MiNiFi C2
+1 (non-binding)
Verified keys and hashes
Performed a clean build
Java 1.8.0_402
Maven 3.9.3
Ubuntu 22.04.4
Performed upgrade from NiFi 1.25.0
Started correctly. Interacted with NiFi Registry 1.25.0 normally.
Performed upgrade of NiFi Registry from 1.25.0
Again, behavior and interaction between
+1 (binding)
Went through the helper guide and did a clean build
Verified signatures and hashes
Built on OSX 14.2.1
Java version: 11.0.20, OpenJDK 64-Bit Server VM Zulu11.66+15-CA (build
11.0.20+8-LTS, mixed mode)
Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546)
Started NiFi and
+1 (binding)
Tried in an ubuntu:24.04 docker container, and updated the release
helper guide on Confluence with my findings.
It worked as expected.
Tried compiling and running on a fresh Arch Linux VM, with the new
Python bootstrap:
+1 (binding)
-Ran full clean install on macOS (Ventura 13.0.1, OpenJDK version 1.8.0_372)
-Verified Core UI and Documentation changes
-Ran basic flows successfully
Drew
> On May 3, 2024, at 8:46 AM, Pierre Villard
> wrote:
>
> Team,
>
> I am pleased to be calling this vote for the source
Thanks Matt! Upgrading to jdk 17 worked.
On Fri, May 3, 2024 at 3:18 PM Matt Burgess wrote:
> +1 (binding)
>
> Ran through release helper, verified various flows for fixes including
> https://issues.apache.org/jira/browse/NIFI-13121
>
> Thanks for RM'ing Pierre!
>
> On Fri, May 3, 2024 at 8:47
+1 (binding)
Ran through release helper, verified various flows for fixes including
https://issues.apache.org/jira/browse/NIFI-13121
Thanks for RM'ing Pierre!
On Fri, May 3, 2024 at 8:47 AM Pierre Villard
wrote:
> Team,
>
> I am pleased to be calling this vote for the source release of Apache
You may be running into [1], can you upgrade your JDK?
Regards,
Matt
[1] https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8219013
On Fri, May 3, 2024 at 2:54 PM Dan S wrote:
> II am encountering the exception below when building with Java 8
> My environment per maven -version
>
>
II am encountering the exception below when building with Java 8
My environment per maven -version
Maven home: /opt/apache-maven-3.9.6
Java version: 1.8.0_412, vendor: Red Hat, Inc., runtime:
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.412.b08-2.el8.x86_64/jre
Default locale: en_US, platform encoding:
+1 (non-binding)
verified source release sha256/512 checksums
successfully ran build using:
Apache Maven 3.9.6
Java openjdk version: 1.8.0_402
linux kernel 3.10.0-1160
Ran various simple flows successfully.
Tested against out of the box/empty registry, (i.e. created bucket, imported
PG.
Team,
I am pleased to be calling this vote for the source release of Apache NiFi
1.26.0.
Please review the following guide for how to verify a release candidate
build:
https://cwiki.apache.org/confluence/display/NIFI/Release+Candidate+Verification
The source being voted on the and the
I'm starting the process for the 1.26 RC as I don't believe we're waiting
for any additional PRs there.
Le jeu. 2 mai 2024 à 07:30, Joe Witt a écrit :
> Matt
>
> You are referring to NIFI-12998 and it causing rebasing to be necessary for
> outstanding PRs?
>
> The rebase should be quite
Canceling RC1 due to some additional temporary files made it to the source
tar gz.
On Thu, 2 May 2024 at 17:13, Gábor Gyimesi wrote:
> Canceling RC1 due to some additional temporary files made it to the source
> tar gz.
>
> On Thu, 2 May 2024 at 16:21, Gábor Gyimesi wrote:
>
>> Hello,
>>
>> I
Minor correction for the last 2 links:
118 issues were closed/resolved for this release:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321520=12353618
Release note highlights can be found here:
Hello Apache NiFi community,
Please find the associated guidance to help those interested in
validating/verifying the release so they can vote.
# Download latest KEYS file:
https://dist.apache.org/repos/dist/release/nifi/KEYS
# Import keys file:
gpg --import KEYS
# Pull down
Hello,
I am pleased to be calling this vote for the source release of Apache NiFi
MiNiFi C++ 0.99.0.
The source tarball, some binary builds, plus signatures and digests can be
found at:
https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/0.99.0/
The Git tag is minifi-cpp-0.99.0-RC2
The
Canceling RC1 due to some additional temporary files made it to the source
tar gz.
On Thu, 2 May 2024 at 16:21, Gábor Gyimesi wrote:
> Hello,
>
> I am pleased to be calling this vote for the source release of Apache NiFi
> MiNiFi C++ 0.99.0.
>
> The source tarball, some binary builds, plus
Canceling RC1 due to some additional temporary files made it to the source
tar gz.
On Thu, 2 May 2024 at 16:23, Gábor Gyimesi wrote:
> Hello Apache NiFi community,
>
> Please find the associated guidance to help those interested in
> validating/verifying the release so they can vote.
>
> #
Hello Apache NiFi community,
Please find the associated guidance to help those interested in
validating/verifying the release so they can vote.
# Download latest KEYS file:
https://dist.apache.org/repos/dist/release/nifi/KEYS
# Import keys file:
gpg --import KEYS
# Pull down
Hello,
I am pleased to be calling this vote for the source release of Apache NiFi
MiNiFi C++ 0.99.0.
The source tarball, some binary builds, plus signatures and digests can be
found at:
https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/0.99.0/
The Git tag is minifi-cpp-0.99.0-RC1
The
Matt
You are referring to NIFI-12998 and it causing rebasing to be necessary for
outstanding PRs?
The rebase should be quite straight forward for most cases.
If you have any questions Im happy to help.
I rebased a tremendous number of times to keep up with main changing while
the PR took
One thing that was mentioned was an included Jira for "providing a clearer
distinction between framework and
extensions," This involved moving extensions to a new module and for
community folks this is causing problems with any
new improvements in-flight before that. Seems like it needed more
Hi,
You can subscribe to the mailing list by sending an email to
dev-subscr...@nifi.apache.org, and replying to the confirmation email
you receive afterwards.
You can request a Jira account here:
https://selfserve.apache.org/jira-account.html
Thanks,
Marton
On 4/28/24 12:26 PM, 宇宙之星
As there seems to be no objections, I will move forward with the
release with the new 0.99.0 version proposal.
BR,
Gabor
On Thu, 25 Apr 2024 at 15:41, Marton Szasz wrote:
> There is a limitation of CMake that it doesn't allow anything other than
> numbers in the version. MiNiFi C++ uses CMake
Team,
We are getting closer to ready for a release candidate build. Based on
some conversations with those working on the user interface, there are
still a couple more items to complete this week. Getting a solid build
of the new UI into this next version will be very helpful, so getting
a few
I created a Python Nifi Processor just as in the standard python documentation.
This is NOT an ExecuteScript processor.I am able to load the python processor
in Nifi but when I click the Configure Processor -> Relationships tab, I see no
relationships there. This renders the Python processor
There is a limitation of CMake that it doesn't allow anything other than
numbers in the version. MiNiFi C++ uses CMake as its build system
generator, so this affects us. The initial idea was to go with 1.0.0
internally, and only specify the -M1 suffix in the package name, git
tag, etc.
We
This issue was discussed in the past but never reached a consensus for an
implementation that managed the concerns. My email is only to provide a
link to that pull request and discussion, for those who are curious.
https://github.com/apache/nifi/pull/4641
-- Mike
On Tue, Apr 23, 2024 at 5:47
Also agreed there. Profile should be there to exclude perhaps but include
should be default.
On Wed, Apr 24, 2024 at 6:30 AM David Handermann <
exceptionfact...@apache.org> wrote:
> Thanks for the replies thus far!
>
> With the goal of including the new UI, it seems like a good time to
> move
Thanks for the replies thus far!
With the goal of including the new UI, it seems like a good time to
move the module from an optional profile to part of the standard
build. That would make the release candidate build and review process
simpler, not requiring the optional build profile.
Regards,
I also agree with this stance for an initial period of transition time, but
this obviously has a huge impact on contributions. Without any kind of end
date, I worry this is going to be policy indefinitely. Because of this, I
tend to agree with what Rob said in the previous email. Maybe once 2.0 is
+1 Rob
On Wed, Apr 24, 2024 at 8:17 AM Robert Fellows
wrote:
> The new UI has progressed quite well and I agree with this stance. However,
> with 2.0 getting close, one could argue that new UI features should
> definitely land in the new UI but only really need to land in the original
> UI if
The new UI has progressed quite well and I agree with this stance. However,
with 2.0 getting close, one could argue that new UI features should
definitely land in the new UI but only really need to land in the original
UI if desired or to support backward compatibility.
--Rob
On Tue, Apr 23,
Thanks for sending this out Matt! I agree that at this point any new
features to the frontend should be implemented in both the new and the
existing UI. Updating the contributions guidelines seems appropriate as
well.
-Scott
On Tue, Apr 23, 2024 at 4:07 PM Matt Gilman wrote:
> Team,
>
>
Edward
Moved those cc'd to bcc including yourself. To really send/receive notes
you'll want to subscribe to the mailing list.
We have to effectively draw the line somewhere at how much data is
retrieved and the click to content mechanism supported isn't meant to be
exhaustive as-is. We
To whom it may concern,
We are using NiFi to pass FlowFiles into ExecuteStreamCommand processors.
Occasionally, running the scripts using that processor results in errors that
route into the nonzero status relationship.
We are pointing the nonzero status relationships to non-functioning
Team,
Substantial progress has been made on modernizing the NiFi UI under [1] and
[2]. As detailed in the JIRAs, this effort has been largely motivated by
moving away from deprecated and unsupported dependencies. As we begin the
process to transition to the new UI, we are at a point where any UI
I agree. Including the updated UI and getting some feedback would be great.
On Mon, Apr 22, 2024 at 8:50 PM Joe Witt wrote:
> Id be a big fan of including the new UI.
>
> On Mon, Apr 22, 2024 at 5:45 PM Pierre Villard <
> pierre.villard...@gmail.com>
> wrote:
>
> > Thanks David, I'm happy to
Id be a big fan of including the new UI.
On Mon, Apr 22, 2024 at 5:45 PM Pierre Villard
wrote:
> Thanks David, I'm happy to take care of a 1.26 release at the same time.
>
> Regarding the M3 release, should the new UI be included and instructions
> given on how to access it to start collecting
Thanks David, I'm happy to take care of a 1.26 release at the same time.
Regarding the M3 release, should the new UI be included and instructions
given on how to access it to start collecting feedback? I'm under the
impression that almost all of the work has been done, no?
Thanks,
Pierre
Le
Team,
We are approaching 300 Jira issues resolved for version 2.0.0-M3 [1],
including a number of important dependency upgrades and Python
framework improvements.
There are several open pull requests that are getting close to
completion, which should be possible to include in an upcoming release
I've tried it again and it worked immediately, so I must have filled in the
form incorrectly beforehand. Thanks for the help!
Jack
Hi,
Normally we approve them within a couple of hours, but it may take a few
days. I believe we didn't get your request: I didn't see any requests
with your name or a similar username on Thursday. We see the full name,
username, and reason for the request, but not the email address.
If you
Hi,
I've recently written a NiFi processor that is used to split large PCAP files
(as used by Wireshark etc) into smaller ones so that they're easier to manage
and it was requested that I contribute this processor to the main repo. I
applied for a Jira account in order to create a ticket on
Thanks for explaining the intent, David, and it makes perfect sense.
-- Mike
On Fri, Apr 19, 2024 at 12:26 PM David Handermann <
exceptionfact...@apache.org> wrote:
> Mike,
>
> The change was intentional from my understanding as Node.js 16 reached
> end of life last year [1]. Registry should
Mike,
The change was intentional from my understanding as Node.js 16 reached
end of life last year [1]. Registry should also be updated to build
with a more recent version of Node.js, but I believe there are some
details to sort out before that can be changed.
Regards,
David Handermann
[1]
Dan,
Reviewing recent changes, NIFI-13035 [1] updated the frontend build
process to use Node.js 21 for both the current nifi-web-ui and the new
nifi-web-frontend modules. For that reason, a more recent OS and glibc
version is now required.
Regards,
David Handermann
[1]
Perhaps this was an unintentional change to the nifi-web-ui from the
NIFI-13035 PR that was merged recently?
-- Mike
On Fri, Apr 19, 2024 at 12:06 PM Dan S wrote:
> Thanks David!
> I did not have this problem the other day when I submitted a PR for
> NIFI-12960.
>
> On Fri, Apr 19, 2024 at
Thanks David!
I did not have this problem the other day when I submitted a PR for
NIFI-12960.
On Fri, Apr 19, 2024 at 12:02 PM David Handermann <
exceptionfact...@apache.org> wrote:
> Dan,
>
> Reviewing the previous thread, the last reply from Matt Gilman still
> applies [1] meaning that CentOS
Dan,
Reviewing the previous thread, the last reply from Matt Gilman still
applies [1] meaning that CentOS 7 is not recent enough to support the
version of Node.js required.
CentOS 7 is also scheduled for End of Life [2] on June 30, 2024. Based
on the compatibility issues with the core OS
I am trying to build the 2.x branch for a PR I am trying to submit for
NIFI-13069 and it is failing. Here are the messages I see from the build
[INFO]
Dear support,
I am installing nifi-2.0.0-M2 on linux ubuntu but it does not initialize
the Nifi service.
*ls /usr/lib/jvm*
default-java java-11-openjdk-amd64 java-8-openjdk-amd64
java-1.11.0-openjdk-amd64 java-17-openjdk-amd64 openjdk-11
java-1.17.0-openjdk-amd64
1 - 100 of 19667 matches
Mail list logo
