Re: [DISCUSS] Deprecate TLS Toolkit for Removal?

[Kevin Doran]

 I agree that tis toolkit can probably be removed in 2.0, and I would add
that tinycert.org provides another option for teams that need to setup
dev/test environments with trusted certificates.

Thanks,
Kevin

On Sep 13, 2023 at 11:46:19, David Handermann 
wrote:

> Hi Isha,
>
> Thanks for the helpful reply. I agree that the TLS Toolkit is most
> convenient for development and lab deployments, and that's where we
> should be able to provide some documentation for alternatives. The
> existing Secure Cluster Walkthrough is a helpful reference for TLS
> Toolkit usage, so if we updated that to provide similar guidance using
> other tools, that would be useful.
>
> Getting everything right with TLS can be challenging, but when it
> comes to project maintenance, it seems better to focus on core
> capabilities and not maintain the TLS Toolkit if the primary use case
> is for non-production deployments.
>
> The encrypt-config command is a different question, but a very good
> question. It includes functionality that is very specific to NiFi, and
> it is also in need of refactoring. The threat model for containerized
> deployments may be somewhat different than running directly on
> physical hardware. With the need to support various approaches,
> however, some type of configuration encryption remains a relevant
> concern.
>
> Regards,
> David Handermann
>
> On Wed, Sep 13, 2023 at 10:19 AM Isha Lamboo
>  wrote:
>
>
> Hi David,
>
>
> My primary use for the TLS toolkit is for lab deployments, mostly during
> in-house trainings. I will miss the convenience of having a full set of
> keystores and truststores ready to go with a single command, but then
> again, a few commands in a script should replicate this well enough,
> without the need for maintaining the toolkit.
>
>
> I see no obstacles to adopting NiFi 2.0 if the TLS toolkit is phased out,
> from the perspective of the deployments I manage.
>
>
> On a side note: How relevant is the encrypt config part of the toolkit
> still in a mostly containerized world?
>
>
> Regards,
>
>
> Isha
>
>
> -Oorspronkelijk bericht-
>
> Van: David Handermann 
>
> Verzonden: woensdag 13 september 2023 15:16
>
> Aan: dev@nifi.apache.org
>
> Onderwerp: [DISCUSS] Deprecate TLS Toolkit for Removal?
>
>
> Team,
>
>
> The TLS Toolkit provides a number of useful features for securing NiFi
> server communication, but it also presents several maintenance concerns. In
> light of other available tools, I am raising the question of removing the
> TLS Toolkit from the repository as part of NiFi 2.0 technical debt
> reduction.
>
>
> With the addition of automatic self-signed certificate generation in NiFi
> 1.14.0, the TLS Toolkit is much less relevant to standalone or development
> deployments. The validity period of the automatic certificate is limited,
> but it provides a method of getting started without any need for the TLS
> Toolkit.
>
>
> On the other end of the spectrum, orchestrated deployments of Kubernetes
> can take advantage of cert-manager [1] for declarative and configurable
> certificate generation and distribution.
>
>
> Cluster deployments on physical hardware or virtual machines may have
> organization-specific Certificate Authorities, which require certificate
> request processing external to NiFi itself. For this scenario, documenting
> several standard OpenSSL commands may help to describe converting between
> PEM and PKCS12 files for common use cases.
>
>
> Back to standalone deployments, Let's Encrypt provides automated
> certificate provisioning with many tools for managing updates. For a
> self-signed solution, the mkcert [2] tool is a popular and simple option
> that works across modern operating systems.
>
>
> With these alternatives, the use cases for TLS Toolkit seem limited.
>
> The Toolkit code is not well-structured, and includes several modes that
> involve custom configuration files with a Jetty web server. There are a
> number of long-standing unresolved Jira issues [3] related to the TLS
> Toolkit.
>
>
> Removing the TLS Toolkit for NiFi 2.0 would encourage the use of more
> robust alternatives and keep the project focused on core capabilities.
>
>
> Thoughts?
>
>
> Regards,
>
> David Handermann
>
>
> [1] https://cert-manager.io/
>
> [2] https://github.com/FiloSottile/mkcert
>
> [3]
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20NIFI%20AND%20resolution%20%3D%20Unresolved%20AND%20text%20~%20%22TLS%20Toolkit%22
>
>

Re: [ANNOUNCE] New nifi PMC Member Nandor Soma Abonyi

[Kevin Doran]

Congrats! Well deserved.

From: Peter Turcsanyi 
Sent: Tuesday, June 27, 2023 5:04:58 AM
To: dev@nifi.apache.org 
Subject: Re: [ANNOUNCE] New nifi PMC Member Nandor Soma Abonyi

Congrats, Soma!

On Tue, Jun 27, 2023 at 1:11 AM Joe Witt  wrote:

> On behalf of the Apache NiFI PMC, I am very pleased to announce that Nandor
> has accepted the PMC's invitation to join the Apache NiFi PMC. We greatly
> appreciate the PR reviews and code contributions and release management
> work of Nandor.
>
> Please join us in congratulating and welcoming Nandor to the Apache NiFi
> PMC.
>
> Congratulations Nandor!
>

Re: [VOTE] Release Apache NiFi NAR Maven Plugin 1.5.1

[Kevin Doran]

 +1 (binding)

Thanks for RM’ing this time around!

Kevin

On Jun 16, 2023 at 12:44:18, Joe Witt  wrote:

> +1 (binding) thanks!
>
> On Thu, Jun 15, 2023 at 9:45 AM Matt Burgess  wrote:
>
>
> +1 (binding)
>
>
> Verified signatures and hashes, built with the system below, built
>
> NiFi NARs and verified the issue I was encountering is fixed. Thanks
>
> for RM'ing Nandor!
>
>
> Apache Maven 3.8.8 (4c87b05d9aedce574290d1acc98575ed5eb6cd39)
>
> Maven home: /Users/mburgess/.sdkman/candidates/maven/current
>
> Java version: 11.0.19, vendor: Eclipse Adoptium, runtime:
>
> /Users/mburgess/.sdkman/candidates/java/11.0.19-tem
>
> Default locale: en_US, platform encoding: UTF-8
>
> OS name: "mac os x", version: "13.4", arch: "aarch64", family: "mac"
>
>
> On Wed, Jun 14, 2023 at 6:55 PM Nandor Soma Abonyi
>
>  wrote:
>
> >
>
> > Hello Apache NiFi Community,
>
> >
>
> > I am pleased to be calling this vote for the source release of Apache
> NiFi NAR Maven Plugin 1.5.1.
>
> >
>
> > The source being voted upon, including signatures, digests, etc. can be
> found at:
>
> > https://dist.apache.org/repos/dist/dev/nifi/nifi-nar-maven-plugin-1.5.1/
>
> >
>
> > A helpful reminder on how the release candidate verification process
> works:
>
> >
> https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+NAR+Maven+Plugin+release+candidate
>
> >
>
> > The Git tag is nifi-nar-maven-plugin-1.5.1-rc1
>
> > The Git commit ID is 39fc959426ea405df6360969b55ae2adad47e1aa
>
> >
> https://gitbox.apache.org/repos/asf?p=nifi-maven.git;a=commit;h=39fc959426ea405df6360969b55ae2adad47e1aa
>
> >
>
> > Checksums of nifi-nar-maven-plugin-1.5.1-source-release.zip:
>
> > SHA256: 0ddc4efbfe504f9ed6477b8c572f2c6e5ba0c953e2e5b063bdfbd1f934eda6bf
>
> > SHA512:
> a7281c8a3769db37e3491f3a5e54533b5f26bdcad99f8adb1e5609f1de17309aefb3d49eb9231e75a814e42566525b9afe4a11bda2c4ab48e8bab5a298b72b24
>
> >
>
> > Release artifacts are signed with the following key:
>
> > https://people.apache.org/keys/committer/nsabonyi.asc
>
> >
>
> > KEYS file available here:
>
> > https://dist.apache.org/repos/dist/release/nifi/KEYS
>
> >
>
> > 3 issues were closed/resolved for this release:
>
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12353009
>
> >
>
> > Release note highlights can be found here:
>
> >
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-NiFiNARMavenPluginVersion1.5.1
>
> >
>
> > The vote will be open for 72 hours. Please download the release
>
> > candidate and evaluate the necessary items including checking hashes,
>
> > signatures, build from source, and test. Then please vote:
>
> >
>
> > [ ] +1 Release this package as nifi-nar-maven-plugin-1.5.1
>
> > [ ] +0 no opinion
>
> > [ ] -1 Do not release this package because …
>
> >
>
>

Re: [DISCUSS] Release NiFi NAR Maven Plugin 1.5.1

[Kevin Doran]

 +1

On Jun 12, 2023 at 05:35:57, Nandor Soma Abonyi 
wrote:

> Hello Apache NiFi Community,
>
> I'd like to initiate a discussion about the next release of
> nifi-nar-maven-plugin.
>
> Currently, nifi-nar-maven-plugin doesn’t use remote repositories, which was
> fixed in [1]. Though it is the only change since the last release, I
> consider it significant
> enough to suggest releasing nifi-nar-maven-plugin as 1.5.1.
>
> I would be happy to take on RM duties for this release.
>
> Do you agree it is time for a new release?
>
> Thanks,
> Nandor Soma Abonyi
>
> [1] NIFI-11324  NAR
> Plugin extension docs not correctly resolving overridden versions from
> system properties
>
>

Re: [VOTE] Release Apache NiFi 1.22.0 (RC1)

[Kevin Doran]

 +1 binding.

Ran through the steps in the Release Helper Guide to verify the
sigs/hashes, build, build docker, and run.

Congrats to the community on this release, and thanks for RM’ing, Joe!

Kevin

On Jun 6, 2023 at 17:38:25, Joe Witt  wrote:

> Hello,
>
> I am pleased to be calling this vote for the source release of Apache NiFi
> 1.22.0.
>
> The source zip, including signatures, digests, etc. can be found at:
> https://repository.apache.org/content/repositories/orgapachenifi-1228
>
> The source being voted upon and the convenience binaries can be found at:
> https://dist.apache.org/repos/dist/dev/nifi/nifi-1.22.0/
>
> A helpful reminder on how the release candidate verification process works:
>
> https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+release+candidate
>
> The Git tag is nifi-1.22.0-RC1
> The Git commit ID is 71e3ea9f2c58d0cf2ce6824c388f2bd3e917dfc8
>
> https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=71e3ea9f2c58d0cf2ce6824c388f2bd3e917dfc8
>
> https://github.com/apache/nifi/commit/71e3ea9f2c58d0cf2ce6824c388f2bd3e917dfc8
>
> Checksums of nifi-1.22.0-source-release.zip:
> SHA256: d63a5f1db95160434670f112a0ee6e06fa141182bd0f12f0e58e3229991f3743
> SHA512:
>
> 5f6da64e75a2d5446f1f274fe3de7e97290f5b916eabbc0491a99c6db33f74fbdea001b403044e75bc5c2183fb0500dfc143d0f4cba19d3511f866fff774d7f5
>
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/joewitt.asc
>
> KEYS file available here:
> https://dist.apache.org/repos/dist/release/nifi/KEYS
>
> 186 issues were closed/resolved for this release:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12353069
>
> Release note highlights can be found here:
>
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.22.0
>
> The vote will be open for 72 hours.
> Please download the release candidate and evaluate the necessary items
> including checking hashes, signatures, build
> from source, and test. Then please vote:
>
> [ ] +1 Release this package as nifi-1.22.0
> [ ] +0 no opinion
> [ ] -1 Do not release this package because...
>

Re: [discuss] nifi 2.0 and Java 17...

[Kevin Doran]

Yeah I agree it makes sense to move to 17… as long as we are introducing a 
potential disruptive migration, we should move to the version we can support 
longer rather than 11 which will land us back in the same situation we were in 
with 8 EOL

From: Pierre Villard 
Sent: Wednesday, May 31, 2023 4:10:47 PM
To: dev@nifi.apache.org 
Subject: Re: [discuss] nifi 2.0 and Java 17...

Hey Joe,

I'd recommend doing the move right now and say that NiFi 2.0 requires Java
17. And we would focus on Java 21 with NiFi 3.0.
I honestly don't see any value in absolutely keeping support for Java 11
right now.

Pierre

Le mer. 31 mai 2023 à 19:22, Joe Witt  a écrit :

> Team,
>
> We've discussed in the past having NiFi 2.0 move from Java 8 to Java 11 as
> the required minimum while also working on Java 17.
>
> As we move on in time though we are now 4 months (Sept) from. Java 11
> openJDK going end of support.  Meanwhile, the Spring 5.x line goes end of
> support as of next year and Spring 6.x requires Java 17.  Also Java 21
> comes out in Sept as well and is already the next LTS release.
>
> I am increasingly of the view that we should seriously discuss/consider
> moving to Java 17 as our basis for NiFi 2.0 as otherwise it basically means
> we'll be forced to move to NiFi 3.0 quite quickly.
>
> We already know we can build and run on Java 17 so we're good there.  We'll
> soon want to do the same for Java 21 ... and the more 'old stuff' we hold
> on to the harder it is.
>
> Who will be seriously impacted by the removal of Java 11 and what was your
> plan for upgrading to Java 17?
>
> thoughts?
>
> Thanks
>

Re: Use ubi9/OpenJDK-11 as base image

[Kevin Doran]

 Hi Christian,

Thank you for your interest in the Apache NiFi project. At a high-level, I
think this proposal is aligned with the overall long term goals of the
project.

One of the many wished for Docker image improvements [1] is to support
image variants and a more modular image definition that decouples a base
image (with dependencies) from the NiFi-specific installation. Recent and
planned changes that consolidate our docker hub and docker maven source
code bring us closer to tackling this.

This is also related to OpenShift compatibility, which, from what I
understand, works best with RedHat base image. This has come up recently,
see NIFI-9605 [2] and PR #5684 [3], which did propose using ubi8/OpenJDK11.

Perhaps you should leave a comment on NIFI-9605, specifically with some of
the advantages of ubi9/OpenJDK-11 base, so that the dev community can make
an informed decision that takes your needs into account. Also it would be
helpful if you could mention any potential disadvantages we need to
consider. This part of your Dockerfile example seems concerning:

>   # xmlstarlet could be installed by the official way by having a
subscribed RHEL9 host that runs the build (you get free dev licenses)
>   # or we could install the CentOS Stream 9 Appstream version (more hacky)
>   # See
http://fr2.rpmfind.net/linux/RPM/centos-stream/9/appstream/aarch64/xmlstarlet-1.6.1-20.el9.aarch64.html

[1]
https://cwiki.apache.org/confluence/display/NIFI/NiFi+Docker+Container+Improvements

[2] https://issues.apache.org/jira/browse/NIFI-9605
[3] https://github.com/apache/nifi/pull/5684

Regards,
Kevin

On Apr 11, 2023 at 11:02:02, Christian Bucheli <
christian_buch...@hotmail.com> wrote:

> To whom it may concern,
>
> Would it be possible to switch to the ubi9/OpenJDK-11 image instead of the
> one use at the moment. Security wise it receives more updates then the one
> already being used. I can do all the plumbing for making it work.
>
> An example:
> ```Dockerfile
> # Licensed to the Apache Software Foundation (ASF) under one
> # or more contributor license agreements. See the NOTICE file
> # distributed with this work for additional information
> # regarding copyright ownership. The ASF licenses this file
> # to you under the Apache License, Version 2.0 (the
> # "License"); you may not use this file except in compliance
> # with the License. You may obtain a copy of the License at
> #
> #   http://www.apache.org/licenses/LICENSE-2.0
> #
> # Unless required by applicable law or agreed to in writing,
> # software distributed under the License is distributed on an
> # "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> # KIND, either express or implied. See the License for the
> # specific language governing permissions and limitations
> # under the License.
> #
>
> ARG IMAGE_NAME=ubi9/openjdk-11
> ARG IMAGE_TAG=latest
> ARG IMAGE_REGISTRY=registry.access.redhat.com
> FROM ${IMAGE_REGISTRY}/${IMAGE_NAME}:${IMAGE_TAG}
> ARG MAINTAINER="Apache NiFi "
> LABEL maintainer="${MAINTAINER}"
> LABEL site="https://nifi.apache.org";
>
> ARG UID=1001
> ARG GID=1001
> ARG NIFI_VERSION=1.21.0
> ARG BASE_URL=https://archive.apache.org/dist
> ARG MIRROR_BASE_URL=${MIRROR_BASE_URL:-${BASE_URL}}
> ARG DISTRO_PATH=${DISTRO_PATH:-${NIFI_VERSION}}
> ARG
> NIFI_BINARY_PATH=${NIFI_BINARY_PATH:-/nifi/${DISTRO_PATH}/nifi-${NIFI_VERSION}-bin.zip}
> ARG
> NIFI_TOOLKIT_BINARY_PATH=${NIFI_TOOLKIT_BINARY_PATH:-/nifi/${DISTRO_PATH}/nifi-toolkit-${NIFI_VERSION}-bin.zip}
>
> ENV NIFI_BASE_DIR=/opt/nifi
> ENV NIFI_HOME ${NIFI_BASE_DIR}/nifi-current
> ENV NIFI_TOOLKIT_HOME ${NIFI_BASE_DIR}/nifi-toolkit-current
> ENV NIFI_PID_DIR=${NIFI_HOME}/run
> ENV NIFI_LOG_DIR=${NIFI_HOME}/logs
>
> ADD sh/ ${NIFI_BASE_DIR}/scripts/
> USER root
> RUN chmod -R +x ${NIFI_BASE_DIR}/scripts/*.sh
>
> # Setup NiFi user and create necessary directories
> # xmlstarlet could be installed by the official way by having a subscribed
> RHEL9 host that runs the build (you get free dev licenses)
> # or we could install the CentOS Stream 9 Appstream version (more hacky)
> # See
> http://fr2.rpmfind.net/linux/RPM/centos-stream/9/appstream/aarch64/xmlstarlet-1.6.1-20.el9.aarch64.html
> RUN groupadd -g ${GID} nifi || groupmod -n nifi `getent group ${GID} | cut
> -d: -f1` \
>&& useradd --shell /bin/bash -u ${UID} -g ${GID} -m nifi \
>&& mkdir -p ${NIFI_BASE_DIR} \
>&& chown -R nifi:nifi ${NIFI_BASE_DIR} \
>&& microdnf install -y jq procps unzip \
>&& microdnf clean all
>
> RUN chown -R :0 ${NIFI_BASE_DIR} \
>&& chmod -R g+rwX ${NIFI_BASE_DIR}
>
> USER 1001
>
> # Download, validate, and expand Apache NiFi Toolkit binary.
> RUN curl -fSL ${MIRROR_BASE_URL}/${NIFI_TOOLKIT_BINARY_PATH} -o
> ${NIFI_BASE_DIR}/nifi-toolkit-${NIFI_VERSION}-bin.zip \
>&& echo "$(curl ${BASE_URL}/${NIFI_TOOLKIT_BINARY_PATH}.sha256)
> *${NIFI_BASE_DIR}/nifi-toolkit-${NIFI_VERSION}-bin.zip" | sha256sum -c - \
>&& unzip ${NIFI_BASE_DIR}/nifi-toolkit-${NIFI_VERSION}-bin.zip -d
> ${NIFI_

Re: [DISCUSS] MiNiFi C++ 0.14.0 release

[Kevin Doran]

 +1 from me, it seems like a good time for the next release of MiNiFi C++

On Apr 3, 2023 at 07:34:44, Gábor Gyimesi  wrote:

> Hi community,
>
> I'd like to initiate a discussion about the next release of MiNiFi C++. The
> last release was almost four months ago, and there have been many new
> features,
> bug fixes and stability improvements committed to the development branch
> since then: 74 tickets closed, over 80 commits as of today.
>
> I would be happy to take on RM duties for this release.
>
> Notable features and improvements since the 0.14.0 release:
>
> - Several improvements on repository resource handling
>  * Periodically run RocksDB repository compaction+1
>  * Add compression options for RocksDB repositories
>  * Add synchronous flow file reloading
>  * Retry failed removals of unused resources
> - Use Python stable ABI to support all libraries above Python 3.2+ for
> Python processors
> - Add ProcessSession::remove to Python and Lua API
> - Add support for JSON flow configuration format with option to generate
> JSON schema locally
> - Add support for reverseDnsLookup in expression language
> - Fix most issues for ARM64 support
> - Improve performance of ListFile processor
> - Add cache SID lookups in ConsumeWindowsEventLog processor
> - Add default connection size limits of 2000 queue size and 100MB of queue
> data size
> - Add support for MQTT 5 (mistakenly advertised for 0.13.0 release)
> - Add failure relationship to SQL processors
> - Add support for new AWS regions
> - Add option to select processor metrics with regular expressions
> - Add the UUID to the end of Processor and Controller Service log lines
> - Make GetFile path attributes consistent with other processors
> - Fix leaks and file lock issues on Windows
> - Fix crashing in python processors
>
> The core API is still not mature enough to be able to commit to it, so
> in line with previous discussions I suggest releasing it as 0.14.0.
>
> Do you agree it is time for a new release? Are there any blockers that we
> should definitely include in this release?
>
> Thanks,
> Gabor
>

[RESULT][VOTE] Release Apache NiFi NAR Maven Plugin 1.5.0 - RC2

[Kevin Doran]

Apache NiFi Community,

I am pleased to announce that the NiFi NAR Maven Plugin 1.5.0 release
of passes with
5 +1 (binding) votes
1 +1 (non-binding) votes
0 0 votes
0 -1 votes

Thanks to all who helped make this release possible.


On Mar 15, 2023 at 22:09:21, Kevin Doran  wrote:

> +1 (binding)
>
> On Mar 15, 2023 at 10:21:17, Nandor Soma Abonyi
>  wrote:
>
>> +1 (non-binding)
>>
>> - Verified hashes and signatures
>> - Compiled the provided source
>> - Compiled NiFi main with nifi-nar-maven-plugin:1.5.0
>>
>> Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
>> Java version: 11.0.18, vendor: Eclipse Adoptium
>> Default locale: en_US, platform encoding: UTF-8
>> OS name: "mac os x", version: "13.1", arch: "x86_64", family: “mac”
>>
>> Thanks for RM’ing Kevin!
>>
>> Regards,
>> Soma
>>
>> On Mar 14, 2023, at 9:59 PM, Kevin Doran  wrote:
>>
>>
>> Hello Apache NiFi Community,
>>
>>
>> Issues with RC1 have been addressed in RC2, and I am pleased to again
>>
>> be calling this vote for the source release of Apache NiFi NAR Maven
>>
>> Plugin 1.5.0.
>>
>>
>> The source being voted upon, including signatures, digests, etc. can
>>
>> be found at:
>>
>>
>> https://repository.apache.org/content/repositories/orgapachenifi-1222/org/apache/nifi/nifi-nar-maven-plugin/1.5.0/
>>
>>
>> The Git tag is nifi-nar-maven-plugin-1.5.0-RC2
>>
>> The Git commit ID is 277f9e8998ca76a972c90d8ecf3f771414c86700
>>
>>
>> https://gitbox.apache.org/repos/asf?p=nifi-maven.git;a=commit;h=277f9e8998ca76a972c90d8ecf3f771414c86700
>>
>>
>> Checksum of nifi-nar-maven-plugin-1.5.0-source-release.zip:
>>
>>
>> SHA512:
>> a265587f8bfb31359cae2335394d88d76d36ae9806030e38fc9846264f20a4e70d642c4f0c08425b843794aaabaeea416b1104ede26671ffcbe001e1976d4efd
>>
>>
>> Release artifacts are signed with the following key:
>>
>> https://people.apache.org/keys/committer/kdoran.asc
>>
>>
>> KEYS file available here:
>>
>> https://dist.apache.org/repos/dist/release/nifi/KEYS
>>
>>
>> 4 issues were closed/resolved for this release:
>>
>> https://issues.apache.org/jira/projects/NIFI/versions/12352895
>>
>>
>> Release note highlights can be found here:
>>
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12352895
>>
>>
>> *The vote will be open for 24 hours.* Please download the release
>>
>> candidate and evaluate the necessary items including checking hashes,
>>
>> signatures, build from source, and test. Then please vote:
>>
>>
>> [ ] +1 Release this package as nifi-nar-maven-plugin-1.5.0
>>
>> [ ] +0 no opinion
>>
>> [ ] -1 Do not release this package because ...
>>
>>
>>

Re: [VOTE] Release Apache NiFi NAR Maven Plugin 1.5.0 - RC2

[Kevin Doran]

 +1 (binding)

On Mar 15, 2023 at 10:21:17, Nandor Soma Abonyi 
wrote:

> +1 (non-binding)
>
> - Verified hashes and signatures
> - Compiled the provided source
> - Compiled NiFi main with nifi-nar-maven-plugin:1.5.0
>
> Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> Java version: 11.0.18, vendor: Eclipse Adoptium
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "13.1", arch: "x86_64", family: “mac”
>
> Thanks for RM’ing Kevin!
>
> Regards,
> Soma
>
> On Mar 14, 2023, at 9:59 PM, Kevin Doran  wrote:
>
>
> Hello Apache NiFi Community,
>
>
> Issues with RC1 have been addressed in RC2, and I am pleased to again
>
> be calling this vote for the source release of Apache NiFi NAR Maven
>
> Plugin 1.5.0.
>
>
> The source being voted upon, including signatures, digests, etc. can
>
> be found at:
>
>
> https://repository.apache.org/content/repositories/orgapachenifi-1222/org/apache/nifi/nifi-nar-maven-plugin/1.5.0/
>
>
> The Git tag is nifi-nar-maven-plugin-1.5.0-RC2
>
> The Git commit ID is 277f9e8998ca76a972c90d8ecf3f771414c86700
>
>
> https://gitbox.apache.org/repos/asf?p=nifi-maven.git;a=commit;h=277f9e8998ca76a972c90d8ecf3f771414c86700
>
>
> Checksum of nifi-nar-maven-plugin-1.5.0-source-release.zip:
>
>
> SHA512:
> a265587f8bfb31359cae2335394d88d76d36ae9806030e38fc9846264f20a4e70d642c4f0c08425b843794aaabaeea416b1104ede26671ffcbe001e1976d4efd
>
>
> Release artifacts are signed with the following key:
>
> https://people.apache.org/keys/committer/kdoran.asc
>
>
> KEYS file available here:
>
> https://dist.apache.org/repos/dist/release/nifi/KEYS
>
>
> 4 issues were closed/resolved for this release:
>
> https://issues.apache.org/jira/projects/NIFI/versions/12352895
>
>
> Release note highlights can be found here:
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12352895
>
>
> *The vote will be open for 24 hours.* Please download the release
>
> candidate and evaluate the necessary items including checking hashes,
>
> signatures, build from source, and test. Then please vote:
>
>
> [ ] +1 Release this package as nifi-nar-maven-plugin-1.5.0
>
> [ ] +0 no opinion
>
> [ ] -1 Do not release this package because ...
>
>
>

Apache NiFi NAR Maven Plugin 1.5.0 RC2 Release Helper Guide

[Kevin Doran]

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/dev/nifi/KEYS

# Import keys file:
gpg --import KEYS

# [optional] Clear out local maven artifact repository

# Pull down nifi-nar-maven-plugin-1.5.0 source release artifacts for review:

wget 
https://repository.apache.org/content/repositories/orgapachenifi-1222/org/apache/nifi/nifi-nar-maven-plugin/1.5.0/nifi-nar-maven-plugin-1.5.0-source-release.zip
wget 
https://repository.apache.org/content/repositories/orgapachenifi-1222/org/apache/nifi/nifi-nar-maven-plugin/1.5.0/nifi-nar-maven-plugin-1.5.0-source-release.zip.asc
wget 
https://repository.apache.org/content/repositories/orgapachenifi-1222/org/apache/nifi/nifi-nar-maven-plugin/1.5.0/nifi-nar-maven-plugin-1.5.0-source-release.zip.sha512

# Verify the signature
gpg --verify -v nifi-nar-maven-plugin-1.5.0-source-release.zip.asc

# Verify the hash (sha512) matches the source and what was provided in
the vote email thread
shasum -a 512 nifi-nar-maven-plugin-1.5.0-source-release.zip

# Verify the build works including release audit tool (RAT) checks
unzip nifi-nar-maven-plugin-1.5.0-source-release.zip
cd nifi-nar-maven-plugin-1.5.0
mvn clean install -Pcontrib-check

# Verify the contents contain a good README, NOTICE, and LICENSE.
# Verify the git commit ID is correct
# Verify the RC was branched off the correct git commit ID

# Verify that NiFi can build NARs correctly using the plugin

- Update NiFi's root pom to use version 1.5.0 of the
pluginhttps://github.com/apache/nifi/blob/main/pom.xml#L101

- Perform a build of NiFi, optionally clear out local .m2 repo
mvn clean install

- Ensure that NiFi starts and loads all processors, controller
services, and reporting tasks

- Spot check a few NARs to ensure they include
META-INF/docs/extension-manifest.xml
cp NIFI_HOME/lib/nifi-xyz-bundle.nar /tmp
cd /tmp
unzip nifi-xyz-bundle.nar
cat META-INF/docs/extension-manifest.xml

# Send a response to the vote thread indicating a +1, 0, -1 based on
your findings.

Thank you for your time and effort to validate the release!

Kevin

[VOTE] Release Apache NiFi NAR Maven Plugin 1.5.0 - RC2

[Kevin Doran]

Hello Apache NiFi Community,

Issues with RC1 have been addressed in RC2, and I am pleased to again
be calling this vote for the source release of Apache NiFi NAR Maven
Plugin 1.5.0.

The source being voted upon, including signatures, digests, etc. can
be found at:
https://repository.apache.org/content/repositories/orgapachenifi-1222/org/apache/nifi/nifi-nar-maven-plugin/1.5.0/

The Git tag is nifi-nar-maven-plugin-1.5.0-RC2
The Git commit ID is 277f9e8998ca76a972c90d8ecf3f771414c86700
https://gitbox.apache.org/repos/asf?p=nifi-maven.git;a=commit;h=277f9e8998ca76a972c90d8ecf3f771414c86700

Checksum of nifi-nar-maven-plugin-1.5.0-source-release.zip:

SHA512: 
a265587f8bfb31359cae2335394d88d76d36ae9806030e38fc9846264f20a4e70d642c4f0c08425b843794aaabaeea416b1104ede26671ffcbe001e1976d4efd

Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/kdoran.asc

KEYS file available here:
https://dist.apache.org/repos/dist/release/nifi/KEYS

4 issues were closed/resolved for this release:
https://issues.apache.org/jira/projects/NIFI/versions/12352895

Release note highlights can be found here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12352895

*The vote will be open for 24 hours.* Please download the release
candidate and evaluate the necessary items including checking hashes,
signatures, build from source, and test. Then please vote:

[ ] +1 Release this package as nifi-nar-maven-plugin-1.5.0
[ ] +0 no opinion
[ ] -1 Do not release this package because ...

[CANCELED][VOTE] Release Apache NiFi NAR Maven Plugin 1.5.0

[Kevin Doran]

Thanks Joe and Jeremy. Those are legit failures. This vote is canceled,
will get that fixed and turn around a RC2.

Thanks,
Kevin

On Mar 13, 2023 at 17:39:27, Jeremy Dyer  wrote:

> -1 seeing same contrib check failures as Joe on Ubuntu 22 X86 machine
>
> (base) ➜  nifi-nar-maven-plugin-1.5.0 mvn --version
> Apache Maven 3.6.3
> Maven home: /usr/share/maven
> Java version: 17.0.6, vendor: Private Build, runtime:
> /usr/lib/jvm/java-17-openjdk-amd64
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.19.0-35-generic", arch: "amd64", family:
> "unix"
>
> I too could very well be doing something wrong.
>
> - Jeremy Dyer
>
>
> On Mon, Mar 13, 2023 at 5:30 PM Joe Witt  wrote:
>
> -1 (subject to change if I've done something goofy)
>
>
> I find contrib check failures.
>
>
> [INFO] --- checkstyle:3.2.0:check (check-style) @ nifi-nar-maven-plugin ---
>
> [WARNING] src/main/java/org/apache/nifi/NarMojo.java:[29,8] (imports)
>
> UnusedImports: Unused import -
>
> org.apache.maven.artifact.repository.RepositoryRequest.
>
> [WARNING] src/main/java/org/apache/nifi/NarMojo.java:[30,8] (imports)
>
> UnusedImports: Unused import -
>
> org.apache.maven.artifact.resolver.ArtifactNotFoundException.
>
> [WARNING] src/main/java/org/apache/nifi/NarMojo.java:[31,8] (imports)
>
> UnusedImports: Unused import -
>
> org.apache.maven.artifact.resolver.ArtifactResolutionException.
>
> [WARNING] src/main/java/org/apache/nifi/NarMojo.java:[984,17] (blocks)
>
> LeftCurly: '{' at column 17 should be on the previous line.
>
> [WARNING]
>
>
> src/test/java/org/apache/nifi/extension/definition/extraction/ExtensionClassLoaderFactoryTest.java:[127]
>
> (regexp) RegexpSinglelineJava: Line has trailing whitespace.
>
>
> After actually removing/changing the mentioned lines it works as expected.
>
>
> Thanks
>
> Joe
>
>
> On Mon, Mar 13, 2023 at 12:57 PM Kevin Doran  wrote:
>
> >
>
> >  Edit: I meant to say that due to the narrow scope of this release and
>
> the
>
> > fact that it is currently blocking release of Apache NiFi 1.21.0, this
>
> vote
>
> > will be open for 24 hours as opposed to the normal 72 hours.
>
> >
>
> > On Mar 13, 2023 at 15:56:22, Kevin Doran  wrote:
>
> >
>
> > > Hello Apache NiFi Community,
>
> > >
>
> > > I am pleased to be calling this vote for the source release of Apache
>
> NiFi NAR Maven Plugin 1.5.0.
>
> > >
>
> > > The source being voted upon, including signatures, digests, etc. can
>
> be found at:
>
> > >
>
>
> https://repository.apache.org/content/repositories/orgapachenifi-1221/org/apache/nifi/nifi-nar-maven-plugin/1.5.0/
>
> > >
>
> > > The Git tag is nifi-nar-maven-plugin-1.5.0-RC1
>
> > > The Git commit ID is ec2635b0474994861d3225538168e46638c0d2bb
>
> > >
>
>
> https://gitbox.apache.org/repos/asf?p=nifi-maven.git;a=commit;h=09d7bb9ff679d0eed9feaa066d2cbdd347a20204
>
> > >
>
> > > Checksum of nifi-nar-maven-plugin-1.5.0-source-release.zip:
>
> > >
>
> > > SHA512:
>
>
> f4b5ab2286319bd53ce5d872008667f63804ca77640e89e15759ffa26743b6854d642a8dec7784fbfc32fcccdfeb7b6b9a3c4daa00886d5d13161b1c2ed47c7f
>
> > >
>
> > > Release artifacts are signed with the following key:
>
> > > https://people.apache.org/keys/committer/kdoran.asc
>
> > >
>
> > > KEYS file available here:
>
> > > https://dist.apache.org/repos/dist/release/nifi/KEYS
>
> > >
>
> > > 3 issues were closed/resolved for this release:
>
> > > https://issues.apache.org/jira/projects/NIFI/versions/12352895
>
> > >
>
> > > Release note highlights can be found here:
>
> > >
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12352895
>
> > >
>
> > > The vote will be open for 72 hours. Please download the release
>
> candidate and evaluate the necessary items including checking hashes,
>
> signatures, build from source, and test. Then please vote:
>
> > >
>
> > > [ ] +1 Release this package as nifi-nar-maven-plugin-1.5.0
>
> > > [ ] +0 no opinion
>
> > > [ ] -1 Do not release this package because ...
>
> > >
>
> > >
>
>
>

Re: [VOTE] Release Apache NiFi NAR Maven Plugin 1.5.0

[Kevin Doran]

 Edit: I meant to say that due to the narrow scope of this release and the
fact that it is currently blocking release of Apache NiFi 1.21.0, this vote
will be open for 24 hours as opposed to the normal 72 hours.

On Mar 13, 2023 at 15:56:22, Kevin Doran  wrote:

> Hello Apache NiFi Community,
>
> I am pleased to be calling this vote for the source release of Apache NiFi 
> NAR Maven Plugin 1.5.0.
>
> The source being voted upon, including signatures, digests, etc. can be found 
> at:
> https://repository.apache.org/content/repositories/orgapachenifi-1221/org/apache/nifi/nifi-nar-maven-plugin/1.5.0/
>
> The Git tag is nifi-nar-maven-plugin-1.5.0-RC1
> The Git commit ID is ec2635b0474994861d3225538168e46638c0d2bb
> https://gitbox.apache.org/repos/asf?p=nifi-maven.git;a=commit;h=09d7bb9ff679d0eed9feaa066d2cbdd347a20204
>
> Checksum of nifi-nar-maven-plugin-1.5.0-source-release.zip:
>
> SHA512: 
> f4b5ab2286319bd53ce5d872008667f63804ca77640e89e15759ffa26743b6854d642a8dec7784fbfc32fcccdfeb7b6b9a3c4daa00886d5d13161b1c2ed47c7f
>
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/kdoran.asc
>
> KEYS file available here:
> https://dist.apache.org/repos/dist/release/nifi/KEYS
>
> 3 issues were closed/resolved for this release:
> https://issues.apache.org/jira/projects/NIFI/versions/12352895
>
> Release note highlights can be found here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12352895
>
> The vote will be open for 72 hours. Please download the release candidate and 
> evaluate the necessary items including checking hashes, signatures, build 
> from source, and test. Then please vote:
>
> [ ] +1 Release this package as nifi-nar-maven-plugin-1.5.0
> [ ] +0 no opinion
> [ ] -1 Do not release this package because ...
>
>

Apache NiFi NAR Maven Plugin 1.5.0 RC1 Release Helper Guide

[Kevin Doran]

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/dev/nifi/KEYS

# Import keys file:
gpg --import KEYS

# [optional] Clear out local maven artifact repository

# Pull down nifi-nar-maven-plugin-1.5.0 source release artifacts for review:

wget 
https://repository.apache.org/content/repositories/orgapachenifi-1221/org/apache/nifi/nifi-nar-maven-plugin/1.5.0/nifi-nar-maven-plugin-1.5.0-source-release.zip
wget 
https://repository.apache.org/content/repositories/orgapachenifi-1221/org/apache/nifi/nifi-nar-maven-plugin/1.5.0/nifi-nar-maven-plugin-1.5.0-source-release.zip.asc
wget 
https://repository.apache.org/content/repositories/orgapachenifi-1221/org/apache/nifi/nifi-nar-maven-plugin/1.5.0/nifi-nar-maven-plugin-1.5.0-source-release.zip.sha512

# Verify the signature
gpg --verify -v nifi-nar-maven-plugin-1.5.0-source-release.zip.asc

# Verify the hash (sha512) matches the source and what was provided in
the vote email thread
shasum -a 512 nifi-nar-maven-plugin-1.5.0-source-release.zip

# Verify the build works including release audit tool (RAT) checks
unzip nifi-nar-maven-plugin-1.5.0-source-release.zip
cd nifi-nar-maven-plugin-1.5.0
mvn clean install -Pcontrib-check

# Verify the contents contain a good README, NOTICE, and LICENSE.
# Verify the git commit ID is correct
# Verify the RC was branched off the correct git commit ID

# Verify that NiFi can build NARs correctly using the plugin

- Update NiFi's root pom to use version 1.5.0 of the
pluginhttps://github.com/apache/nifi/blob/main/pom.xml#L101

- Perform a build of NiFi, optionally clear out local .m2 repo
mvn clean install

- Ensure that NiFi starts and loads all processors, controller
services, and reporting tasks

- Spot check a few NARs to ensure they include
META-INF/docs/extension-manifest.xml
cp NIFI_HOME/lib/nifi-xyz-bundle.nar /tmp
cd /tmp
unzip nifi-xyz-bundle.nar
cat META-INF/docs/extension-manifest.xml

# Send a response to the vote thread indicating a +1, 0, -1 based on
your findings.

Thank you for your time and effort to validate the release!

Kevin

[VOTE] Release Apache NiFi NAR Maven Plugin 1.5.0

[Kevin Doran]

Hello Apache NiFi Community,

I am pleased to be calling this vote for the source release of Apache
NiFi NAR Maven Plugin 1.5.0.

The source being voted upon, including signatures, digests, etc. can
be found at:
https://repository.apache.org/content/repositories/orgapachenifi-1221/org/apache/nifi/nifi-nar-maven-plugin/1.5.0/

The Git tag is nifi-nar-maven-plugin-1.5.0-RC1
The Git commit ID is ec2635b0474994861d3225538168e46638c0d2bb
https://gitbox.apache.org/repos/asf?p=nifi-maven.git;a=commit;h=09d7bb9ff679d0eed9feaa066d2cbdd347a20204

Checksum of nifi-nar-maven-plugin-1.5.0-source-release.zip:

SHA512: 
f4b5ab2286319bd53ce5d872008667f63804ca77640e89e15759ffa26743b6854d642a8dec7784fbfc32fcccdfeb7b6b9a3c4daa00886d5d13161b1c2ed47c7f

Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/kdoran.asc

KEYS file available here:
https://dist.apache.org/repos/dist/release/nifi/KEYS

3 issues were closed/resolved for this release:
https://issues.apache.org/jira/projects/NIFI/versions/12352895

Release note highlights can be found here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12352895

The vote will be open for 72 hours. Please download the release
candidate and evaluate the necessary items including checking hashes,
signatures, build from source, and test. Then please vote:

[ ] +1 Release this package as nifi-nar-maven-plugin-1.5.0
[ ] +0 no opinion
[ ] -1 Do not release this package because ...

Re: [discuss] plan to kick out NiFi 1.20.1

[Kevin Doran]

 Thanks, Joe. Will do.

On Mar 13, 2023 at 12:57:06, Joe Witt  wrote:

> Kevin - yeah sorry I meant to hang tight for that but was forgetting.
> Will sit still and will participate in the vote thread.
>
> Given the very narrow scope of that change I suggest a 24 hour vote to
> fix/release.  Worth considering
>
> On Mon, Mar 13, 2023 at 9:55 AM Kevin Doran  wrote:
>
>
> I'm fine with 1.21.0 vs 1.20.1.
>
>
> Either way, It might be worthwhile waiting for the NiFi NAR Maven Plugin
>
> 1.5.0 to be released, so we can use that in NiFi 1.21.0.
>
>
> For external NAR projects that inherit from nifi-nar-bundles as their
>
> parent, they are stuck on NiFi 1.19.0 due to NIFI-11217 fixed in the next
>
> plugin release.
>
>
> I should have NiFi NAR Maven Plugin 1.5.0 RC1 ready for voting today.
>
>
> Thanks,
>
> Kevin
>
>
> On Mar 13, 2023 at 12:49:00, Joe Witt  wrote:
>
>
> > Team,
>
> >
>
> > In starting to get this ball rolling it seems to me we should just
>
> > kick out 1.21.0.  There are already 50 JIRAs there.  Nothing feature
>
> > wise just a bunch of bugs, improvements, tasks
>
> >
>
> > But it doesn't seem worthwhile to cherry-pick at this stage to me.
>
> > I'll start the RC process now with 1.21.0 but if someone has a strong
>
> > preference/objection please share and I'll keep watching here.
>
> >
>
> > Thanks
>
> >
>
> > On Thu, Mar 9, 2023 at 1:59 PM Pierre Villard
>
> >  wrote:
>
> >
>
> >
>
> > +1 for a 1.20.1 - we also fixed a few bugs around NiFi Registry
>
> >
>
> >
>
> > Le jeu. 9 mars 2023 à 21:01, Joe Witt  a écrit :
>
> >
>
> >
>
> > > Team,
>
> >
>
> > >
>
> >
>
> > > I'm thinking we should kick out a 1.20.1.
>
> >
>
> > >
>
> >
>
> > > This one is pretty annoying and we've seen a few folks hit it
>
> >
>
> > > https://issues.apache.org/jira/browse/NIFI-11189
>
> >
>
> > >
>
> >
>
> > > I'll sweep up all bugs and keep an eye on the pending maven nar nifi
>
> >
>
> > > plugin fix that seems poised for release and ideally draft right off
>
> >
>
> > > that.
>
> >
>
> > >
>
> >
>
> > > Thanks
>
> >
>
> > > Joe
>
> >
>
> > >
>
> >
>
> >
>
>

Re: [discuss] plan to kick out NiFi 1.20.1

[Kevin Doran]

I'm fine with 1.21.0 vs 1.20.1.

Either way, It might be worthwhile waiting for the NiFi NAR Maven Plugin
1.5.0 to be released, so we can use that in NiFi 1.21.0.

For external NAR projects that inherit from nifi-nar-bundles as their
parent, they are stuck on NiFi 1.19.0 due to NIFI-11217 fixed in the next
plugin release.

I should have NiFi NAR Maven Plugin 1.5.0 RC1 ready for voting today.

Thanks,
Kevin

On Mar 13, 2023 at 12:49:00, Joe Witt  wrote:

> Team,
>
> In starting to get this ball rolling it seems to me we should just
> kick out 1.21.0.  There are already 50 JIRAs there.  Nothing feature
> wise just a bunch of bugs, improvements, tasks
>
> But it doesn't seem worthwhile to cherry-pick at this stage to me.
> I'll start the RC process now with 1.21.0 but if someone has a strong
> preference/objection please share and I'll keep watching here.
>
> Thanks
>
> On Thu, Mar 9, 2023 at 1:59 PM Pierre Villard
>  wrote:
>
>
> +1 for a 1.20.1 - we also fixed a few bugs around NiFi Registry
>
>
> Le jeu. 9 mars 2023 à 21:01, Joe Witt  a écrit :
>
>
> > Team,
>
> >
>
> > I'm thinking we should kick out a 1.20.1.
>
> >
>
> > This one is pretty annoying and we've seen a few folks hit it
>
> > https://issues.apache.org/jira/browse/NIFI-11189
>
> >
>
> > I'll sweep up all bugs and keep an eye on the pending maven nar nifi
>
> > plugin fix that seems poised for release and ideally draft right off
>
> > that.
>
> >
>
> > Thanks
>
> > Joe
>
> >
>
>

[DISCUSS] Release NiFi NAR Maven Plugin 1.5.0

[Kevin Doran]

Hi NiFi dev community,

Thank you all for participating in the recent 1.40 release of the NiFi NAR
Maven plugin. Unfortunately, it introduced a bug that prevents building
some NARs outside of the apache/nifi repository [1]. Thanks to community
member Julien G on Apache NiFi Slack for reporting and helping us diagnose
the issue.

Given that this bug was related to a dependency upgrade, those of us
investigating it noticed during the investigation that a number of the core
dependencies for our plugin were quite old. Upgrading all dependencies was
done as well [2]. As this was a large change that touched many classes, we
are making the next release of the plugin a minor version bump even though
are no new features being added.

I plan to prepare a NiFi NAR Maven Plugin 1.5.0 RC soon to vote on. If
there is anything else we should consider including as part of this
release, please mention it on this thread.

[1] https://issues.apache.org/jira/browse/NIFI-11217
[2] https://issues.apache.org/jira/browse/NIFI-11218

Thanks!
Kevin

Re: [discuss] NiFi 1.20 and NiFi 2.0

[Kevin Doran]

Witt  joe.w...@gmail.com>>
> wrote:
> br/>>> Team <
> br/>>> As you commit to the main line now pleease start using whatever
> the latest relevant feature release is on the 2.x line which right now
> would be 2.0.0. If we find we need to do a 1.21 and so on we'll pull those
> commits down as we would for any other mx release in the past but the
> 'main' line becomes 2.0.0 now.
> br/>>> Thanks <
> Joe
> br/>>> On Mon, FFeb 6, 2023 at 10:44 AM Joe Witt  <mailto:joe.w...@gmail.com>>
> wrote:
> br/>>>> Team, <
> br/>>>> I think we are there!! Going to kick out RC1 now.
> br/>>>> Thanks <
> br/>>>> On Mon, Jan 30, 2023 at 11:29 AM Joe Witt  <mailto:joe.w...@gmail.com>>
> wrote:
> br/>>>>> Team, <
> br/>>>>> As you can see I've noot kicked off the RC yet. Many bug
> fixes/dependency updates are happening. Ideally we'll wait until nar Maven
> plugin goes and we're trying to fix some nifi registry/nifi interaction
> issues as well. Still will get the RC out as soon as we can.
> br/>>>>> Thanks <
> br/>>>>> On Mon, Jan 23, 2023 aat 11:12 AM Joe Witt  <mailto:joe.w...@gmail.com>>
> wrote:
> br/>>>>>> Hello <
> br/>>>>>> Here is a goodd picture of what the 1.20 RC looks like.
> I've tagged several JIRAs today to ensure we get them in. A theme is really
> around stabilizing nifi/nifi-registry integration as we're seeing
> substantial uptick in usage and thus various community reported findings.
> We'll get that quite smooth with these included.
> br/>>>>>> https://issues<https://issues/>..
> apache.org/jira/projects/NIFI/versions/12352581<
> http://apache.org/jira/projects/NIFI/versions/12352581>
> br/>>>>>> Thanks <
> br/>>>>>> On Mon, Jan 233, 2023 at 8:50 AM Joe Witt <
> joe.w...@gmail.com<mailto:joe.w...@gmail.com>> wrote:
> br/>>>>>>> Team, <
> br/>>>>>>> I'm goiing through the outstanding JIRAs/PRs and flagging
> which look like they should be 'must have' for 1.20 and then will work the
> RC as soon as those land.
> br/>>>>>>> Hopefullly have the RC up within a day or two but we'll
> see how these land as some have review comments pending action.
> br/>>>>>>> Thanks
> br/>>>>>>> On Thu,, Jan 12, 2023 at 2:53 AM Isha Lamboo <
> isha.lam...@virtualsciences.nl<mailto:isha.lam...@virtualsciences.nl>>
> wrote:
> br/>>>>>>>>; Hi all,
> br/>>>>>>>>; I would like to contribute to the migration tooling
> (mostly testing I suppose) when that comes up.
> br/>>>>>>>>; My team's largest client has a completely
> template-based pipeline with external scripts replacing variable values
> before deploying to target clusters, so we've already started looking at
> this when the goals for 2.0 were discussed and approved. The migration to
> flowdefinitions and parameters is quite complex and we've hit several
> blockers when we tried to implement a direct translation.
> br/>>>>>>>>; I expect that any time I spend helping to improve the
> tooling will pay off handsomely for our clients.
> br/>>>>>>>>; Regards,
> br/>>>>>>>>; Isha
> br/>>>>>>>>; -Oorspronkelijk bericht-
> Van: Adam Taft mailto:a...@adamtaft.com>>
> Verzonden: woensdag 11 januari 2023 23:42
> Aan: dev@nifi.apache.org<mailto:dev@nifi.apache.org>
> Onderwerp: Re: [discuss] NiFi 1.20 and NiFi 2.0
> br/>>>>>>>>; This is really insightful and spot on ...
> br/>>>>>>>>; Kevin wrote:
> Good migration tooling will take a while to develop and test, and
> the
> core contributors to that effort may not have sufficient variety
> of
> flows to evaluate when the migration tools are "done" for the
> majority
> of the community to have success upgrading to 2.x. A milestone
> release
> would
> allow
> us get more feedback on migration over a longer period than the
> vote
> window
> of an RC candidate.
> br/>>>>>>>>; It's exactly this case, that an early 2.0 release
> might not have had time to fully work its way through existing production
> deployments, that's concerning. The pace and voting of an "RC" is much too
> short to get any quality feedba

Re: [VOTE] Release Apache NiFi 1.20.0 (RC1)

[Kevin Doran]

 +1 (binding)

Ran through the normal verification steps / checked signatures and hashes.
All looks good.

Thanks for RM’ing, Joe!

Kevin

On Feb 8, 2023 at 14:33:31, Nissim Shiman  wrote:

> +1 (non-binding)
>
> verified source release sha256/512 checksums
>
>
> built and ran successfully using:Apache Maven 3.6.3 Java openjdk version:
> 1.8.0_352
> linux kernel 3.10.0-1160
>
>
> Verified various simple flows.
>
> Noticed issue where content viewer doesn't handle very large files (i.e.
> 100MB) well.  nifi screen looses look and feel when this occurs and
> displays OutOfMemoryError
>
> Put in a jira for this  https://issues.apache.org/jira/browse/NIFI-11153
>
> This would be a very limited user initiated edge case, so I don't think
> this is a blocker.
>
>
> Thank you for the upcoming release!
>
> Nissim Shiman
>
>
>On Monday, February 6, 2023 at 08:56:10 PM UTC, Joe Witt <
> joew...@apache.org> wrote:
>
> Hello,
>
> I am pleased to be calling this vote for the source release of Apache NiFi
> 1.20.0.
>
> The source zip, including signatures, digests, etc. can be found at:
> https://repository.apache.org/content/repositories/orgapachenifi-1220
>
> The source being voted upon and the convenience binaries can be found at:
> https://dist.apache.org/repos/dist/dev/nifi/nifi-1.20.0/
>
> A helpful reminder on how the release candidate verification process works:
>
> https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+release+candidate
>
> The Git tag is nifi-1.20.0-RC1
> The Git commit ID is 81296b5b69a69d26afb8f8dec3a58a8363653890
>
> https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=81296b5b69a69d26afb8f8dec3a58a8363653890
>
> Checksums of nifi-1.20.0-source-release.zip:
> SHA256: 694e9eec951caf628576a2aaa16e7ddadc11b9bf455f16d503bdd88aefdbfe66
> SHA512:
>
> f54891aadbf58eaf4df465e99eb935ddbb47c70c1e329968098762f670eeed56a427ed88f21f150c056f8b057f7120127f3470afe4f4f89b80d659d7b8080339
>
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/joewitt.asc
>
> KEYS file available here:
> https://dist.apache.org/repos/dist/release/nifi/KEYS
>
> 205 issues were closed/resolved for this release:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12352581
>
> Release note highlights can be found here:
>
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.20.0
>
> The vote will be open for 72 hours.
> Please download the release candidate and evaluate the necessary items
> including checking hashes, signatures, build
> from source, and test. Then please vote:
>
> [ ] +1 Release this package as nifi-1.20.0
> [ ] +0 no opinion
> [ ] -1 Do not release this package because...
>
>

[RESULT][VOTE] Release Apache NiFi NAR Maven Plugin 1.4.0

[Kevin Doran]

Apache NiFi Community,

I am pleased to announce that the nifi-nar-maven-plugin-1.4.0 release
passes with
5 +1 (binding) votes
2 +1 (non-binding) votes
0 0 votes
0 -1 votes

Thanks to all who helped make this release possible.

Here is the vote thread:
https://lists.apache.org/thread/tvqqpy4w0nv6w8m05y749f9gv35f5268

I will finalize the release artifacts and send the announcement email tomorrow.


On Feb 2, 2023 at 18:17:56, Kevin Doran  wrote:

> +1, binding
>
> On Feb 2, 2023 at 16:23:17, David Handermann 
> wrote:
>
>> +1 binding
>>
>> - Verified hashes
>> - Ran build using Maven 3.8.7
>> - Ran build on Ubuntu 22.04 with Azul Zulu JDK 1.8.0-352 x86_64
>> - Ran build on Ubuntu 22.04 with Azul Zulu JDK 17.0.5 x86_64
>> - Ran NiFi main branch build using NAR Plugin
>> - Ran build of selected NAR modules using new duplicate-nar-dependencies
>> goal
>>
>> Thanks Kevin!
>>
>> Regards,
>> David Handermann
>>
>> On Mon, Jan 30, 2023 at 5:19 PM Kevin Doran  wrote:
>>
>> Hello Apache NiFi Community,
>>
>>
>> I am pleased to be calling this vote for the source release of Apache
>>
>> NiFi NAR Maven Plugin 1.4.0.
>>
>>
>> The source being voted upon, including signatures, digests, etc. can
>>
>> be found at:
>>
>>
>>
>> https://repository.apache.org/content/repositories/orgapachenifi-1219/org/apache/nifi/nifi-nar-maven-plugin/1.4.0/
>>
>>
>> The Git tag is nifi-nar-maven-plugin-1.4.0-RC1
>>
>> The Git commit ID is 09d7bb9ff679d0eed9feaa066d2cbdd347a20204
>>
>>
>>
>> https://gitbox.apache.org/repos/asf?p=nifi-maven.git;a=commit;h=09d7bb9ff679d0eed9feaa066d2cbdd347a20204
>>
>>
>> Checksum of nifi-nar-maven-plugin-1.4.0-source-release.zip
>>
>>
>> SHA512:
>>
>>
>> d48bfde8a5bab8a17b320889297c09efa162a7017db2268e274db626926ff9b58173abab54db4e1a50b5664fc86a9501ce2ef267b3e3b768eb80ef5c929860c9
>>
>>
>> Release artifacts are signed with the following key:
>>
>> https://people.apache.org/keys/committer/kdoran.asc
>>
>>
>> KEYS file available here:
>>
>> https://dist.apache.org/repos/dist/release/nifi/KEYS
>>
>>
>> 6 issues were closed/resolved for this release:
>>
>>
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12352124
>>
>>
>> Release note highlights can be found here:
>>
>>
>>
>> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-NiFiNARMavenPluginVersion1.4.0
>>
>>
>> The vote will be open for 72 hours. Please download the release
>>
>> candidate and evaluate the necessary items including checking hashes,
>>
>> signatures, build from source, and test. Then please vote:
>>
>>
>> [ ] +1 Release this package as nifi-nar-maven-plugin-1.4.0
>>
>> [ ] +0 no opinion
>>
>> [ ] -1 Do not release this package because ...
>>
>>
>>

Re: [VOTE] Release Apache NiFi NAR Maven Plugin 1.4.0

[Kevin Doran]

 +1, binding

On Feb 2, 2023 at 16:23:17, David Handermann 
wrote:

> +1 binding
>
> - Verified hashes
> - Ran build using Maven 3.8.7
> - Ran build on Ubuntu 22.04 with Azul Zulu JDK 1.8.0-352 x86_64
> - Ran build on Ubuntu 22.04 with Azul Zulu JDK 17.0.5 x86_64
> - Ran NiFi main branch build using NAR Plugin
> - Ran build of selected NAR modules using new duplicate-nar-dependencies
> goal
>
> Thanks Kevin!
>
> Regards,
> David Handermann
>
> On Mon, Jan 30, 2023 at 5:19 PM Kevin Doran  wrote:
>
> Hello Apache NiFi Community,
>
>
> I am pleased to be calling this vote for the source release of Apache
>
> NiFi NAR Maven Plugin 1.4.0.
>
>
> The source being voted upon, including signatures, digests, etc. can
>
> be found at:
>
>
>
> https://repository.apache.org/content/repositories/orgapachenifi-1219/org/apache/nifi/nifi-nar-maven-plugin/1.4.0/
>
>
> The Git tag is nifi-nar-maven-plugin-1.4.0-RC1
>
> The Git commit ID is 09d7bb9ff679d0eed9feaa066d2cbdd347a20204
>
>
>
> https://gitbox.apache.org/repos/asf?p=nifi-maven.git;a=commit;h=09d7bb9ff679d0eed9feaa066d2cbdd347a20204
>
>
> Checksum of nifi-nar-maven-plugin-1.4.0-source-release.zip
>
>
> SHA512:
>
>
> d48bfde8a5bab8a17b320889297c09efa162a7017db2268e274db626926ff9b58173abab54db4e1a50b5664fc86a9501ce2ef267b3e3b768eb80ef5c929860c9
>
>
> Release artifacts are signed with the following key:
>
> https://people.apache.org/keys/committer/kdoran.asc
>
>
> KEYS file available here:
>
> https://dist.apache.org/repos/dist/release/nifi/KEYS
>
>
> 6 issues were closed/resolved for this release:
>
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12352124
>
>
> Release note highlights can be found here:
>
>
>
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-NiFiNARMavenPluginVersion1.4.0
>
>
> The vote will be open for 72 hours. Please download the release
>
> candidate and evaluate the necessary items including checking hashes,
>
> signatures, build from source, and test. Then please vote:
>
>
> [ ] +1 Release this package as nifi-nar-maven-plugin-1.4.0
>
> [ ] +0 no opinion
>
> [ ] -1 Do not release this package because ...
>
>
>

Apache NiFi NAR Maven Plugin 1.4.0 RC1 Release Helper Guide

[Kevin Doran]

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/dev/nifi/KEYS

# Import keys file:
gpg --import KEYS

# [optional] Clear out local maven artifact repository

# Pull down nifi-nar-maven-plugin-1.4.0 source release artifacts for review:

wget 
https://repository.apache.org/content/repositories/orgapachenifi-1219/org/apache/nifi/nifi-nar-maven-plugin/1.4.0/nifi-nar-maven-plugin-1.4.0-source-release.zip
wget 
https://repository.apache.org/content/repositories/orgapachenifi-1219/org/apache/nifi/nifi-nar-maven-plugin/1.4.0/nifi-nar-maven-plugin-1.4.0-source-release.zip.asc
wget 
https://repository.apache.org/content/repositories/orgapachenifi-1219/org/apache/nifi/nifi-nar-maven-plugin/1.4.0/nifi-nar-maven-plugin-1.4.0-source-release.zip.sha512

# Verify the signature
gpg --verify -v nifi-nar-maven-plugin-1.4.0-source-release.zip.asc

# Verify the hash (sha512) matches the source and what was provided in
the vote email thread
shasum -a 512 nifi-nar-maven-plugin-1.4.0-source-release.zip

# Unzip nifi-nar-maven-plugin-1.4.0-source-release.zip
unzip nifi-nar-maven-plugin-1.4.0-source-release.zip

# Verify the build works including release audit tool (RAT) checks
cd nifi-nar-maven-plugin-1.4.0
mvn clean install -Pcontrib-check

# Verify the contents contain a good README, NOTICE, and LICENSE.
# Verify the git commit ID is correct
# Verify the RC was branched off the correct git commit ID

# Verify that NiFi can build NARs correctly using the plugin

- Update NiFi's root pom to use version 1.4.0 of the
pluginhttps://github.com/apache/nifi/blob/main/pom.xml#L102

- Perform a build of NiFi, optionally clear out local .m2 repo
mvn clean install

- Ensure that NiFi starts and loads all processors, controller
services, and reporting tasks

- Spot check a few NARs to ensure they include
META-INF/docs/extension-manifest.xml
cp NIFI_HOME/lib/nifi-xyz-bundle.nar /tmp
cd /tmp
unzip nifi-xyz-bundle.nar
cat META-INF/docs/extension-manifest.xml

# Send a response to the vote thread indicating a +1, 0, -1 based on
your findings.

Thank you for your time and effort to validate the release!

[VOTE] Release Apache NiFi NAR Maven Plugin 1.4.0

[Kevin Doran]

Hello Apache NiFi Community,

I am pleased to be calling this vote for the source release of Apache
NiFi NAR Maven Plugin 1.4.0.

The source being voted upon, including signatures, digests, etc. can
be found at:
https://repository.apache.org/content/repositories/orgapachenifi-1219/org/apache/nifi/nifi-nar-maven-plugin/1.4.0/

The Git tag is nifi-nar-maven-plugin-1.4.0-RC1
The Git commit ID is 09d7bb9ff679d0eed9feaa066d2cbdd347a20204
https://gitbox.apache.org/repos/asf?p=nifi-maven.git;a=commit;h=09d7bb9ff679d0eed9feaa066d2cbdd347a20204

Checksum of nifi-nar-maven-plugin-1.4.0-source-release.zip

SHA512: 
d48bfde8a5bab8a17b320889297c09efa162a7017db2268e274db626926ff9b58173abab54db4e1a50b5664fc86a9501ce2ef267b3e3b768eb80ef5c929860c9

Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/kdoran.asc

KEYS file available here:
https://dist.apache.org/repos/dist/release/nifi/KEYS

6 issues were closed/resolved for this release:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12352124

Release note highlights can be found here:
https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-NiFiNARMavenPluginVersion1.4.0

The vote will be open for 72 hours. Please download the release
candidate and evaluate the necessary items including checking hashes,
signatures, build from source, and test. Then please vote:

[ ] +1 Release this package as nifi-nar-maven-plugin-1.4.0
[ ] +0 no opinion
[ ] -1 Do not release this package because ...

Re: Reference parameters within execute script processor?

[Kevin Doran]

 Hi Carson,

Yes, it is possible. You want to add dynamic (user-defined) properties in
the processor config that reference your parameters.

For ExecuteScript [1] these will be passed to your python script as
variables with the same name.
For ExecuteStreamCommand [2] these will be passed to your python script as
environment variables with the same name.

Apache NiFi recently added the ability to reference Sensitive Parameters
from dynamic properties, so even those can be passed to scripts using this
method.

[1]
https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-scripting-nar/1.19.1/org.apache.nifi.processors.script.ExecuteScript/additionalDetails.html

[2]
https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-standard-nar/1.19.1/org.apache.nifi.processors.standard.ExecuteStreamCommand/index.html


Hope this helps!

Kevin


On Jan 27, 2023 at 08:46:57, Carson Goff  wrote:

> Hello,
>
> I have been doing some research lately and have not been able to find
> anything regarding this. I would like to be able to reference some of my
> parameters within an execute script processor running a python script, is
> this currently possible within nifi? If not, is it a planned feature?
>
> Thanks,
>
> Carson Goff
> Octo | Data Engineer
> M: 410-991-1870
>
>

Re: [DISCUSS] Release NiFi NAR Maven Plugin 1.4.0

[Kevin Doran]

 Thanks all. Will kickoff the RC soon.

Kevin

On Jan 26, 2023 at 10:22:23, Harry Clarke  wrote:

> It seems I'm unable to reproduce at the moment anyway (annoyingly working
> even with the same versions as before!)
>
> I'm happy to drop this, and continue this in Slack/Jira if I'm able to get
> any results.
>
> On the plus side, my team may be able to move to Java 17 now!
> 
> From: Joe Witt 
> Sent: 26 January 2023 15:11
> To: dev@nifi.apache.org 
> Subject: Re: [DISCUSS] Release NiFi NAR Maven Plugin 1.4.0
>
> Bryan - agreed.  Those are maven specific issues/settings.  I dont think it
> has any relationship to this thread in terms of a nar maven plugin release.
>
> Thanks
>
> On Thu, Jan 26, 2023 at 8:10 AM Bryan Bende  wrote:
>
> Thanks Kevin.
>
>
> Just to clarify, the Maven issues mentioned here don't sound specific
>
> to the NAR plugin, but sound like general Maven issues? or am I
>
> mis-interpreting?
>
>
> On Wed, Jan 25, 2023 at 6:56 PM Joe Witt  wrote:
>
> >
>
> > Thanks Kevin.  Sounds good.
>
> >
>
> > If you can start that soon I can draft 1.20 off that..
>
> >
>
> > thanks
>
> >
>
> > On Wed, Jan 25, 2023 at 4:46 PM Kevin Doran  wrote:
>
> >
>
> > >  Hi Harry,
>
> > >
>
> > > Thanks for the heads up. If you can share those findings, there's a
>
> few of
>
> > > us on this list that could help look into them and see if NiFi can do
>
> > > anything to work around potential Maven issues.
>
> > >
>
> > > Cheers,
>
> > > Kevin
>
> > >
>
> > > On Jan 25, 2023 at 18:42:07, Harry Clarke 
>
> > > wrote:
>
> > >
>
> > > > I'm not sure how to view what's been worked on since the last
>
> release,
>
> > > but
>
> > > > my team did notice an issue with 3.8.1 of Maven that isn't present in
>
> > > 3.6.1.
>
> > > >
>
> > > > It's hard to nail down exactly what's going on, but it looked to be
>
> that
>
> > > > plugin repository proxy settings weren't being honoured by Maven
>
> within
>
> > > the
>
> > > > settings.xml files, and pom.xml repo declarations were taking
>
> precedence.
>
> > > > Of course, this fails immediately if you're behind a firewall.
>
> > > >
>
> > > > I'll try to dig up where we got to with our investigation, but this
>
> was a
>
> > > > blocker for us moving to Java 17.
>
> > > > ____
>
> > > > From: Kevin Doran 
>
> > > > Sent: 25 January 2023 23:34
>
> > > > To: dev@nifi.apache.org 
>
> > > > Subject: Re: [DISCUSS] Release NiFi NAR Maven Plugin 1.4.0
>
> > > >
>
> > > > Hi all,
>
> > > >
>
> > > > The issues raised on this thread have all been addressed, so I’d
>
> like to
>
> > > > revive this goal to release NiFi NAR Maven Plugin 1.4.0 soon.
>
> > > >
>
> > > > Unless anyone is aware of additional items to include, I plan to
>
> start
>
> > > > preparing a release candidate this week.
>
> > > >
>
> > > > Thanks,
>
> > > > Kevin
>
> > > >
>
> > > > On Nov 30, 2022 at 14:28:00, Kevin Doran  wrote:
>
> > > >
>
> > > > Thanks, Bryan! There is no urgency around this release, so I'm happy
>
> to
>
> > > >
>
> > > > wait for that.
>
> > > >
>
> > > >
>
> > > > On Nov 30, 2022 at 14:24:02, Bryan Bende  wrote:
>
> > > >
>
> > > >
>
> > > > > Thanks Kevin!
>
> > > >
>
> > > > >
>
> > > >
>
> > > > > There is actually one change I was planning to start working on,
>
> and
>
> > > >
>
> > > > > since we don't release the NAR plugin very frequently, I would
>
> like to
>
> > > >
>
> > > > > try and get it in before this release.
>
> > > >
>
> > > > >
>
> > > >
>
> > > > > I created this JIRA [1] for the issue, and I can report back here
>
> once
>
> > > >
>
> > > > > I start working on it to see if it looks like it will still be
&

Re: [DISCUSS] Release NiFi NAR Maven Plugin 1.4.0

[Kevin Doran]

 Hi Harry,

Thanks for the heads up. If you can share those findings, there's a few of
us on this list that could help look into them and see if NiFi can do
anything to work around potential Maven issues.

Cheers,
Kevin

On Jan 25, 2023 at 18:42:07, Harry Clarke  wrote:

> I'm not sure how to view what's been worked on since the last release, but
> my team did notice an issue with 3.8.1 of Maven that isn't present in 3.6.1.
>
> It's hard to nail down exactly what's going on, but it looked to be that
> plugin repository proxy settings weren't being honoured by Maven within the
> settings.xml files, and pom.xml repo declarations were taking precedence.
> Of course, this fails immediately if you're behind a firewall.
>
> I'll try to dig up where we got to with our investigation, but this was a
> blocker for us moving to Java 17.
> 
> From: Kevin Doran 
> Sent: 25 January 2023 23:34
> To: dev@nifi.apache.org 
> Subject: Re: [DISCUSS] Release NiFi NAR Maven Plugin 1.4.0
>
> Hi all,
>
> The issues raised on this thread have all been addressed, so I’d like to
> revive this goal to release NiFi NAR Maven Plugin 1.4.0 soon.
>
> Unless anyone is aware of additional items to include, I plan to start
> preparing a release candidate this week.
>
> Thanks,
> Kevin
>
> On Nov 30, 2022 at 14:28:00, Kevin Doran  wrote:
>
> Thanks, Bryan! There is no urgency around this release, so I'm happy to
>
> wait for that.
>
>
> On Nov 30, 2022 at 14:24:02, Bryan Bende  wrote:
>
>
> > Thanks Kevin!
>
> >
>
> > There is actually one change I was planning to start working on, and
>
> > since we don't release the NAR plugin very frequently, I would like to
>
> > try and get it in before this release.
>
> >
>
> > I created this JIRA [1] for the issue, and I can report back here once
>
> > I start working on it to see if it looks like it will still be
>
> > something to wait on.
>
> >
>
> > [1] https://issues.apache.org/jira/browse/NIFI-10915
>
> >
>
> >
>
> > On Wed, Nov 30, 2022 at 9:43 AM David Handermann
>
> >  wrote:
>
> >
>
> >
>
> > Mark,
>
> >
>
> >
>
> > The dependency duplication detection is a new optional goal of the NAR
>
> >
>
> > plugin. The basic purpose is to detect unnecessary dependencies in the
>
> >
>
> > compile scope, which are already provided from a parent NAR dependency.
>
> >
>
> >
>
> > For example, the nifi-standard-service-api-nar includes the
>
> >
>
> > nifi-ssl-context-service-api library. The
> nifi-web-client-provider-service
>
> >
>
> > depends on nifi-ssl-context-service-api, and identifies it correctly with
>
> >
>
> > the provided scope in the Maven configuration. The
>
> >
>
> > nifi-web-client-provider-service-nar bundles
>
> >
>
> > nifi-web-client-provider-service, and depends on
>
> >
>
> > nifi-standard-service-api-nar. If the nifi-ssl-context-service-api was
> not
>
> >
>
> > marked as provided, the new duplication detection goal would flag the
>
> >
>
> > unnecessary inclusion of the nifi-ssl-context-service-api.
>
> >
>
> >
>
> > The duplication detection will help avoid including unnecessary
>
> >
>
> > dependencies, and also avoid unexpected runtime behavior. The NiFi NAR
>
> >
>
> > class loading hierarchy uses libraries from the parent NAR at runtime, so
>
> >
>
> > avoiding unnecessary dependency inclusion is important for these reasons.
>
> >
>
> > The goal is optional, and will require additional changes to enable by
>
> >
>
> > default in NiFi builds, but it should be very helpful for future
> releases.
>
> >
>
> >
>
> > Regards,
>
> >
>
> > David Handermann
>
> >
>
> >
>
> > On Wed, Nov 30, 2022 at 7:36 AM Mark Bean  wrote:
>
> >
>
> >
>
> > > Sounds great Kevin. Thanks!
>
> >
>
> > >
>
> >
>
> > > Can you give a little more detail on the dependency duplication
>
> > detection?
>
> >
>
> > > How does it work? Does it detect different versions of the same
>
> > dependency?
>
> >
>
> > > Is it detecting duplicates only within a given NAR or across multiple
>
> > NARs?
>
> >
>
> > >
>
> >
>
> > > Thanks,
>
> 

Re: [DISCUSS] Release NiFi NAR Maven Plugin 1.4.0

[Kevin Doran]

 Hi all,

The issues raised on this thread have all been addressed, so I’d like to
revive this goal to release NiFi NAR Maven Plugin 1.4.0 soon.

Unless anyone is aware of additional items to include, I plan to start
preparing a release candidate this week.

Thanks,
Kevin

On Nov 30, 2022 at 14:28:00, Kevin Doran  wrote:

> Thanks, Bryan! There is no urgency around this release, so I'm happy to
> wait for that.
>
> On Nov 30, 2022 at 14:24:02, Bryan Bende  wrote:
>
>> Thanks Kevin!
>>
>> There is actually one change I was planning to start working on, and
>> since we don't release the NAR plugin very frequently, I would like to
>> try and get it in before this release.
>>
>> I created this JIRA [1] for the issue, and I can report back here once
>> I start working on it to see if it looks like it will still be
>> something to wait on.
>>
>> [1] https://issues.apache.org/jira/browse/NIFI-10915
>>
>>
>> On Wed, Nov 30, 2022 at 9:43 AM David Handermann
>>  wrote:
>>
>>
>> Mark,
>>
>>
>> The dependency duplication detection is a new optional goal of the NAR
>>
>> plugin. The basic purpose is to detect unnecessary dependencies in the
>>
>> compile scope, which are already provided from a parent NAR dependency.
>>
>>
>> For example, the nifi-standard-service-api-nar includes the
>>
>> nifi-ssl-context-service-api library. The nifi-web-client-provider-service
>>
>> depends on nifi-ssl-context-service-api, and identifies it correctly with
>>
>> the provided scope in the Maven configuration. The
>>
>> nifi-web-client-provider-service-nar bundles
>>
>> nifi-web-client-provider-service, and depends on
>>
>> nifi-standard-service-api-nar. If the nifi-ssl-context-service-api was not
>>
>> marked as provided, the new duplication detection goal would flag the
>>
>> unnecessary inclusion of the nifi-ssl-context-service-api.
>>
>>
>> The duplication detection will help avoid including unnecessary
>>
>> dependencies, and also avoid unexpected runtime behavior. The NiFi NAR
>>
>> class loading hierarchy uses libraries from the parent NAR at runtime, so
>>
>> avoiding unnecessary dependency inclusion is important for these reasons.
>>
>> The goal is optional, and will require additional changes to enable by
>>
>> default in NiFi builds, but it should be very helpful for future releases.
>>
>>
>> Regards,
>>
>> David Handermann
>>
>>
>> On Wed, Nov 30, 2022 at 7:36 AM Mark Bean  wrote:
>>
>>
>> > Sounds great Kevin. Thanks!
>>
>> >
>>
>> > Can you give a little more detail on the dependency duplication
>> detection?
>>
>> > How does it work? Does it detect different versions of the same
>> dependency?
>>
>> > Is it detecting duplicates only within a given NAR or across multiple
>> NARs?
>>
>> >
>>
>> > Thanks,
>>
>> > Mark
>>
>> >
>>
>> >
>>
>> > On Tue, Nov 29, 2022 at 4:18 PM Kevin Doran  wrote:
>>
>> >
>>
>> > > Hi all,
>>
>> > >
>>
>> > > There’s been a few improvements and bug fixes to the NAR Maven Plugin.
>>
>> > One
>>
>> > > nice new feature is a new maven goal that detects duplicate
>> dependencies
>>
>> > in
>>
>> > > NARs. Another contribution improves our NiFi build reproducibility.
>>
>> > >
>>
>> > > Given all this, I’d like to release a new version of the plugin that
>> we
>>
>> > can
>>
>> > > start using in NiFi. As this includes a feature, this will be a minor
>>
>> > > version bump (1.4.0).
>>
>> > >
>>
>> > > I’m happy to RM. There are two outstanding PRs, and if there are no
>>
>> > > objections on this thread, I’ll wait for those to be merged and then
>>
>> > > prepare a release candidate.
>>
>> > >
>>
>> > > Thanks,
>>
>> > > Kevin
>>
>> > >
>>
>> >
>>
>>

Re: Access To Apache Jira

[Kevin Doran]

 Hi Harry,

The ASF JIRA account harryclarke has been created and added to the NIFI
project. Welcome!

Regards,
Kevin

On Jan 18, 2023 at 06:23:12, "Clarke, Harry"  wrote:

> Hi there!
>
> Please can I have an ASF Jira account for creating and contributing to
> issues on NiFi (https://infra.apache.org/jira-guidelines.html#who)?
> I should be registered as an ASF contributor under the ID  “harryclarke”
>
> Harry Clarke
> Pronouns:<
> https://www.goldmansachs.com/careers/blog/posts/bring-your-authentic-self-to-work-pronouns.html>
> He / Him / His
> VP  – Controls Engineering - PRE
>
>
> 
>
> © Copyright 2023 Goldman Sachs. All rights reserved. See
> http://www.gs.com/disclaimer/email-salesandtrading.html for risk
> disclosure, order handling practices, conflicts of interest and other terms
> and conditions relating to this e-mail and your reliance on it, and
> http://www.gs.com/disclaimer/ipo/ for recent prospectuses for initial
> public offerings to which this message may relate. See
> http://www.gs.com/swaps-related-disclosures for important disclosures
> relating to swap transactions, and
> http://www.goldmansachs.com/terms-of-dealing for general terms of
> dealing. For information on the nature and risks of investments for MiFID
> Professional Clients, see
> http://www.goldmansachs.com/disclosures/mifid/info-on-nature-risks-of-investments.pdf
> See http://www.goldmansachs.com/disclosures/mifid<
> http://www.goldmansachs.com/disclosures/mifid/> for important disclosures
> and GS policies in relation to MiFID II and MiFIR. This e-mail may contain
> confidential or privileged information. If you are not the intended
> recipient, please advise us immediately and delete it. See
> http://www.gs.com/disclaimer/email/ on confidentiality and the risks of
> electronic communication. If you cannot access these links, please notify
> us by reply message and we will send the contents to you. This material is
> a solicitation of derivatives business generally, only for the purposes of,
> and to the extent it would otherwise be subject to, CFTC Regulations 1.71
> and 23.605.
>
> 
>
> Your Personal Data: We may collect and process information about you that
> may be subject to data protection laws. For more information about how we
> use and disclose your personal data, how we protect your information, our
> legal basis to use your information, your rights and who you can contact,
> please refer to: www.gs.com/privacy-notices<
> http://www.gs.com/privacy-notices>
>

Re: [discuss] NiFi 1.20 and NiFi 2.0

[Kevin Doran]

I agree main needs to target 2.x, that is where most effort should be focused, 
and development there can be cherry picked / backported to a 1.x branch. The 
inverse approach creates too much of a moving target for 2.x.

Joe, I do not see anything else needed for cutting 1.20.

From: Joe Witt 
Sent: Wednesday, January 11, 2023 7:05:59 PM
To: dev@nifi.apache.org 
Subject: Re: [discuss] NiFi 1.20 and NiFi 2.0

Hello

We dont have a release schedule and never really have.  What we do have is
7+ years of track record which shows who and what we do.  We have done a
major release change before.  We release every couple of months or so.
This is very manageable and the stated goals are scoped as such.

We have declared what our goals are for 2.0 and now it is time to simply
make it happen.  We will keep 1.x moving along in the meantime but one of
these is going to get the ‘most’ energy as that is ultimately how all this
works.

Whatever is our ‘main’ line is where all PRs go by default and where people
work by default.  The burden of maintaining these lines is very real and
will provide plenty of motivation to move 2.0 along rapidly. The true
notion of business as usual is where PRs land and who does the work to
review and merge them.

The commentary around production usage worries suggests ideas or views that
differ from the discussed, documented and now voted upon release goals.
Someone starting on 2.0 should enjoy stability similar to a NiFi 1.20
release. Existing users will be provided tooling/automation/docs to move
from 1.x to 2.x.

Milestones may serve as a valuable tool
for us.  We can use them as we vet out migration tooling we put on the 1.x
line.

Do we need anything else for 1.20?

Thanks

On Wed, Jan 11, 2023 at 3:42 PM Adam Taft  wrote:

> This is really insightful and spot on ...
>
> Kevin wrote:
> > Good migration tooling will take a while to develop and test, and the
> core
> > contributors to that effort may not have sufficient variety of flows to
> > evaluate when the migration tools are "done" for the majority of the
> > community to have success upgrading to 2.x. A milestone release would
> allow
> > us get more feedback on migration over a longer period than the vote
> window
> > of an RC candidate.
>
> It's exactly this case, that an early 2.0 release might not have had time
> to fully work its way through existing production deployments, that's
> concerning. The pace and voting of an "RC" is much too short to get any
> quality feedback from users in the field.
>
> I think it's really smart to consider the "Milestone" release approach
> here. We release 2.0.0-M1, 2.0.0-M2, ... waiting an adequate amount of time
> for feedback. We can put these milestones on a calendar, as needed, so that
> feedback is required some 'x' number of weeks/months after each milestone.
>
> And to this end, I'd personally rather see us keep the 'main' branch
> current with the 1.x line _until_ we're ready and are satisfied with the
> end goals of the 2.0 release objectives. When the milestone releases have
> been completed and there's a comfort level with the 2.x line, it's at the
> point we'd isolate the 1.x line into its own branch and switch main over to
> the 2.x line.
>
> This is an attractive way of:
> a) continuing business-as-usual with the 1.x line
> b) making headway on the 2.x release milestones
> c) giving adequate time for feedback against the 2.0 milestones coming from
> the field
>
> I don't mind the known-unknowns. But it's really the unknown-unknowns that
> are going to drive a delay in the 2.0 release. I think it's smart to be
> able to get some of the unknowns ironed out before we finalize the 2.0
> release ceremony. The milestone approach really helps with that.
>
> /Adam
>
> On Wed, Jan 11, 2023 at 11:11 AM Kevin Doran  wrote:
>
> > Sorry, Joe, I was not clear, and to be honest the two thoughts are
> somewhat
> > unrelated in my mind too :)
> >
> > I agree that good migration tooling is key. Otherwise, we risk users
> > staying on 1.x or creating a schism of 1.x and 2.x users.
> >
> > Good migration tooling will take a while to develop and test, and the
> core
> > contributors to that effort may not have sufficient variety of flows to
> > evaluate when the migration tools are "done" for the majority of the
> > community to have success upgrading to 2.x. A milestone release would
> allow
> > us get more feedback on migration over a longer period than the vote
> window
> > of an RC candidate.
> >
> > Perhaps we could continue to release from the 1.x line (including minor
> > releases with some feature

Re: [discuss] NiFi 1.20 and NiFi 2.0

[Kevin Doran]

Sorry, Joe, I was not clear, and to be honest the two thoughts are somewhat
unrelated in my mind too :)

I agree that good migration tooling is key. Otherwise, we risk users
staying on 1.x or creating a schism of 1.x and 2.x users.

Good migration tooling will take a while to develop and test, and the core
contributors to that effort may not have sufficient variety of flows to
evaluate when the migration tools are "done" for the majority of the
community to have success upgrading to 2.x. A milestone release would allow
us get more feedback on migration over a longer period than the vote window
of an RC candidate.

Perhaps we could continue to release from the 1.x line (including minor
releases with some features) until we are ready to drop the "milestone"
qualifier from 2.0.0, and only then put 1.x into maintenance-only status.
It would be the same proposal to move main to target 2.0.0-M1, but relax
restrictions for what can land on the 1.x branch and be open to a 1.21,
1.22, etc. if 2.0.0 work takes longer than anticipated. For example, maybe
we would be open to landing new/backported processors on the 1.x branch,
but not core framework features or API changes.

This might not be necessary, but I think it is fair that saying "no new
features on 1.x" and also "no new features in 2.0.0" puts the project in a
rough place if 2.0.0 takes longer than a few months, so if we go that
route, we need to commit to a quick release of 2.0.0 that most users can
move to easily.

Thanks,
Kevin

On Jan 11, 2023 at 12:32:46, Joe Witt  wrote:

> Kevin,
>
> Yeah we can do whatever we want as far as 'releases' of 2.0 that are prior
> to us officially considering it 2.0/stable.
>
> That said - the migration tooling will be key to provide as we need to make
> the bridge as solid and stable as possible to help someone move from 1.x to
> 2.x.  I dont know how related these two concepts (milestone releases and
> 1.x to 2.x ease really are).
>
> Thanks
>
> On Wed, Jan 11, 2023 at 10:27 AM Kevin Doran  wrote:
>
>  [hit the wrong keyboard shortcut, here is the rest of my thoughts]
>
>
> On this point from David:
>
>
> We may need to have a longer release candidate period, or more incremental
>
> > fix releases
>
> > for the initial 2.0.0 release train, but I do not expect delaying a 2.0.0
>
> > release for new features, as that is not part of the release goals.
>
> >
>
>
> Would the community benefit from one or more milestone releases of 2.0, to
>
> allow for a wider group to run / live on the proposed 2.0 prior to
>
> releasing it as "stable"? I know we've never done a milestone release in
>
> the past, and I'm not sure what ASF guidance is on the topic, but if it
>
> could be beneficial we could look into that.
>
>
> Cheers,
>
> Kevin
>
>
> On Jan 11, 2023 at 12:22:43, Kevin Doran  wrote:
>
>
> > I think this is a good, practical discussion.
>
> >
>
> > On the one hand, we can't put off 2.x any longer as we really need to
>
> > updated the minimum required Java to 11. Updating main development to
>
> > target 2.x feels like a good way drive progress on that along with the
>
> > other 2.0 goals.
>
> >
>
> > On the other hand, the concerns are valid: moving all development to
>
> > target 2.x puts the project at risk if we cannot release 2.0.0 on a
>
> > reasonable timeline. The restricted scope of 2.0 helps, but this stated
>
> > release goal feels risky to me:
>
> >
>
> > Implement Migration Tools for Upgrading Flows
>
> >
>
> >
>
> >- Implement automated migration where possible to remap properties and
>
> >   features
>
> >   - Implement migration tools for manual conversion of XML Templates
>
> >   to JSON Flow Definitions
>
> >   - Create documentation for manual steps necessary where
>
> >   programmatic migration cannot be implemented
>
> >   - NiFi 2.0 should be capable of starting with ghosted components
>
> >   for removed Processors or Controller Services
>
> >
>
> >
>
> > Removing deprecated components should be fairly straightforward and
>
> quick,
>
> > but automating and documenting migration is a large effort.
>
> >
>
> > On this po
>
> >
>
> >
>
> > On Jan 10, 2023 at 09:32:31, Bryan Bende  wrote:
>
> >
>
> >> The plan as I understand it is not to diverge and create separate
>
> feature
>
> >> development on the 1.x line, so I would expect all PRs to continue to be
>
> >> submitted only to main. We would release 1

Re: [discuss] NiFi 1.20 and NiFi 2.0

[Kevin Doran]

 [hit the wrong keyboard shortcut, here is the rest of my thoughts]

On this point from David:

We may need to have a longer release candidate period, or more incremental
> fix releases
> for the initial 2.0.0 release train, but I do not expect delaying a 2.0.0
> release for new features, as that is not part of the release goals.
>

Would the community benefit from one or more milestone releases of 2.0, to
allow for a wider group to run / live on the proposed 2.0 prior to
releasing it as "stable"? I know we've never done a milestone release in
the past, and I'm not sure what ASF guidance is on the topic, but if it
could be beneficial we could look into that.

Cheers,
Kevin

On Jan 11, 2023 at 12:22:43, Kevin Doran  wrote:

> I think this is a good, practical discussion.
>
> On the one hand, we can't put off 2.x any longer as we really need to
> updated the minimum required Java to 11. Updating main development to
> target 2.x feels like a good way drive progress on that along with the
> other 2.0 goals.
>
> On the other hand, the concerns are valid: moving all development to
> target 2.x puts the project at risk if we cannot release 2.0.0 on a
> reasonable timeline. The restricted scope of 2.0 helps, but this stated
> release goal feels risky to me:
>
> Implement Migration Tools for Upgrading Flows
>
>
>- Implement automated migration where possible to remap properties and
>   features
>   - Implement migration tools for manual conversion of XML Templates
>   to JSON Flow Definitions
>   - Create documentation for manual steps necessary where
>   programmatic migration cannot be implemented
>   - NiFi 2.0 should be capable of starting with ghosted components
>   for removed Processors or Controller Services
>
>
> Removing deprecated components should be fairly straightforward and quick,
> but automating and documenting migration is a large effort.
>
> On this po
>
>
> On Jan 10, 2023 at 09:32:31, Bryan Bende  wrote:
>
>> The plan as I understand it is not to diverge and create separate feature
>> development on the 1.x line, so I would expect all PRs to continue to be
>> submitted only to main. We would release 1.x as needed with major bug
>> fixes
>> or critical security updates, and these would be cherry-picked and/or
>> backported as necessary, mostly without the need for PRs, the same as we
>> would do if we were bringing fixes from main (1.20.0-SNAPSHOT) back to a
>> maintenance line like (1.19.x). For precedent, we followed this same
>> approach going from the 0.x line to 1.0.0 and there wasn't any major
>> issue.
>>
>> On Tue, Jan 10, 2023 at 7:07 AM Otto Fowler 
>> wrote:
>>
>>  It was also mentioned in another thread that we need to have agreement on
>>
>> our explicit strategy and support for 1.x going forward, did that happen?
>>
>>
>> From: Otto Fowler  
>>
>> Reply: Otto Fowler  
>>
>> Date: January 10, 2023 at 07:02:34
>>
>> To: dev@nifi.apache.org  
>>
>> Subject:  Re: [discuss] NiFi 1.20 and NiFi 2.0
>>
>>
>> There needs to be an update to the contributing guide as to how to submit
>>
>> PRs to 1.x or 2.x etc.
>>
>>
>> From: Joe Witt  
>>
>> Reply: dev@nifi.apache.org  
>>
>> Date: January 9, 2023 at 15:53:16
>>
>> To: dev@nifi.apache.org  
>>
>> Subject:  [discuss] NiFi 1.20 and NiFi 2.0
>>
>>
>> Team,
>>
>>
>> As David mentioned in [1] following a successful NiFi 2.0 release goal
>>
>> planning - we are now going to start moving the 'main' line to be the NiFi
>>
>> 2.0 line which will allow for the key work to take place. We will also
>>
>> move niFi 1.x to its appropriate support line.
>>
>>
>> It is also the case that we have nearly 100 JIRAs on NiFi 1.20 and we have
>>
>> work in there including security items so it is time to make a release.
>>
>> The intent then is to initiate 1.20 and immediate after that change 'main'
>>
>> to 2.0.
>>
>>
>> Going forward then all work on the 1.x line should be focused on
>>
>> maintaining existing features, dependencies, and helping 1.x users migrate
>>
>> to the 2.x line. Otherwise, new feature work will happen on 'main' as it
>>
>> normally does and will come out in the NiFi 2.x release line.
>>
>>
>> Please flag key outstanding items as we narrow down the release candidate
>>
>> for NiFi 1.20.
>>
>>
>> Thanks
>>
>> Joe
>>
>>
>> [1] https://lists.apache.org/thread/qo4vvdw46235y7vy2crcd6l4m11wl7jz
>>
>>
>>

Re: [discuss] NiFi 1.20 and NiFi 2.0

[Kevin Doran]

 I think this is a good, practical discussion.

On the one hand, we can't put off 2.x any longer as we really need to
updated the minimum required Java to 11. Updating main development to
target 2.x feels like a good way drive progress on that along with the
other 2.0 goals.

On the other hand, the concerns are valid: moving all development to target
2.x puts the project at risk if we cannot release 2.0.0 on a reasonable
timeline. The restricted scope of 2.0 helps, but this stated release goal
feels risky to me:

Implement Migration Tools for Upgrading Flows


   - Implement automated migration where possible to remap properties and
  features
  - Implement migration tools for manual conversion of XML Templates to
  JSON Flow Definitions
  - Create documentation for manual steps necessary where programmatic
  migration cannot be implemented
  - NiFi 2.0 should be capable of starting with ghosted components for
  removed Processors or Controller Services


Removing deprecated components should be fairly straightforward and quick,
but automating and documenting migration is a large effort.

On this po


On Jan 10, 2023 at 09:32:31, Bryan Bende  wrote:

> The plan as I understand it is not to diverge and create separate feature
> development on the 1.x line, so I would expect all PRs to continue to be
> submitted only to main. We would release 1.x as needed with major bug fixes
> or critical security updates, and these would be cherry-picked and/or
> backported as necessary, mostly without the need for PRs, the same as we
> would do if we were bringing fixes from main (1.20.0-SNAPSHOT) back to a
> maintenance line like (1.19.x). For precedent, we followed this same
> approach going from the 0.x line to 1.0.0 and there wasn't any major issue.
>
> On Tue, Jan 10, 2023 at 7:07 AM Otto Fowler 
> wrote:
>
>  It was also mentioned in another thread that we need to have agreement on
>
> our explicit strategy and support for 1.x going forward, did that happen?
>
>
> From: Otto Fowler  
>
> Reply: Otto Fowler  
>
> Date: January 10, 2023 at 07:02:34
>
> To: dev@nifi.apache.org  
>
> Subject:  Re: [discuss] NiFi 1.20 and NiFi 2.0
>
>
> There needs to be an update to the contributing guide as to how to submit
>
> PRs to 1.x or 2.x etc.
>
>
> From: Joe Witt  
>
> Reply: dev@nifi.apache.org  
>
> Date: January 9, 2023 at 15:53:16
>
> To: dev@nifi.apache.org  
>
> Subject:  [discuss] NiFi 1.20 and NiFi 2.0
>
>
> Team,
>
>
> As David mentioned in [1] following a successful NiFi 2.0 release goal
>
> planning - we are now going to start moving the 'main' line to be the NiFi
>
> 2.0 line which will allow for the key work to take place. We will also
>
> move niFi 1.x to its appropriate support line.
>
>
> It is also the case that we have nearly 100 JIRAs on NiFi 1.20 and we have
>
> work in there including security items so it is time to make a release.
>
> The intent then is to initiate 1.20 and immediate after that change 'main'
>
> to 2.0.
>
>
> Going forward then all work on the 1.x line should be focused on
>
> maintaining existing features, dependencies, and helping 1.x users migrate
>
> to the 2.x line. Otherwise, new feature work will happen on 'main' as it
>
> normally does and will come out in the NiFi 2.x release line.
>
>
> Please flag key outstanding items as we narrow down the release candidate
>
> for NiFi 1.20.
>
>
> Thanks
>
> Joe
>
>
> [1] https://lists.apache.org/thread/qo4vvdw46235y7vy2crcd6l4m11wl7jz
>
>
>

Re: [VOTE] Adopt NiFi 2.0 Proposed Release Goals

[Kevin Doran]

 +1 (binding)

On Dec 12, 2022 at 12:41:16, Matt Gilman  wrote:

> +1 (binding)
>
> On Mon, Dec 12, 2022 at 12:02 PM David Handermann <
> exceptionfact...@apache.org> wrote:
>
> Team,
>
>
> Following positive feedback on NiFi 2.0 Proposed Release Goals [1] on the
>
> recent discussion thread [2], I am calling this vote to adopt the following
>
> as Release Goals for NiFi 2.0:
>
>
> 1. Remove Java 8 support and require Java 11
>
> 2. Remove deprecated components
>
> 3. Remove deprecated component properties
>
> 4. Remove components integrating with unmaintained services
>
> 5. Remove compatibility classes and methods
>
> 6. Remove flow.xml.gz in favor of flow.json.gz
>
> 7. Remove duplicative features
>
> 8. Upgrade internal Java API references
>
> 9. Reorganize standard components
>
> 10. Implement migration tools for upgrading flows
>
>
> A positive vote indicates agreement on these goals and the initiation of
>
> the following actions:
>
>
> 1. Rename NiFi 2.0 Proposed Release Goals to NiFi 2.0 Release Goals
>
> 2. Create version 1 branch in Git for subsequent support releases on the
>
> version 1 series
>
> 3. Update the current main branch in Git to version 2.0.0-SNAPSHOT
>
>
> The vote will be open for 72 hours and follow standard procedures for
>
> release votes.
>
>
> Please review the linked goals and discussions for background.
>
>
> [ ] +1 Adopt NiFi 2.0 Release Goals
>
> [ ] +0 No opinion
>
> [ ] -1 Do not adopt NiFi 2.0 Release Goals for the following reasons...
>
>
> [1]
>
>
>
> https://cwiki.apache.org/confluence/display/NIFI/NiFi+2.0+Proposed+Release+Goals
>
> [2] https://lists.apache.org/thread/xo77p9t3xg4k70356xrqbdg4m9sg7sf8
>
>
>

Re: [DISCUSS] Finalizing Release Goals for NiFi 2.0

[Kevin Doran]

Thanks, David. The updated wiki page looks good and I’m very supportive of
the proposal

I support a narrower scope for 2.x and an eventual 3.x line sooner rather
than later. It takes some pressure off trying to fit everything into this
2.x change / migration

Kevin

On Dec 7, 2022 at 18:07:35, Ryan Hendrickson <
ryan.andrew.hendrick...@gmail.com> wrote:

> The Proposed Release Goals and Deprecated Components and Features pages
> look great.
>
> I appreciate the minor leap of Java 11 as a 2.x requirement vs Java 17.
>
> Maybe once there is a timeline, the 2.x branch could be scheduled only to
> be alive for a minor amount of time... a year, etc. Then a later 2.x or 3.0
> release would bring about Java 17.
>
> Ryan
>
> On Wed, Dec 7, 2022 at 3:09 PM Mike Thomsen 
> wrote:
>
> > Mike - what do you mean by "controller service-based configuration for
>
>
> Using controller services for configuring bundles that connect an
>
> external service such as Cassandra, Elasticsearch, etc. and removing
>
> the option to configure connections on the processor.
>
>
> > I don't think you were suggesting the minimum version be Java 17, were
>
> you?
>
>
> I was. Partly as devil's advocate, partly because I actually want to
>
> use Java 17 as a daily driver.
>
>
> On Wed, Dec 7, 2022 at 2:20 PM Mark Bean  wrote:
>
> >
>
> > I agree this is a great start to a discussion with pointers to important
>
> > docs for the 2.0 transition. Thanks David!
>
> >
>
> > Mike - what do you mean by "controller service-based configuration for
>
> > connection details"?
>
> >
>
> > Also, the transition from Java 11 to 17 is not without potential issues.
>
> > I've discovered one already. [1] I support stepping up on Java version
>
> > requirements. Perhaps rather than the currently stated "Requires Java 8
>
> or
>
> > Java 11", the requirement can be "Requires Java 11 or Java 17". I don't
>
> > think you were suggesting the minimum version be Java 17, were you?
>
> Either
>
> > way, the issue with Java 17 needs to be identified and fixed as well as
>
> > more thorough testing to find other possible edge cases before we move
>
> > forward too aggressively.
>
> >
>
> > [1] https://issues.apache.org/jira/browse/NIFI-10958
>
> >
>
> > On Wed, Dec 7, 2022 at 1:33 PM Mike Thomsen 
>
> wrote:
>
> >
>
> > > Really good start on the discussion. One thing I'm curious about is
>
> > > Java 11 vs 17. Java 8 -> 11 is major jump that I can understand why
>
> > > businesses scoffed at that for a long time, but the lift from 11 to 17
>
> > > was about like 7 -> 8. A 2.0 release seems like a good time to jump
>
> > > straight to the latest official LTS for Java and start greenlighting
>
> > > new language features that might simplify things.
>
> > >
>
> > > I would also add (since I didn't see it) a design goal of forcing a
>
> > > complete shift in all bundles to using controller service-based
>
> > > configurations for connection details. 2.0 feels like a really good
>
> > > time for us to establish a community-wide best practice of
>
> > > centralizing configurations in dedicated components.
>
> > >
>
> > > On Wed, Dec 7, 2022 at 9:13 AM Mark Payne 
>
> wrote:
>
> > > >
>
> > > > Yeah, agreed. I am very supportive, as well.
>
> > > >
>
> > > > Thanks for taking the time to put this together, David.
>
> > > >
>
> > > > -Mark
>
> > > >
>
> > > >
>
> > > > > On Dec 7, 2022, at 4:07 AM, Pierre Villard <
>
> > > pierre.villard...@gmail.com> wrote:
>
> > > > >
>
> > > > > Thanks for putting this together David. This is an excellent
>
> writeup
>
> > > and
>
> > > > > it's great to have a release where we focus on tech debt as well as
>
> > > making
>
> > > > > sure we stay up to date with our dependencies and what we support.
>
> > > This is
>
> > > > > a great opportunity for us to clean a lot of things in our code
>
> and I
>
> > > can't
>
> > > > > wait for us to get started with this. I'm definitely a +1 to have a
>
> > > formal
>
> > > > > vote on this proposal.
>
> > > > >
>
> > > > > Thanks,
>
> > > > > Pierre
>
> > > > >
>
> > > > > Le mar. 6 déc. 2022 à 23:50, Joe Witt  a
>
> écrit :
>
> > > > >
>
> > > > >> David, All,
>
> > > > >>
>
> > > > >> This is an excellent writeup/good framing.  I am supportive of
>
> this
>
> > > > >> as-is since it is achievable and lays out a clear path.  We can
>
> make
>
> > > > >> milestone releases of NiFi 2.0.0 along the way until we achieve
>
> all
>
> > > > >> the stated goals. I assume migration bits will be the long pole
>
> and
>
> > > > >> once we have them sorted we can kick out a 2.0.0.   We already
>
> have a
>
> > > > >> version guide that governs how long we'd keep 1.x maintained
>
> though
>
> > > > >> the phase out is pretty natural as we move main to a 2.0.0 basis
>
> > > > >> anyway.
>
> > > > >>
>
> > > > >> Not to confuse this thread but it makes me think we could do a
>
> similar
>
> > > > >> framing for a NiFi 3.0 which lays out a potentially new approach
>
> to
>
> > > > >> NiFi decoupling the web/in

Re: [DISCUSS] Release NiFi NAR Maven Plugin 1.4.0

[Kevin Doran]

 Thanks, Bryan! There is no urgency around this release, so I'm happy to
wait for that.

On Nov 30, 2022 at 14:24:02, Bryan Bende  wrote:

> Thanks Kevin!
>
> There is actually one change I was planning to start working on, and
> since we don't release the NAR plugin very frequently, I would like to
> try and get it in before this release.
>
> I created this JIRA [1] for the issue, and I can report back here once
> I start working on it to see if it looks like it will still be
> something to wait on.
>
> [1] https://issues.apache.org/jira/browse/NIFI-10915
>
>
> On Wed, Nov 30, 2022 at 9:43 AM David Handermann
>  wrote:
>
>
> Mark,
>
>
> The dependency duplication detection is a new optional goal of the NAR
>
> plugin. The basic purpose is to detect unnecessary dependencies in the
>
> compile scope, which are already provided from a parent NAR dependency.
>
>
> For example, the nifi-standard-service-api-nar includes the
>
> nifi-ssl-context-service-api library. The nifi-web-client-provider-service
>
> depends on nifi-ssl-context-service-api, and identifies it correctly with
>
> the provided scope in the Maven configuration. The
>
> nifi-web-client-provider-service-nar bundles
>
> nifi-web-client-provider-service, and depends on
>
> nifi-standard-service-api-nar. If the nifi-ssl-context-service-api was not
>
> marked as provided, the new duplication detection goal would flag the
>
> unnecessary inclusion of the nifi-ssl-context-service-api.
>
>
> The duplication detection will help avoid including unnecessary
>
> dependencies, and also avoid unexpected runtime behavior. The NiFi NAR
>
> class loading hierarchy uses libraries from the parent NAR at runtime, so
>
> avoiding unnecessary dependency inclusion is important for these reasons.
>
> The goal is optional, and will require additional changes to enable by
>
> default in NiFi builds, but it should be very helpful for future releases.
>
>
> Regards,
>
> David Handermann
>
>
> On Wed, Nov 30, 2022 at 7:36 AM Mark Bean  wrote:
>
>
> > Sounds great Kevin. Thanks!
>
> >
>
> > Can you give a little more detail on the dependency duplication
> detection?
>
> > How does it work? Does it detect different versions of the same
> dependency?
>
> > Is it detecting duplicates only within a given NAR or across multiple
> NARs?
>
> >
>
> > Thanks,
>
> > Mark
>
> >
>
> >
>
> > On Tue, Nov 29, 2022 at 4:18 PM Kevin Doran  wrote:
>
> >
>
> > > Hi all,
>
> > >
>
> > > There’s been a few improvements and bug fixes to the NAR Maven Plugin.
>
> > One
>
> > > nice new feature is a new maven goal that detects duplicate
> dependencies
>
> > in
>
> > > NARs. Another contribution improves our NiFi build reproducibility.
>
> > >
>
> > > Given all this, I’d like to release a new version of the plugin that we
>
> > can
>
> > > start using in NiFi. As this includes a feature, this will be a minor
>
> > > version bump (1.4.0).
>
> > >
>
> > > I’m happy to RM. There are two outstanding PRs, and if there are no
>
> > > objections on this thread, I’ll wait for those to be merged and then
>
> > > prepare a release candidate.
>
> > >
>
> > > Thanks,
>
> > > Kevin
>
> > >
>
> >
>
>

[DISCUSS] Release NiFi NAR Maven Plugin 1.4.0

[Kevin Doran]

Hi all,

There’s been a few improvements and bug fixes to the NAR Maven Plugin. One
nice new feature is a new maven goal that detects duplicate dependencies in
NARs. Another contribution improves our NiFi build reproducibility.

Given all this, I’d like to release a new version of the plugin that we can
start using in NiFi. As this includes a feature, this will be a minor
version bump (1.4.0).

I’m happy to RM. There are two outstanding PRs, and if there are no
objections on this thread, I’ll wait for those to be merged and then
prepare a release candidate.

Thanks,
Kevin

Re: [DISCUSS] MiNiFi C++ 0.13.0 release

[Kevin Doran]

 +1, seems like a great time for a new release

On Nov 28, 2022 at 05:14:59, Ferenc Gerlits  wrote:

> Hi community,
>
> I'd like to initiate a discussion about the next release of MiNiFi C++. The
> last release was almost six months ago, and there have been many new
> features,
> bug fixes and stability improvements committed to the development branch
> since then: 80 tickets closed, over 100 commits.
>
> I would be happy to take on RM duties for this release.
>
> New features since the 0.12.0 release:
>
> - New processors:
>  * ListenTCP
>  * PutTCP
>  * PostElasticSearch
>  * CollectKubernetesPodMetrics
> - Warn on SSL certificates about to expire
> - Fix cron-based scheduling
> - Improve metrics reporting and add support for Prometheus
> - Improve the performance of several processors (ListenHTTP, AWS, Azure,
> GCS)
> - Support swapping out flow files from memory to disk
> - Support low-memory use cases with FileSystemRepository
> - Improve the MQTT processors and add support for MQTT v5.0
> - Improve communication with C2, eg. add alert capability
> - Fix support of native packages in Python scripting
> - Fix Python scripting on Windows
> - Add SSL support to the ListenSyslog and ListenTCP processors
> - Fix the 32-bit build on Windows
> - Support POST/PUT of large files in InvokeHTTP
> - Plus upgrade libraries, fix issues reported by clang-tidy, fix memory
> leaks etc
>
> The core API is still not mature enough to be able to commit to it, so
> in line with previous discussions I suggest releasing it as 0.13.0.
>
> Do you agree it is time for a new release? Are there any blockers that we
> should definitely include in this release?
>
> Thanks,
> Ferenc
>

Re: [discuss] NiFi 1.19.0

[Kevin Doran]

 NIFI-10701 is merged. If folks are ok holding off a day or two more for
1.19, I'll look into following the work Ferenc Kis did for that to knock
out NIFI-10820.

On Nov 15, 2022 at 19:43:57, Matt Burgess  wrote:

> Awesome, thanks all! I'd like to wait for Github actions to be happy
> and then merge?
>
> On Tue, Nov 15, 2022 at 7:11 PM Mark Bean  wrote:
>
>
> NIFI-10703 has been worked through. I think it's good to go now.
>
>
> On Tue, Nov 15, 2022 at 4:43 PM Matt Burgess  wrote:
>
>
> > I can take that review too, if your suggestions are incorporated. I
>
> > started looking the other day but didn't get to dig in. I'll try to
>
> > reproduce in the meantime.
>
> >
>
> > Regards,
>
> > Matt
>
> >
>
> > On Tue, Nov 15, 2022 at 4:42 PM Nathan Gough 
> wrote:
>
> > >
>
> > > We might also want https://issues.apache.org/jira/browse/NIFI-10787
>
> > >
>
> > > On Tue, Nov 15, 2022 at 4:05 PM Mark Bean 
> wrote:
>
> > >
>
> > > > I will be on it in about 2 hours, if not addressed sooner.
>
> > > >
>
> > > > On Tue, Nov 15, 2022 at 3:46 PM Joe Witt  wrote:
>
> > > >
>
> > > > > NIFI-10703 would be great to get in.  Just a matter of gettin' it
>
> > done
>
> > > > and
>
> > > > > merged I think.  You're on it?
>
> > > > >
>
> > > > > Thanks
>
> > > > >
>
> > > > > On Tue, Nov 15, 2022 at 1:38 PM Mark Bean 
>
> > wrote:
>
> > > > >
>
> > > > > > Sorry.. check that. There's a typo in the latest commit on that
> PR.
>
> > > > > >
>
> > > > > > On Tue, Nov 15, 2022 at 3:35 PM Mark Bean  >
>
> > > > wrote:
>
> > > > > >
>
> > > > > > > Could we get NIFIDEVS-10703 (PR #6638) in there too? AFAIK,
> it's
>
> > good
>
> > > > > to
>
> > > > > > > go.
>
> > > > > > >
>
> > > > > > > Thanks,
>
> > > > > > > Mark
>
> > > > > > >
>
> > > > > > >
>
> > > > > > > On Tue, Nov 15, 2022 at 2:56 PM Joe Witt 
>
> > wrote:
>
> > > > > > >
>
> > > > > > >> Hello All,
>
> > > > > > >>
>
> > > > > > >> I plan to kick off the RC as soon as
>
> > > > > > >> https://issues.apache.org/jira/browse/NIFI-10701 is merged.
>
> > > > > > >>
>
> > > > > > >> Thanks
>
> > > > > > >>
>
> > > > > > >> On Thu, Nov 10, 2022 at 12:52 PM David Handermann <
>
> > > > > > >> exceptionfact...@apache.org> wrote:
>
> > > > > > >>
>
> > > > > > >> > Joe,
>
> > > > > > >> >
>
> > > > > > >> > Thanks for initiating the discussion. I agree with moving
>
> > toward a
>
> > > > > > >> 1.19.0
>
> > > > > > >> > release instead of 1.18.1 given over 150 Jira issues already
>
> > > > tagged
>
> > > > > > with
>
> > > > > > >> > 1.19.0.
>
> > > > > > >> >
>
> > > > > > >> > We should start another thread soon regarding 2.0. One of
> the
>
> > key
>
> > > > > > >> things to
>
> > > > > > >> > do before that, however, would be to finish adding
> deprecation
>
> > > > > logging
>
> > > > > > >> to
>
> > > > > > >> > remaining features we plan to remove in 2.0. Having a minor
>
> > > > release
>
> > > > > in
>
> > > > > > >> > version 1 series deprecating targets for removal should be a
>
> > > > > > >> prerequisite
>
> > > > > > >> > before branching and starting on 2.0.
>
> > > > > > >> >
>
> > > > > > >> > In the meantime, if that means we plan on a 1.20.0 release,
> I
>
> > am
>
> > > > in
>
> > > > > > >> favor
>
> > > > > > >> > of moving forward with 1.19.0.
>
> > > > > > >> >
>
> > > > > > >> > Regards,
>
> > > > > > >> > David Handermann
>
> > > > > > >> >
>
> > > > > > >> > On Thu, Nov 10, 2022 at 1:44 PM Joe Witt <
> joe.w...@gmail.com>
>
> > > > > wrote:
>
> > > > > > >> >
>
> > > > > > >> > > Team,
>
> > > > > > >> > >
>
> > > > > > >> > > We keep getting a slew of emails on various lists, slack,
>
> > and
>
> > > > the
>
> > > > > > >> > security
>
> > > > > > >> > > list about commons text.  We need a 1.18.1 or a 1.19.0.
>
> > > > > > >> > >
>
> > > > > > >> > > Given all that has already happened on 1.19.0 I'm inclined
>
> > to
>
> > > > just
>
> > > > > > 'do
>
> > > > > > >> > > that' release and get it going.
>
> > > > > > >> > >
>
> > > > > > >> > > I know we need to start getting serious about 2.0 but
>
> > perhaps
>
> > > > the
>
> > > > > > most
>
> > > > > > >> > > realistic path for that is we branch and come back to main
>
> > after
>
> > > > > we
>
> > > > > > >> get
>
> > > > > > >> > > that figured out.  But we need to keep moving forward in
> the
>
> > > > > > meantime.
>
> > > > > > >> > >
>
> > > > > > >> > > Please share if there is anything we know about on the
> main
>
> > line
>
> > > > > > which
>
> > > > > > >> > > would make doing a 1.19.0 problematic.
>
> > > > > > >> > >
>
> > > > > > >> > >
>
> > https://issues.apache.org/jira/projects/NIFI/versions/12352345
>
> > > > > > >> > >
>
> > > > > > >> > > Thanks
>
> > > > > > >> > >
>
> > > > > > >> >
>
> > > > > > >>
>
> > > > > > >
>
> > > > > >
>
> > > > >
>
> > > >
>
> >
>
>

Re: Latest NiFi-arm64 docker image

[Kevin Doran]

 Hi James,

NiFi arm64 images are not yet available, though there is some work in
progress to add arm64 platform support, so they might be made available as
part of the next regular NiFI release.

On Nov 3, 2022 at 02:22:06, James Li  wrote:

> Hi,
>
> Could you provide latest NiFi-arm64 docker image
>
> Best Regards.
> James
>

Re: proposal to extend several component key properties to use Expression Lng instead of VarRegs only (based off https://issues.apache.org/jira/browse/NIFI-8214)

[Kevin Doran]

Hi Rogier,

Thanks for your message. This is an interesting use case. In a way it
inverts the typical use of NiFi, which is where the flow files are the data
being moved and the flow logic is in the flow definition / processor
config. Instead this puts the parameters of the job/workflow into the
flowfile, which presumably gets enhanced as it moves through the flow so
you end up with one object/document containing your workflow parameters and
data/results. Is that accurate?

I understand correctly, this sounds like a workflow orchestration problem,
which is similar to but has some subtle differences from data flow
management. There are tools that try to solve workflow orchestration. Two
that come to mind are Conductor [1] and Cadence [2]. NiFi can do this, and
I see plenty of flows that use flowfile attributes to store some control
signals or values needed for flow logic. But because its not the core use
case, I think NiFi developers / extension authors don't think of it when
building components, which is why they don't think of enabling expression
language on certain properties.

This isn't really a response to whether NiFi should / should not add
broader expression language support to properties nor is it an opinion on
wheterh NiFi should or should not try to serve the needs of workflow
orchestration / job execution. Others on this list may have opinions on
that. I'm just offering my perspective on why this isn't already the case.
AFAIK, in many cases adding EL support to processor properties is a fairly
straightforward effort; the challenge, as you point out, is applying it
broadly to all our existing processors (and new processors as they get
developed) rather than just one or two.

[1] https://conductor.netflix.com/
[2] https://cadenceworkflow.io/

Cheers,
Kevin

On Oct 18, 2022 at 06:05:14, TIMMERMANS Rogier <
rogier.timmerm...@contractor.voo.be> wrote:

> Hello,
>
>
>
> Apologies in advance if this is the wrong list to send this type of query
> to.
>
> After short discussion with Chris Sampson on
> https://issues.apache.org/jira/browse/NIFI-8214 he proposed to send out
> email to this list; I hope it finds you well.
>
>
>
> We (several of my colleagues) sometimes use a pattern where we build a
> nifi flow that gets initiated by a short json configuration file; the
> initial input file (or generated flowfile) contains simple configuration
> data for the rest of the flow and sets up things like Remote paths, users,
> testcase IDs, endpoints to hit, etc… as a file is easier to manage,
> maintain and archive than a graphical set of linked components with logic.
>
> This setup allows relative easy building of a generalized graphical logic
> flow with (less issue below) minimal branching as ‘controlling where stuff
> goes or talks to’ is effectively on the input file.
> With some processing and splitting upfront each flowfile will effectively
> go down it’s intended path and carry the needed values as attributes for
> downstream usage where they act as dynamic configuration/parameters (or
> whatever terminology you wish to apply) and we are also able to use
> calculations/logic to pick output locations, etc. To make it more concrete
> just imagine a use case where a simple attribute value can decide using a
> production system or a test system endpoint where all logic is identical
> but the only difference will be an input and/or output location. Granted
> the example is simple but it does demonstrate how this can get out of hand
> with multiple branching locations and duplicated components.
>
> We do face the issue that several NiFi components do not support
> Attributes (or expression language) on several key configuration properties
> (some typical example components with this limitation: FTP components,
> ElasticPut, and there surely will be a few others based off the similar
> base-classes which I haven’t used/found yet); this forces us into building
> dedicated routes+ duplicated pattern of components because a simple
> destination URI or an Remote Input/Output path cannot be dynamically
> adjusted but only be set through more pre-defined constants (parameters or
> through VarRegistry).
> This reduces flexibility quite a bit and introduces a lot of complexity to
> the graphical view as this obviously means more graphical clutter on the
> worksheet, a lot more connection lines, additional branching, etc…
> A minor change in logic or a property needs to be touched in several
> places making this relatively error-prone to maintain as well.
>
>
>
> I’d like to propose to extend – by default – fields like: Server
> endpoints, ports , Remote Paths, Input Paths (all these similar type of
> fields which are limited in several components) - with a default capability
> of using attributes/expression language (and by extension parameters and
> the variable registry); this will increase flexibility for many components
> and could de-dupe a lot of graphical flow logic and components.
>
>
>
>
>
>
>
> Best Regards,

Re: JUnit errors

[Kevin Doran]

Hi Akshara,

I suspect it could be related to Java 18. I believe we require Java 17 or
Java 11 (or Java 8, although we are about to drop support for that). Can
you try that?

Thanks,
Kevin

On Sep 8, 2022 at 02:38:11, Akshara Uke  wrote:

> Hello,
>
> I took the latest codebase, and am trying to run unit tests.
> However, I get below error:
>
>
> *Could not initialize plugin: interface org.mockito.plugins.MockMaker
> (alternate: null)*
>
> Similar to this thread :
>
> https://stackoverflow.com/questions/41956692/could-not-initialize-plugin-interface-org-mockito-plugins-mockmake
>
>
> I tried to give explicit dependencies needed by mockito core for the
> version 3.11.2, however the error is still the same.
>  1.11.3
>3.2
>
>   
>net.bytebuddy
>byte-buddy
>${byte.buddy.version}
>test
>
>   
>net.bytebuddy
>byte-buddy-agent
>${byte.buddy.version}
>test
>
>
>org.objenesis
>objenesis
>${objenesis.version}
>test
>
>
> When I change to the latest mockito version (4.7.0) it works fine.
>
> Is anyone else also facing the same issue?
> My java version is
> java --version
> java 18.0.2.1 2022-08-18
>
> Appreciate any help.
>
> Thanks,
> akshara
>

Re: New NiFi PMC Member Nathan Gough

[Kevin Doran]

 Congrats Nathan!

On Sep 7, 2022 at 12:24:17, Otto Fowler  wrote:

> Congratulations, thanks for all you do
>
>
>
>
> From: David Handermann 
> 
> Reply: dev@nifi.apache.org  
> Date: September 7, 2022 at 12:10:21
> To: dev@nifi.apache.org  
> Subject:  New NiFi PMC Member Nathan Gough
>
> Apache NiFi Community,
>
> On behalf of the Apache NiFi Project Management Committee, I am very
> pleased to announce that Nathan Gough has accepted the invitation to join
> the PMC.
>
> Nathan has been a consistent contributor to the project since 2018. In
> addition to developing features and fixes, he regularly reviews pull
> requests and assists others through mailing lists and Slack conversations.
> He also plays an active role in reviewing and updating security reports for
> the project.
>
> Please join us in congratulating and welcoming Nathan to the Apache NiFi
> PMC. Congratulations Nathan!
>

Re: [VOTE] Release Apache NiFi 1.17.0 (RC2)

[Kevin Doran]

+1 (binding)

Ran through the release helper guide on:

Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Java version: 1.8.0_333
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "12.4", arch: "aarch64", family: "mac"

Thanks for RM’ing Joe!
Kevin

On Jul 28, 2022 at 16:10:06, Joe Witt  wrote:

> +1 binding
>
> On Thu, Jul 28, 2022 at 12:54 PM Eduardo Fontes 
> wrote:
>
> Hi,
>
>
> 0 (non-binding)
>
>
> I found a issue about PutDatabaseRecord processor:
>
>
> - https://issues.apache.org/jira/browse/NIFI-10289 PutDatabaseRecord
>
> generating incomplete Merge SQL when using Oracle12DatabaseAdapter
>
>
> I submitted the following pull request to address the issue:
>
>
> - NIFI-10289 https://github.com/apache/nifi/pull/6256
>
>
> Regards,
>
> Eduardo Fontes
>
>
> On Thu, Jul 28, 2022 at 11:28 AM Joe Witt  wrote:
>
>
> > Hello,
>
> >
>
> > I am pleased to be calling this vote for the source release of Apache
>
> NiFi
>
> > 1.17.0.
>
> >
>
> > The source zip, including signatures, digests, etc. can be found at:
>
> > https://repository.apache.org/content/repositories/orgapachenifi-1210
>
> >
>
> > The source being voted upon and the convenience binaries can be found at:
>
> > https://dist.apache.org/repos/dist/dev/nifi/nifi-1.17.0/
>
> >
>
> > A helpful reminder on how the release candidate verification process
>
> works:
>
> >
>
> >
>
>
> https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+release+candidate
>
> >
>
> > The Git tag is nifi-1.17.0-RC2
>
> > The Git commit ID is 8d256784d84cc28bf5642e1bf38dec3eba0c5f23
>
> >
>
> >
>
>
> https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=8d256784d84cc28bf5642e1bf38dec3eba0c5f23
>
> >
>
> > Checksums of nifi-1.17.0-source-release.zip:
>
> > SHA256: 8b9b2088ad966329248cfae7792f576f4f30fea4b4e50f055f84724dba4fe8a3
>
> > SHA512:
>
> >
>
> >
>
>
> 2429348ad514ca7ab9df86aaa57207f1434044c6f7e947d0950ca9826b4f1aa51061617a17444c086eed19b1f26a5ebbe3b455cafed9d219727adf26ecb5f8d2
>
> >
>
> > Release artifacts are signed with the following key:
>
> > https://people.apache.org/keys/committer/joewitt.asc
>
> >
>
> > KEYS file available here:
>
> > https://dist.apache.org/repos/dist/release/nifi/KEYS
>
> >
>
> > 310 issues were closed/resolved for this release:
>
> >
>
> >
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12351438
>
> >
>
> > Release note highlights can be found here:
>
> >
>
> >
>
>
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.17.0
>
> >
>
> > The vote will be open for 72 hours.
>
> > Please download the release candidate and evaluate the necessary items
>
> > including checking hashes, signatures, build from source, and test. Then
>
> > please vote:
>
> >
>
> > [ ] +1 Release this package as nifi-1.17.0
>
> > [ ] +0 no opinion
>
> > [ ] -1 Do not release this package because...
>
> >
>
>
>

Re: [VOTE] Release Apache NiFi 1.17.0 (rc1)

[Kevin Doran]

 +1 (binding)

Verified using the steps from the RC helper guide on an Apple Silicon
(arm64) Mac:

Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: /Users/kdoran/.sdkman/candidates/maven/current
Java version: 1.8.0_333, vendor: BellSoft, runtime:
/Users/kdoran/.sdkman/candidates/java/8.0.333-librca/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "12.4", arch: "aarch64", family: “mac"

Thanks!
Kevin

On Jul 26, 2022 at 11:59:48, Pierre Villard 
wrote:

> +1 (binding)
>
> Went through the usual steps and deployed a secured cluster with secured
> NiFi Registry to run some flows.
>
> Built on Mac OS Monterey 12.4
> Apache Maven 3.8.2 (ea98e05a04480131370aa0c110b8c54cf726c06f)
> Java version: 1.8.0_302, vendor: Azul Systems, Inc., runtime:
> /Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre
>
> Thanks,
> Pierre
>
> Le mar. 26 juil. 2022 à 17:01, Krisztina Zsihovszki  a
> écrit :
>
> Hi!
>
>
> +1 (non-binding)
>
>
> Went through the steps described in helper guide.
>
> - Verified signatures and hashes
>
> - Built on Mac OS Monterey 12.4
>
> - AdoptOpenJDK (build 1.8.0_275)
>
> - Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0)
>
> - Verified that Nifi starts up, tested NIFI-10265 and NIFI-9911
>
>
> Regards,
>
>
> Krisztina
>
>
> On Tue, Jul 26, 2022 at 4:04 PM Otto Fowler 
>
> wrote:
>
>
> >  +1 (non-binding)
>
> > Followed release helper
>
> > Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
>
> > Maven home: /usr/local/Cellar/maven/3.8.6/libexec
>
> > Java version: 1.8.0_292, vendor: AdoptOpenJDK, runtime:
>
> > /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
>
> > Default locale: en_US, platform encoding: UTF-8
>
> > OS name: "mac os x", version: "10.16", arch: "x86_64", family: “mac"
>
> >
>
> > From: Joe Witt  
>
> > Reply: dev@nifi.apache.org  
>
> > Date: July 25, 2022 at 22:57:16
>
> > To: dev@nifi.apache.org  
>
> > Subject:  [VOTE] Release Apache NiFi 1.17.0 (rc1)
>
> >
>
> > Hello,
>
> >
>
> > I am pleased to be calling this vote for the source release of Apache
>
> NiFi
>
> > 1.17.0.
>
> >
>
> > The source zip, including signatures, digests, etc. can be found at:
>
> > https://repository.apache.org/content/repositories/orgapachenifi-1209
>
> >
>
> > The source being voted upon and the convenience binaries can be found at:
>
> > https://dist.apache.org/repos/dist/dev/nifi/nifi-1.17.0/
>
> >
>
> > A helpful reminder on how the release candidate verification process
>
> works:
>
> >
>
> >
>
>
> https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+release+candidate
>
> >
>
> > The Git tag is nifi-1.17.0-RC1
>
> > The Git commit ID is cfa99de02ab5a440e94a2bb0044822ae9d0d99e7
>
> >
>
> >
>
>
> https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=cfa99de02ab5a440e94a2bb0044822ae9d0d99e7
>
> >
>
> > Checksums of nifi-1.17.0-source-release.zip:
>
> > SHA256: 060ac40bbd6f3bac08f724bf040a68d52f4449d2e529af9c1d61db8932aa7b1b
>
> > SHA512:
>
> >
>
> >
>
>
> 97440184d0c34e1f287eba648eb47e5c276df46d6d89c376616939380d95afb6c03b4e4e9ea4170ba62d300637387d532314381225d000d529a6cc5bc4e8b436
>
> >
>
> >
>
> > Release artifacts are signed with the following key:
>
> > https://people.apache.org/keys/committer/joewitt.asc
>
> >
>
> > KEYS file available here:
>
> > https://dist.apache.org/repos/dist/release/nifi/KEYS
>
> >
>
> > 305 issues were closed/resolved for this release:
>
> >
>
> >
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12351438
>
> >
>
> > Release note highlights can be found here:
>
> >
>
> >
>
>
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.17.0
>
> >
>
> > The vote will be open for 72 hours.
>
> > Please download the release candidate and evaluate the necessary items
>
> > including checking hashes, signatures, build from source, and test. Then
>
> > please vote:
>
> >
>
> > [ ] +1 Release this package as nifi-1.17.0
>
> > [ ] +0 no opinion
>
> > [ ] -1 Do not release this package because...
>
> >
>
>
>

Re: [VOTE] Release Apache NiFi NAR Maven Plugin 1.3.5

[Kevin Doran]

 +1 (binding)

Ran through the steps in the Release Helper Guide; everything checked out.

Thanks for the bugfix and RM'ing Bryan!
Kevin

On Jul 20, 2022 at 16:37:16, Bryan Bende  wrote:

> Hello Apache NiFi Community,
>
> I am pleased to be calling this vote for the source release of Apache
> NiFi NAR Maven Plugin 1.3.5.
>
> The source being voted upon, including signatures, digests, etc. can
> be found at:
> https://dist.apache.org/repos/dist/dev/nifi/nifi-nar-maven-plugin-1.3.5/
>
> The Git tag is nifi-nar-maven-plugin-1.3.5-RC1
> The Git commit ID is 77f516a65d796b715278bedd06407d4a8f98f771
>
> https://gitbox.apache.org/repos/asf?p=nifi-maven.git;a=commit;h=77f516a65d796b715278bedd06407d4a8f98f771
>
> Checksums of nifi-nar-maven-plugin-1.3.5-source-release.zip:
> SHA256: 073271bbd28b3d0b9b74c42ab889b4e7301e52b9a0579a3484e7ad0b7f8d3532
> SHA512:
> 9fcc487a197a8d3c5cd297696eb303015c9cde32f89541682dfac921e862c1f1ee8ba5e41573eeb7a5b5190b95c3b49443fca9ed5d5a3f7768a4ea1b031829af
>
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/bbende.asc
>
> KEYS file available here:
> https://dist.apache.org/repos/dist/release/nifi/KEYS
>
> 2 issues were closed/resolved for this release:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12351862
>
> Release note highlights can be found here:
>
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-NiFiNARMavenPluginVersion1.3.5
>
> The vote will be open for 24 hours. Please download the release
> candidate and evaluate the necessary items including checking hashes,
> signatures, build from source, and test. Then please vote:
>
> [ ] +1 Release this package as nifi-nar-maven-plugin-1.3.5
> [ ] +0 no opinion
> [ ] -1 Do not release this package because ...
>

Re: [DISCUSS] Release for NAR Maven Plugin

[Kevin Doran]

 +1 for cutting a release - thanks Bryan!

On Jul 20, 2022 at 15:30:59, Bryan Bende  wrote:

> If there are no objections, I'm planning to kick out another minor
> release for the NAR plugin to release a fix for a bug that was just
> resolved [1] .
>
> [1] https://issues.apache.org/jira/browse/NIFI-10253
>

[RESULT][VOTE] Release Apache NiFi NAR Maven Plugin 1.3.4

[Kevin Doran]

Apache NiFi Community,

I am pleased to announce that the Apache NiFi NAR Maven Plugin 1.3.4
release vote passes with:

  4 +1 (binding) votes
  2 +1 (non-binding) votes
  0 +0 votes
  0 -1 votes

Thanks to all who helped make this release possible!

Here is the vote thread:
https://lists.apache.org/thread/6q8p15djry0ltpz5gxo9wlsrj0h9m537
Regards,
Kevin

Re: [VOTE] Release Apache NiFi NAR Maven Plugin 1.3.4

[Kevin Doran]

 +1 (binding)

On Jun 17, 2022 at 11:50:53, David Handermann 
wrote:

> +1 (binding)
>
> - Verified signature and hashes
> - Ran build on Ubuntu 22.04 with Azul Zulu JDK 1.8.0-332
> - Ran build on Ubuntu 22.04 with Azul Zulu JDK 17.0.3
>
> Thanks Kevin!
>
> Regards,
> David Handermann
>
> On Thu, Jun 16, 2022 at 4:11 PM Kevin Doran  wrote:
>
> Hello Apache NiFi Community,
>
>
> I am pleased to be calling this vote for the source release of Apache
>
> NiFi NAR Maven Plugin 1.3.4.
>
>
> The source being voted upon, including signatures, digests, etc. can
>
> be found at:
>
> https://dist.apache.org/repos/dist/dev/nifi/nifi-nar-maven-plugin-1.3.4/
>
>
> The Git tag is nifi-nar-maven-plugin-1.3.4-RC1
>
> The Git commit ID is c4d9563bff2b5c2120e7f1e181343e2c01cc0422
>
>
>
> https://gitbox.apache.org/repos/asf?p=nifi-maven.git;a=commit;h=c4d9563bff2b5c2120e7f1e181343e2c01cc0422
>
>
> Checksums of nifi-nar-maven-plugin-1.3.4-source-release.zip:
>
> SHA256: acee55a767b9c90c8884e8c6e5fe936088243f778dc7e1de6f281cd4c8a85cab
>
> SHA512:
>
>
> 267cc157117d179517257f47c8d92f3dc5e594b230bb019ccc6e2cb2884b450af56603214fa651bc33aceb3bf0bdb9369aa779672cb3f6f0efd2bacb166f9051
>
>
> Release artifacts are signed with the following key:
>
> https://people.apache.org/keys/committer/kdoran.asc
>
>
> KEYS file available here:
>
> https://dist.apache.org/repos/dist/release/nifi/KEYS
>
>
> 3 issues were closed/resolved for this release:
>
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12350909
>
>
> Release note highlights can be found here:
>
>
>
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-NiFiNARMavenPluginVersion1.3.4
>
>
> The vote will be open for 72 hours. Please download the release
>
> candidate and evaluate the necessary items including checking hashes,
>
> signatures, build from source, and test. Then please vote:
>
>
> [ ] +1 Release this package as nifi-nar-maven-plugin-1.3.4
>
> [ ] +0 no opinion
>
> [ ] -1 Do not release this package because ...
>
>
>

Apache NiFi NAR Maven Plugin 1.3.4 RC1 Release Helper Guide

[Kevin Doran]

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/dev/nifi/KEYS

# Import keys file:
gpg --import KEYS

# [optional] Clear out local maven artifact repository

# Pull down nifi-nar-maven-plugin-1.3.4 source release artifacts for review:

wget 
https://dist.apache.org/repos/dist/dev/nifi/nifi-nar-maven-plugin-1.3.4/nifi-nar-maven-plugin-1.3.4-source-release.zip
wget 
https://dist.apache.org/repos/dist/dev/nifi/nifi-nar-maven-plugin-1.3.4/nifi-nar-maven-plugin-1.3.4-source-release.zip.asc
wget 
https://dist.apache.org/repos/dist/dev/nifi/nifi-nar-maven-plugin-1.3.4/nifi-nar-maven-plugin-1.3.4-source-release.zip.sha256
wget 
https://dist.apache.org/repos/dist/dev/nifi/nifi-nar-maven-plugin-1.3.4/nifi-nar-maven-plugin-1.3.4-source-release.zip.sha512

# Verify the signature
gpg --verify -v nifi-nar-maven-plugin-1.3.4-source-release.zip.asc

# Verify the hashes (sha256, sha512) match the source and what was
provided in the vote email thread
shasum -a 256 nifi-nar-maven-plugin-1.3.4-source-release.zip
shasum -a 512 nifi-nar-maven-plugin-1.3.4-source-release.zip

# Unzip nifi-nar-maven-plugin-1.3.4-source-release.zip
unzip nifi-nar-maven-plugin-1.3.4-source-release.zip

# Verify the build works including release audit tool (RAT) checks
cd nifi-nar-maven-plugin-1.3.4
mvn clean install -Pcontrib-check

# Verify the contents contain a good README, NOTICE, and LICENSE.
# Verify the git commit ID is correct
# Verify the RC was branched off the correct git commit ID

# Verify that NiFi can build NARs correctly using the plugin

- Update NiFi's root pom to use version 1.3.4 of the
pluginhttps://github.com/apache/nifi/blob/master/pom.xml#L556

- Perform a build of NiFi, optionally clear out local .m2 repo
mvn clean install

- Ensure that NiFi starts and loads all processors, controller
services, and reporting tasks

- Spot check a few NARs to ensure they include
META-INF/docs/extension-manifest.xml
cp NIFI_HOME/lib/nifi-xyz-bundle.nar /tmp
cd /tmp
unzip nifi-xyz-bundle.nar
cat META-INF/docs/extension-manifest.xml

# Send a response to the vote thread indicating a +1, 0, -1 based on
your findings.

Thank you for your time and effort to validate the release!

[VOTE] Release Apache NiFi NAR Maven Plugin 1.3.4

[Kevin Doran]

Hello Apache NiFi Community,

I am pleased to be calling this vote for the source release of Apache
NiFi NAR Maven Plugin 1.3.4.

The source being voted upon, including signatures, digests, etc. can
be found at:
https://dist.apache.org/repos/dist/dev/nifi/nifi-nar-maven-plugin-1.3.4/

The Git tag is nifi-nar-maven-plugin-1.3.4-RC1
The Git commit ID is c4d9563bff2b5c2120e7f1e181343e2c01cc0422
https://gitbox.apache.org/repos/asf?p=nifi-maven.git;a=commit;h=c4d9563bff2b5c2120e7f1e181343e2c01cc0422

Checksums of nifi-nar-maven-plugin-1.3.4-source-release.zip:
SHA256: acee55a767b9c90c8884e8c6e5fe936088243f778dc7e1de6f281cd4c8a85cab
SHA512: 
267cc157117d179517257f47c8d92f3dc5e594b230bb019ccc6e2cb2884b450af56603214fa651bc33aceb3bf0bdb9369aa779672cb3f6f0efd2bacb166f9051

Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/kdoran.asc

KEYS file available here:
https://dist.apache.org/repos/dist/release/nifi/KEYS

3 issues were closed/resolved for this release:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12350909

Release note highlights can be found here:
https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-NiFiNARMavenPluginVersion1.3.4

The vote will be open for 72 hours. Please download the release
candidate and evaluate the necessary items including checking hashes,
signatures, build from source, and test. Then please vote:

[ ] +1 Release this package as nifi-nar-maven-plugin-1.3.4
[ ] +0 no opinion
[ ] -1 Do not release this package because ...

Re: [DISCUSS] Strategy for Dropping Java 8 Support in NiFi 2.0

[Kevin Doran]

Pierre and David, I agree with this project goals:


   - a 2.x release that drops support for Java 8 (requires at least Java
   11) by EOY
   - a 3.x release that drops support for Java 11 (requires at least Java
   17) in the not-to-distant future, perhaps 2023/24


This would also mean we could move some of the original goals of 2.x to
target the 3.x line instead, given the deadlines David identified.

Kevin

On Jun 15, 2022 at 13:20:41, David Handermann 
wrote:

> Thanks for the replies Kevin and Pierre!
>
> Various JDK vendors have different timelines for Java 11 support, some
> planning to end active support in September 2023 and others in October
> 2024.  Either way, I agree that moving to Java 11 as the minimum version
> should be a shorter duration, with the goal of making Java 17 the minimum
> before too much time elapses.
>
> As far as a general timeline for removing Java 8 support in NiFi, a good
> goal in my mind would be no later than the end of this calendar year, 2022.
>
> Regards,
> David Handermann
>
> On Wed, Jun 15, 2022 at 11:55 AM Pierre Villard <
> pierre.villard...@gmail.com>
> wrote:
>
> I'd even love to go straight to Java 17 since it's the new LTS version...
>
> but this may be quite a big jump for our community and users.
>
> I guess we can envision a "short" 2.x release line and consider Java 17 for
>
> 3.x.
>
> Definitely approve the proposal!
>
>
> Le mer. 15 juin 2022 à 18:50, Kevin Doran  a écrit :
>
>
> > Thanks for reviving this discussion David. In light of those core
>
> > dependencies dropping support for Java 8, this plan seems necessary for
>
> > NiFi. I support the proposal.
>
> >
>
> > Thanks,
>
> > Kevin
>
> >
>
> > On Jun 15, 2022 at 11:48:05, David Handermann <
>
> exceptionfact...@apache.org
>
> > >
>
> > wrote:
>
> >
>
> > > Team,
>
> > >
>
> > > With multiple major projects in the process of sunsetting support for
>
> > Java
>
> > > 8, we should also prepare a timeline for removing Java 8 support from
>
> > > Apache NiFi and subprojects.
>
> > >
>
> > > BACKGROUND
>
> > >
>
> > > The Jetty project announced the end of community support for version 9
>
> as
>
> > > of 2022-06-01 [1]. Although Jetty 9 is not end of life in terms of
>
> > security
>
> > > updates, this is an important milestone as both NiFi and NiFi Registry
>
> > > leverage Jetty for the web application container. Jetty 10 requires
>
> Java
>
> > 11
>
> > > as the minimum version.
>
> > >
>
> > > The next major release of the Spring Framework will drop support for
>
> both
>
> > > Java 8 and 11, requiring Java 17 as the minimum version [2]. Other
>
> > > supporting components, such as OpenSAML, which enables SAML 2
>
> > integration,
>
> > > dropped support for Java 8 in OpenSAML 4 [3].
>
> > >
>
> > > In order to continue maintaining a secure product, NiFi will also need
>
> to
>
> > > remove Java 8 support so that we can track dependency upgrades.
>
> > >
>
> > > NEXT STEPS
>
> > >
>
> > > In light of widespread deployment of Apache NiFi and subprojects, we
>
> need
>
> > > to prepare a timeline for transition. Although there have been various
>
> > > discussions on what should be included in the next major release,
>
> > narrowing
>
> > > the focus to simply removing support for Java 8 provides the simplest
>
> > path
>
> > > forward.
>
> > >
>
> > > Announcing removal of support for Java 8 should incorporate a
>
> reasonable
>
> > > amount of time for potential transition. NiFi has supported Java 11 for
>
> > > multiple releases, and NiFi 1.16.0 included basic support for Java 17.
>
> > >
>
> > > At minimum, it seems best to proceed with a release for NiFi 1.17.0,
>
> when
>
> > > ready, without making any changes. At that time, we should also have a
>
> > > timeline for removing Java 8 support. It may be worthwhile to plan on
>
> at
>
> > > least one more minor release that incorporates deprecation warnings
>
> where
>
> > > necessary.
>
> > >
>
> > > Following a selected minor release version, a support branch for major
>
> > > version 1 could be created, as a means of providing critical security
>
> and
>
> > > functional fixes. With a support branch created, main development could
>
> > be
>
> > > transitioned to 2.0.0-SNAPSHOT. I defer to Joe Witt as the release
>
> > manager
>
> > > for more thought around these particular details.
>
> > >
>
> > > Please provide your thoughts on the general process, and highlight
>
> > > particular areas of concern.
>
> > >
>
> > > Regards,
>
> > > David Handermann
>
> > >
>
> > > [1] https://github.com/eclipse/jetty.project/issues/7958
>
> > > [2]
>
> > >
>
> > >
>
> >
>
>
> https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6
>
> > > [3] https://shibboleth.atlassian.net/wiki/spaces/OSAML/overview
>
> > >
>
> >
>
>
>

Re: [DISCUSS] Strategy for Dropping Java 8 Support in NiFi 2.0

[Kevin Doran]

Thanks for reviving this discussion David. In light of those core
dependencies dropping support for Java 8, this plan seems necessary for
NiFi. I support the proposal.

Thanks,
Kevin

On Jun 15, 2022 at 11:48:05, David Handermann 
wrote:

> Team,
>
> With multiple major projects in the process of sunsetting support for Java
> 8, we should also prepare a timeline for removing Java 8 support from
> Apache NiFi and subprojects.
>
> BACKGROUND
>
> The Jetty project announced the end of community support for version 9 as
> of 2022-06-01 [1]. Although Jetty 9 is not end of life in terms of security
> updates, this is an important milestone as both NiFi and NiFi Registry
> leverage Jetty for the web application container. Jetty 10 requires Java 11
> as the minimum version.
>
> The next major release of the Spring Framework will drop support for both
> Java 8 and 11, requiring Java 17 as the minimum version [2]. Other
> supporting components, such as OpenSAML, which enables SAML 2 integration,
> dropped support for Java 8 in OpenSAML 4 [3].
>
> In order to continue maintaining a secure product, NiFi will also need to
> remove Java 8 support so that we can track dependency upgrades.
>
> NEXT STEPS
>
> In light of widespread deployment of Apache NiFi and subprojects, we need
> to prepare a timeline for transition. Although there have been various
> discussions on what should be included in the next major release, narrowing
> the focus to simply removing support for Java 8 provides the simplest path
> forward.
>
> Announcing removal of support for Java 8 should incorporate a reasonable
> amount of time for potential transition. NiFi has supported Java 11 for
> multiple releases, and NiFi 1.16.0 included basic support for Java 17.
>
> At minimum, it seems best to proceed with a release for NiFi 1.17.0, when
> ready, without making any changes. At that time, we should also have a
> timeline for removing Java 8 support. It may be worthwhile to plan on at
> least one more minor release that incorporates deprecation warnings where
> necessary.
>
> Following a selected minor release version, a support branch for major
> version 1 could be created, as a means of providing critical security and
> functional fixes. With a support branch created, main development could be
> transitioned to 2.0.0-SNAPSHOT. I defer to Joe Witt as the release manager
> for more thought around these particular details.
>
> Please provide your thoughts on the general process, and highlight
> particular areas of concern.
>
> Regards,
> David Handermann
>
> [1] https://github.com/eclipse/jetty.project/issues/7958
> [2]
>
> https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6
> [3] https://shibboleth.atlassian.net/wiki/spaces/OSAML/overview
>

[DISCUSS] Release for NAR Maven Plugin

[Kevin Doran]

All,

If there are no objections, I would like to put out a maintenance release
(1.3.4) of the NAR Maven plugin, which has had some recent bug fixes and
improvements:


   1. https://issues.apache.org/jira/browse/NIFI-10011
   2. https://issues.apache.org/jira/browse/NIFI-9856
   3. https://issues.apache.org/jira/browse/NIFI-9857


I would be glad to take the role of RM for this release.

Thanks,
Kevin

Re: [VOTE] Release Apache NiFi 1.16.3 (RC1)

[Kevin Doran]

 +1 (binding)


   - verified sigs and hashes
   - build on macOS 12.3.1 - jdk 1.8.0_332
   - built all docker images, and verified using docker compose test env


Thanks for RM'ing!

Kevin

On Jun 14, 2022 at 16:41:25, Peter Turcsanyi  wrote:

> +1 (binding)
>
> - Verified signatures and hashes.
> - Built NiFi on Ubuntu 20.04 with Java 8 (Adoptium Temurin 1.8.0_332-b09),
> Java 11 (Adoptium Temurin 11.0.15+10) and Java 17 (Adoptium Temurin
> 17.0.3+7).
> - Ran some simple flows.
>
> Thanks for RMing Joe!
>
> Peter
>
> On Tue, Jun 14, 2022 at 10:18 PM Andrew Lim 
> wrote:
>
> +1 (binding)
>
>
> -Ran full clean install on OS X (Catalina 10.15.7, OpenJDK version
>
> 1.8.0_252)
>
> -Tested secure NiFi with secure NiFi Registry
>
> -Ran basic flows successfully; tested basic versioned flow functionality
>
>
> Drew
>
>
> > On Jun 14, 2022, at 12:38 AM, Joe Witt  wrote:
>
> >
>
> > Hello,
>
> >
>
> > I am pleased to be calling this vote for the source release of Apache
>
> NiFi
>
> > 1.16.3.
>
> >
>
> > The source zip, including signatures, digests, etc. can be found at:
>
> > https://repository.apache.org/content/repositories/orgapachenifi-1205
>
> >
>
> > The source being voted upon and the convenience binaries can be found at:
>
> > https://dist.apache.org/repos/dist/dev/nifi/nifi-1.16.3/
>
> >
>
> > A helpful reminder on how the release candidate verification process
>
> works:
>
> >
>
>
> https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+release+candidate
>
> >
>
> > The Git tag is nifi-1.16.3-RC1
>
> > The Git commit ID is e15bdd7e3d09047d5fed70117b7c3dfd26f3a36e
>
> >
>
>
> https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=e15bdd7e3d09047d5fed70117b7c3dfd26f3a36e
>
> >
>
> > Checksums of nifi-1.16.3-source-release.zip:
>
> > SHA256: c18edf739361246fe22bb4c2e5a4b1936b6199512b78638868f99b1d827b4d9e
>
> > SHA512:
>
> >
>
>
> e3c9942737a0c2cf43fb3030da3cbee7d6be17038f0cf683c9522db25eb6d8664884594d5a7ce2183733568c06b9ccb52c3a6bf6d5ddcb334d2f84477cc68177
>
> >
>
> > Release artifacts are signed with the following key:
>
> > https://people.apache.org/keys/committer/joewitt.asc
>
> >
>
> > KEYS file available here:
>
> > https://dist.apache.org/repos/dist/release/nifi/KEYS
>
> >
>
> > 13 issues were closed/resolved for this release:
>
> >
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12351844
>
> >
>
> > Release note highlights can be found here:
>
> >
>
>
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.16.3
>
> >
>
> > The vote will be open for 24 hours.
>
> > Please download the release candidate and evaluate the necessary items
>
> > including checking hashes, signatures, build from source, and test. Then
>
> > please vote:
>
> >
>
> > [ ] +1 Release this package as nifi-1.16.3
>
> > [ ] +0 no opinion
>
> > [ ] -1 Do not release this package because...
>
>
>
>

Re: [DISCUSS] MiNiFi C++ 0.12.0 release

[Kevin Doran]

 +1

On May 17, 2022 at 08:29:35, Marc Parisi  wrote:

> Really awesome work from a great team so I think a release is in order as
> well. +1
>
> On Tue, May 17, 2022 at 5:48 AM Gábor Gyimesi  wrote:
>
> +1
>
>
> On Tue, 17 May 2022 at 11:30, Pierre Villard 
>
> wrote:
>
>
> > +1
>
> >
>
> > Le mar. 17 mai 2022 à 10:02, Ádám Markovics  a
>
> > écrit :
>
> >
>
> > > Hi,
>
> > > I also think it's time for a new release.
>
> > > Regards,
>
> > >
>
> > > Ádám
>
> > >
>
> > > On Mon, May 16, 2022 at 5:32 PM Marton Szasz 
>
> wrote:
>
> > >
>
> > > > I agree that it's time for a new release, thanks for RM'ing Martin.
>
> > > >
>
> > > > I have these two issues that I think would be nice to include in the
>
> > > > release:
>
> > > > 1. MINIFICPP-1828 fix InvokeHTTP Attributes to Send
>
> > > > https://github.com/apache/nifi-minifi-cpp/pull/1331
>
> > > > This is a bug that is severe enough that I would prefer to wait for
>
> > > > the fix to get merged before the release.
>
> > > > 2. MINIFICPP-1744: Add FetchGCSObject, DeleteGCSObject, ListGCSBucket
>
> > > > https://github.com/apache/nifi-minifi-cpp/pull/1297
>
> > > > This would be a nice addition to complete the GCS extension. Not
>
> > > > necessarily required for the release, but nice to have IMO. I'll try
>
> > > > to post a second review today or tomorrow.
>
> > > >
>
> > > >
>
> > > >
>
> > > > On Mon, 16 May 2022 at 14:57, Arpad Boda  wrote:
>
> > > > >
>
> > > > > +1
>
> > > > >
>
> > > > > On Mon, May 16, 2022 at 4:12 PM Joe Witt 
>
> wrote:
>
> > > > >
>
> > > > > > Certainly more than enough there!  Thanks Martin
>
> > > > > >
>
> > > > > > On Mon, May 16, 2022 at 7:06 AM Martin Zink <
>
> martinz...@apache.org
>
> > >
>
> > > > wrote:
>
> > > > > >
>
> > > > > > > Hi community,
>
> > > > > > >
>
> > > > > > > I'd like to initiate a discussion about the next release of
>
> > MiNiFi
>
> > > > C++.
>
> > > > > > The
>
> > > > > > > last release was five months ago, and there have been many new
>
> > > > features,
>
> > > > > > > bug fixes and stability improvements committed to the
>
> development
>
> > > > branch
>
> > > > > > > since. (~110 commits)
>
> > > > > > > I would be happy to take on RM duties for this release.
>
> > > > > > >
>
> > > > > > > New features since the 0.11.0 release:
>
> > > > > > > - new processors:
>
> > > > > > >* DeleteAzureBlobStorage
>
> > > > > > >* FetchAzureBlobStorage
>
> > > > > > >* FetchAzureDataLakeStorage
>
> > > > > > >* ListAzureBlobStorage
>
> > > > > > >* ListAzureDataLakeStorage
>
> > > > > > >* PutGCSObject
>
> > > > > > >* ProcFsMonitor
>
> > > > > > >* PutUDP
>
> > > > > > >* FetchFile
>
> > > > > > >* ListFile
>
> > > > > > >* PutSplunkHTTP
>
> > > > > > >* QuerySplunkIndexingStatus
>
> > > > > > >
>
> > > > > > > - Log collection from Kubernetes
>
> > > > > > > - improved support for Lua processors
>
> > > > > > > - platform independent ListenSyslog
>
> > > > > > > - property update over C2 protocol
>
> > > > > > >
>
> > > > > > > The core API is still not mature enough to be able to commit to
>
> > it,
>
> > > > so
>
> > > > > > > in line with previous discussions I suggest releasing it as
>
> > 0.12.0.
>
> > > > > > >
>
> > > > > > > Do you agree it is time for a new release? Are there any
>
> blockers
>
> > > > that we
>
> > > > > > > should definitely include in this release?
>
> > > > > > >
>
> > > > > > > Thanks,
>
> > > > > > > Martin
>
> > > > > > >
>
> > > > > >
>
> > > >
>
> > >
>
> >
>
>
>

Re: Jira contributor access

[Kevin Doran]

 Good point, thanks Marton. Done!

On May 2, 2022 at 11:47:41, Marton Szasz  wrote:

> I believe you will need to add him to NIFIREG as well, here:
> https://issues.apache.org/jira/plugins/servlet/project-config/NIFIREG/roles
> I don't have access to that subproject, hopefully someone can jump in who
> does.
>
> Marton
>
> On Mon, 2 May 2022 at 15:42, Kevin Doran  wrote:
>
>
>  Hi and welcome to the community and thanks for your interest in
>
> contributing ! I've added you as a contributor to our NIFI Jira project.
>
>
> Thanks!
>
> Kevin
>
>
> On Apr 28, 2022 at 23:10:59, Nesa Simon David <
> ultra.redemptio...@gmail.com>
>
> wrote:
>
>
> > Hello my username on Jira is "hellznrg". I would like to contribute to
>
> > development on nifi-registry.
>
> >
>
> > Thanks
>
> >
>
> > --
>
> > Nesa Simon David
>
> > Mobile: 0434059978
>
> >
>
>

Re: Jira contributor access

[Kevin Doran]

 Hi and welcome to the community and thanks for your interest in
contributing ! I've added you as a contributor to our NIFI Jira project.

Thanks!
Kevin

On Apr 28, 2022 at 23:10:59, Nesa Simon David 
wrote:

> Hello my username on Jira is "hellznrg". I would like to contribute to
> development on nifi-registry.
>
> Thanks
>
> --
> Nesa Simon David
> Mobile: 0434059978
>

Re: [ANNOUNCE] New Apache NiFi Committer Adam Markovics

[Kevin Doran]

 Congrats, Adam!

On Mar 28, 2022 at 10:08:24, Otto Fowler  wrote:

> Congratulations!
>
> From: Marton Szasz  
> Reply: dev@nifi.apache.org  
> Date: March 25, 2022 at 08:50:07
> To: dev@nifi.apache.org  
> Subject:  [ANNOUNCE] New Apache NiFi Committer Adam Markovics
>
> Apache NiFi community,
>
> On behalf of the Apache NiFi PMC, I am very pleased to announce that
> Adam Markovics has accepted the PMC's invitation to become a committer
> on the Apache NiFi project. We greatly appreciate all of Adam's hard
> work and generous contributions to the project. We look forward to
> continued involvement in the project.
>
> Adam has been a consistent contributor to MiNiFi C++ for almost 2
> years. His contributions vary from user experience improvements, for
> example better diagnostics for incorrect flow designs, and developer
> quality of life improvements like improved static analysis and better
> test coverage.
>
> Welcome Adam and congratulations!
>

Re: Java 17 and GitHub Workflow Updates

[Kevin Doran]

Thanks for your contributions David, Mike, and Paul! These are all great
updates.

On Mar 17, 2022 at 15:04:32, David Handermann 
wrote:

> Development Team,
>
> Thanks to reviews from Mike Thomsen and Paul Grey, support for building the
> NiFi project on Java 17 is now in the main branch.
>
> The GitHub continuous integration workflow now includes a fourth
> environment:
>
> Ubuntu Zulu JDK 17 EN
>
> Although some dependencies may cause runtime issues with Java 17, this new
> build target will help highlight and correct particular issues. For the
> purpose of compatibility, restricted reflective access is one of the most
> important differences in Java 17.  Java 11 flags these issues as illegal
> reflective access warnings, but Java 17 prevents these operations.
>
> New issues with particular components should be flagged and addressed using
> the standard Jira tracking process.
>
> This is also a good time to mention ongoing work related to JUnit 5. Big
> thanks to Mike Thomsen for working through numerous modules and multiple
> rounds of feedback to update a majority of components to JUnit 5! All new
> test code should use JUnit 5 org.junit.jupiter components.  Some work still
> remains to convert various modules, which can be tracked through sub-tasks
> under the following Jira issue:
>
> https://issues.apache.org/jira/browse/NIFI-9084
>
> Finally, shout out to Paul Grey for his efforts to improve the reliability
> of the NiFi system tests on GitHub.  The resource-constrained GitHub
> runners can expose test stability problems that are difficult to track
> down, but thanks to Paul's work, the stability of the system tests on
> GitHub has improved.
>
> Regards,
> David Handermann
>

Re: [VOTE] Release Apache NiFi 1.16.0 (rc3)

[Kevin Doran]

 +1

Ran through the release helper guide steps
verified signature and hashes
verified build
verified docker images and nifi+registry integration

Thanks for RM'ing Joe!

Kevin

On Mar 21, 2022 at 17:41:41, Joe Witt  wrote:

> Hello,
>
> I am pleased to be calling this vote for the source release of Apache NiFi
> 1.16.0.
>
> The source zip, including signatures, digests, etc. can be found at:
> https://repository.apache.org/content/repositories/orgapachenifi-1198
>
> The source being voted upon and the convenience binaries can be found at:
> https://dist.apache.org/repos/dist/dev/nifi/nifi-1.16.0/
>
> A helpful reminder on how the release candidate verification process works:
>
> https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+release+candidate
>
> The Git tag is nifi-1.16.0-RC3
> The Git commit ID is b019a9191f1c83bc7f547dc02c1b679b8936acee
>
> https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=b019a9191f1c83bc7f547dc02c1b679b8936acee
>
> Checksums of nifi-1.16.0-source-release.zip:
> SHA256: 2f16cb94df404d1bcc9c32835ba98da8940005a5d7ea5504c155ee42021a221e
> SHA512:
>
> cbd95f15cec5ffe506fef204526267b18b77d7266f6dc3e1bbc3c7600aac12e119977f7d8cf93dbbbc86fbb0739ba88aaa11a5381d29a463ec9a0c9a18f4e9e6
>
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/joewitt.asc
>
> KEYS file available here:
> https://dist.apache.org/repos/dist/release/nifi/KEYS
>
> 401 issues were closed/resolved for this release:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12350741
>
> Release note highlights can be found here:
>
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.16.0
>
> The vote will be open for 72 hours.
> Please download the release candidate and evaluate the necessary items
> including checking hashes, signatures, build from source, and test. Then
> please vote:
>
> [ ] +1 Release this package as nifi-1.16.0
> [ ] +0 no opinion
> [ ] -1 Do not release this package because...
>

Re: Question on NiFi Installation

[Kevin Doran]

 Bharath and I already spoke on Apache NiFi Slack, but for the record here
on the dev mailing list:

NiFi is not currently ARM compatible, though some of us in the community
are working on it. If you would like to contribute to or track our progress
building and running on arm64/aarch64 platforms, please see NIFI-9554:
https://issues.apache.org/jira/browse/NIFI-9554

Cheers,
Kevin

On Mar 22, 2022 at 13:41:05, Bharath R  wrote:

> Hello All,
>
> I have a question on NiFi Installation.
> Can NiFi be installed on AWS ARM-Based instances?
> Does NiFi Architecture support it?
>
>
> Thanks,
> Bharath
>

Re: [ANNOUNCE] New Apache NiFi Committer Paul Grey

[Kevin Doran]

Congrats Paul! We’ll deserved

From: Nathan Gough 
Sent: Wednesday, March 16, 2022 9:12:21 PM
To: dev@nifi.apache.org 
Subject: Re: [ANNOUNCE] New Apache NiFi Committer Paul Grey

Congrats, Paul! Thanks for your contributions so far.

On Wed, Mar 16, 2022 at 9:06 PM Marton Szasz  wrote:

> Congratulations, Paul!
>
> On Thu, 17 Mar 2022 at 00:00, Joe Witt  wrote:
> >
> > Congrats and thanks!
> >
> > On Wed, Mar 16, 2022 at 4:55 PM gre...@yahoo.com.INVALID
> >  wrote:
> >
> > > Thanks much!  Next step is to do something about this "yahoo.com"
> email
> > > address...
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Wednesday, March 16, 2022, 06:46:02 PM EDT, David Handermann <
> > > exceptionfact...@apache.org> wrote:
> > >
> > >
> > >
> > >
> > >
> > > Apache NiFi community,
> > >
> > > On behalf of the Apache NiFi PMC, I am very pleased to announce that
> Paul
> > > Grey
> > > has accepted the PMC's invitation to become a committer on the Apache
> NiFi
> > > project.
> > >
> > > Paul has contributed a number of pull requests and code reviews over
> the
> > > past year, improving project security and test stability in a number of
> > > areas. We appreciate Paul's work and look forward to continued
> > > contributions!
> > >
> > > Welcome Paul, and congratulations!
> > >
>

Re: What is the minimum ram storage required to install NiFi

[Kevin Doran]

Hi Ricky,

NiFi is a data processing tool. The system requirements are almost entirely
dependent on your specific use case: how much data will flow through NiFi
and what type of processing will be done on it? For that processing, how
will it utilize cpu, memory, disk, network, etc?

NiFi itself takes up a few GB of space, both on disk and in memory at
runtime, but that is likely not very useful when sizing machines for a NiFi
deployment. Sizing for NiFi is a similar process to sizing a database. In
that case you would care about how much data do you plan to store and what
types of queries will be executed against it, not the size of the database
binaries themselves. Same for NiFi.

Hope this helps,
Kevin

On Feb 17, 2022 at 10:44:37, "Rodriguez, Ricky [USA]"
 wrote:

> Hi,
>
> What are the minimum amounts of storage and ram required for installation
> of NiFi?
>
> Thanks,
>
> Carlos R Rodriguez
>
> Booz | Allen | Hamilton
> BoozAllen.com
> Empower People to Change the World
>
>

Re: apache/nifi convenience Docker Image - publish JDK 11 version?

[Kevin Doran]

Hi Chris,

I forgot to mention - Bryan Bende was able to help me with this, so you should 
have edit permissions in Confluence now.

Thanks,
Kevin

> On Jan 13, 2022, at 12:09, Chris Sampson  
> wrote:
> 
> Thanks Kevin, that's great.
> 
> My username is "chriss".
> 
> 
> ---
> *Chris Sampson*
> IT Consultant
> chris.samp...@naimuri.com
> 
> 
> On Thu, 13 Jan 2022 at 16:38, Kevin Doran  wrote:
> 
>> Thanks, Chris! I’ve incorporated these ideas into the Confluence page.
>> I’ll look into getting you edit permissions - what is your username there?
>> 
>>> On Dec 18, 2021, at 13:35, Chris Sampson 
>> wrote:
>>> 
>>> Kevin,
>>> 
>>> Good idea to write up a list of ideas - unfortunately I don't appear to
>>> have permission to edit the page, but a few other ideas are:
>>> 
>>>  - Provide an "alpine" based image (could be the
>>>  "openjdk:-alpine" image used as a base) to reduce image size
>> and
>>>  O/S footprint of the container
>>>  - Change the Docker start scripts to allow for all nifi.properties (and
>>>  other config file properties) to be set by Environment Variables - this
>>>  could be a case of using a common Env Var prefix to and iterating
>> through
>>>  them within the script, e.g. anything that is NIFI_* is assumed to be a
>>>  nifi.properties entry, etc. - this would make the convenience image
>> all the
>>>  more convenient for people and follow suit with some other applications
>>>  using Docker wrappers
>>>  - Docker-focussed default config, for example logback.xml that directs
>>>  output to STDOUT/STDERR by default, possibly in JSON format, allowing
>>>  easier out-of-the-box use of the logs in Docker-based environments that
>>>  already process Docker log output
>>>  - Allow for the nifi.properties/config file changes during start.sh to
>>>  be skipped (some people inject the config files into their containers
>> but
>>>  want them to be read-only, which then means the start.sh script fails
>>>  because the files can't be edited)
>>>  - Change the default config file locations within the Docker images,
>>>  e.g. the flow.xml.gz and other system generated config that should be
>>>  persisted through container restart would be better in a different
>> folder
>>>  to things like nifi.properties, then the directory can be externalised
>> as a
>>>  Volume (without running into read-only/mutability issues like the
>> start.sh
>>>  point above)
>>>  - Make it easier for Docker-based instances to join an existing cluster
>>>  - this might be a case of relocating some of the files to make better
>> use
>>>  of ephemeral vs. persistent directories/Volumes and/or having a
>>>  configurable mechanism that allows for the cluster config files to be
>>>  deleted during startup if the instance expects to join a cluster but
>> cannot
>>>  because it is unable to overwrite existing files with those being
>> offered
>>>  by the cluster (not sure how much of an issue this still is after some
>>>  recent changes)
>>> 
>>> Please feel free to add any/all of the above to the Confluence page that
>>> you think would be worthwhile to add to the pile for consideration.
>>> 
>>> 
>>> ---
>>> *Chris Sampson*
>>> IT Consultant
>>> chris.samp...@naimuri.com
>>> 
>>> 
>>> On Fri, 17 Dec 2021 at 18:01, Kevin Doran  wrote:
>>> 
>>>> Hi Chris,
>>>> 
>>>> I like this idea and have been thinking of a number of other
>> improvements
>>>> we could make for container images of Apache NiFi, including (I think
>>>> discussed on another thread) consolidating Dockerfiles for dockerhub /
>>>> dockermaven, as the only significant difference is where the nifi
>> assembly
>>>> archive comes from, arm64 images that run native on ARM platforms,
>>>> including newer M1 Macs (requires some minor changes to NiFi source
>> itself
>>>> to compile).
>>>> 
>>>> I’ve started a Wiki page [1] to collect ideas, and once we reach
>> consensus
>>>> on the improvements we’d like to make and possible approaches, we can
>> turn
>>>> these into Jiras.
>>>> 
>>>> [1]
>>>> 
>> https://cwiki.apache.org/confluence/display/NIFI/NiFi+Docker+Container+Improvements
>>>> 
>>>&g

Re: [VOTE] Release Apache NiFi Flow Design System 0.3.0 RC2

[Kevin Doran]

+1 binding

- Verified signature and hashes
- Checked License, Notice, Readme files
- Built using Node 16.13.2 (darmin-arm64)
- Ran demo app and it was working as expected

Thanks for this release, Scott!

-Kevin

> On Jan 26, 2022, at 09:26, David Handermann  
> wrote:
> 
> +1 binding
> 
> - Ran build using Node 16.13.2
> - Verified hashes and signatures
> - Verified License and Notice files
> 
> Thanks Scott!
> 
> Regards,
> David Handermann
> 
> On Wed, Jan 26, 2022 at 8:17 AM Shane Ardell 
> wrote:
> 
>> +1 (non-binding).
>> 
>> Performed all verification steps listed in the helper guide and ran the
>> demo app.
>> 
>> Thanks for RMing, Scott!
>> 
>> On Wed, Jan 26, 2022 at 9:12 AM Matt Gilman 
>> wrote:
>> 
>>> +1 (binding) Release this package as nifi-fds-0.3.0
>>> 
>>> Ran through release helper. Looks good. Thanks for RMing Scott!
>>> 
>>> Matt
>>> 
>>> On Tue, Jan 25, 2022 at 4:41 PM Scott Aslan 
>> wrote:
>>> 
 Hello,
 
 I am pleased to be calling this vote for the source release of Apache
>>> NiFi
 Flow Design System nifi-fds-0.3.0.
 
 The source zip, including signatures, etc. can be found at:
 https://dist.apache.org/repos/dist/dev/nifi/nifi-fds/nifi-fds-0.3.0
 
 The Git tag is nifi-0.3.0-RC2
 The Git commit ID is a17b6712154f1b7bf36a04cfe728b61640843807
 
 
>>> 
>> https://gitbox.apache.org/repos/asf?p=nifi-fds.git;a=commit;h=a17b6712154f1b7bf36a04cfe728b61640843807
 
 Checksums of nifi-fds-0.3.0-source-release.zip:
 SHA1: 92e473c2c0da9f031c47724ade9808f7572dd6bd
 SHA256:
>> 200c8f6a2a7fcdfa5a65c73dfef887c0173a9bf10d73ee7ac0160a614e9202ff
 SHA512:
 
 
>>> 
>> 74b93eb29a5e0bfefd25de288f387308307de63cf159f0c447565615a32b041fe5af20a326528a5dc8e99bf3adc8bbdc157cfa10090d51b30f958bb6253201b9
 
 Release artifacts are signed with the following key:
 https://people.apache.org/keys/committer/scottyaslan.asc
 
 KEYS file available here:
 https://dist.apache.org/repos/dist/release/nifi/KEYS
 
 17 issues were closed/resolved for this release:
 
 
>>> 
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12345959
 
 Release note highlights can be found here:
 
 
>>> 
>> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-NiFiFlowDesignSystem0.3.0
 
 The vote will be open for 72 hours.
 Please download the release candidate and evaluate the necessary items
 including checking hashes, signatures, build from source, and test.
>> Then
 please vote:
 
 [ ] +1 Release this package as nifi-fds-0.3.0
 [ ] +0 no opinion
 [ ] -1 Do not release this package because...
 
>>> 
>> 

Re: [DISCUSS] release nifi-fds 0.3.0

[Kevin Doran]

+1 Thanks Scott!

From: Joe Witt 
Sent: Monday, January 24, 2022 11:33:08 AM
To: dev@nifi.apache.org 
Subject: Re: [DISCUSS] release nifi-fds 0.3.0

Scott

Super good to see us getting this back up to date and thanks for RM.

Joe

On Mon, Jan 24, 2022 at 9:27 AM Scott Aslan  wrote:
>
> All,
>
> I would like to kick out a release of nifi-fds. There are multiple npm
> audit issues and the version of Angular is old. Puls, the nifi-fds v0.2.0
> requires node v8.10.0 and npm v5.6.0 which are very old and already past
> their respective end of life. These older versions of node and npm are also
> blocking [1].
>
> I can take care of putting together the release.
>
> Thanks,
>
> Scott
>
> [1] https://issues.apache.org/jira/browse/NIFI-9554

Re: apache/nifi convenience Docker Image - publish JDK 11 version?

[Kevin Doran]

Thanks, Chris! I’ve incorporated these ideas into the Confluence page. I’ll 
look into getting you edit permissions - what is your username there?

> On Dec 18, 2021, at 13:35, Chris Sampson  
> wrote:
> 
> Kevin,
> 
> Good idea to write up a list of ideas - unfortunately I don't appear to
> have permission to edit the page, but a few other ideas are:
> 
>   - Provide an "alpine" based image (could be the
>   "openjdk:-alpine" image used as a base) to reduce image size and
>   O/S footprint of the container
>   - Change the Docker start scripts to allow for all nifi.properties (and
>   other config file properties) to be set by Environment Variables - this
>   could be a case of using a common Env Var prefix to and iterating through
>   them within the script, e.g. anything that is NIFI_* is assumed to be a
>   nifi.properties entry, etc. - this would make the convenience image all the
>   more convenient for people and follow suit with some other applications
>   using Docker wrappers
>   - Docker-focussed default config, for example logback.xml that directs
>   output to STDOUT/STDERR by default, possibly in JSON format, allowing
>   easier out-of-the-box use of the logs in Docker-based environments that
>   already process Docker log output
>   - Allow for the nifi.properties/config file changes during start.sh to
>   be skipped (some people inject the config files into their containers but
>   want them to be read-only, which then means the start.sh script fails
>   because the files can't be edited)
>   - Change the default config file locations within the Docker images,
>   e.g. the flow.xml.gz and other system generated config that should be
>   persisted through container restart would be better in a different folder
>   to things like nifi.properties, then the directory can be externalised as a
>   Volume (without running into read-only/mutability issues like the start.sh
>   point above)
>   - Make it easier for Docker-based instances to join an existing cluster
>   - this might be a case of relocating some of the files to make better use
>   of ephemeral vs. persistent directories/Volumes and/or having a
>   configurable mechanism that allows for the cluster config files to be
>   deleted during startup if the instance expects to join a cluster but cannot
>   because it is unable to overwrite existing files with those being offered
>   by the cluster (not sure how much of an issue this still is after some
>   recent changes)
> 
> Please feel free to add any/all of the above to the Confluence page that
> you think would be worthwhile to add to the pile for consideration.
> 
> 
> ---
> *Chris Sampson*
> IT Consultant
> chris.samp...@naimuri.com
> 
> 
> On Fri, 17 Dec 2021 at 18:01, Kevin Doran  wrote:
> 
>> Hi Chris,
>> 
>> I like this idea and have been thinking of a number of other improvements
>> we could make for container images of Apache NiFi, including (I think
>> discussed on another thread) consolidating Dockerfiles for dockerhub /
>> dockermaven, as the only significant difference is where the nifi assembly
>> archive comes from, arm64 images that run native on ARM platforms,
>> including newer M1 Macs (requires some minor changes to NiFi source itself
>> to compile).
>> 
>> I’ve started a Wiki page [1] to collect ideas, and once we reach consensus
>> on the improvements we’d like to make and possible approaches, we can turn
>> these into Jiras.
>> 
>> [1]
>> https://cwiki.apache.org/confluence/display/NIFI/NiFi+Docker+Container+Improvements
>> 
>> Thanks!
>> Kevin
>> 
>>> On Nov 26, 2021, at 07:46, Chris Sampson 
>> wrote:
>>> 
>>> I'm not sure whether I've seen this discussed previously, but I thought
>> it
>>> worth asking whether we could/should publish a JDK 11 based version of
>> the
>>> apache/nifi Docker Image to Docker Hub as part of the release process in
>>> future?
>>> 
>>> I realise NiFi 1.x is/will remain based on JDK 8 but with all the work
>> gone
>>> into enabling JDK 11 compilation and deployment, along with the planned
>>> move to JDK 11 in the future for NiFi 2.x, it would seem sensible to
>> start
>>> making it easier for people to move towards using JDK 11 now that it's
>>> available.
>>> 
>>> The Dockerfiles used to build NiFi (I've not looked at Toolkit, MiNiFi or
>>> Registry) can be given a build ARG to use different base images/versions,
>>> so it should be relatively straightforward to do this and maybe publish
>> the
>>> Image to Docker Hub as *apache/nifi:-jdk11*?
>>> 
>>> Users can, of course, download the NiFi source to build this image
>>> themselves, but to make it easier for the community it would seem
>> sensible
>>> to consider the additional release artifact. This avoids lots of people
>>> having to pull all of the code (it's not a small repo) or build the
>> image,
>>> which can take a long time, etc.
>>> 
>>> 
>>> ---
>>> *Chris Sampson*
>>> IT Consultant
>>> chris.samp...@naimuri.com
>> 
>> 

Re: Apache NiFi support for Apple arm64 processors

[Kevin Doran]

Hi Aleksander,

Sorry for the (very) delayed response, but I recently ran into this
myself and opened a Jira [1] to track making progress on support for
Apple Silicon platforms.

Once that is completed, I plan to look into building arm64 Docker
images as well. Improvement ideas for Apache NiFi docker images are
being collected here [2], and includes supporting arm64 platforms.

[1] https://issues.apache.org/jira/browse/NIFI-9554
[2] 
https://cwiki.apache.org/confluence/display/NIFI/NiFi+Docker+Container+Improvements

Cheers,
Kevin

On Tue, Jun 15, 2021 at 8:49 AM Aleksander Rękawek
 wrote:
>
> Hello,
>
> I`m writing to You because i face issues with NiFi running (or rather not 
> running) on Apple MacBook with M1 (silicon) CPU, on docker and also as 
> service runned from command line.
> I was trying to build docker image with arm64v8/openjdk but there was some 
> problems with Jetty, it don§t want to start or report error about http/https 
> (that it cannot be setted up both).
> Application started as a service from terminal doesn`t want to start and only 
> report:
>
>
> INFO [main] org.apache.nifi.bootstrap.Command Launched Apache NiFi with 
> Process ID 27315
>
> And then crush without any error message.
> If You need any further information or logs i can send it.
> If You have any suggestions or advices how i can solve it, I will be very 
> gratefull.
>
> BR,
> Aleksander

Re: apache/nifi convenience Docker Image - publish JDK 11 version?

[Kevin Doran]

Hi Chris,

I like this idea and have been thinking of a number of other improvements we 
could make for container images of Apache NiFi, including (I think discussed on 
another thread) consolidating Dockerfiles for dockerhub / dockermaven, as the 
only significant difference is where the nifi assembly archive comes from, 
arm64 images that run native on ARM platforms, including newer M1 Macs 
(requires some minor changes to NiFi source itself to compile).

I’ve started a Wiki page [1] to collect ideas, and once we reach consensus on 
the improvements we’d like to make and possible approaches, we can turn these 
into Jiras.

[1] 
https://cwiki.apache.org/confluence/display/NIFI/NiFi+Docker+Container+Improvements
 

Thanks!
Kevin

> On Nov 26, 2021, at 07:46, Chris Sampson  
> wrote:
> 
> I'm not sure whether I've seen this discussed previously, but I thought it
> worth asking whether we could/should publish a JDK 11 based version of the
> apache/nifi Docker Image to Docker Hub as part of the release process in
> future?
> 
> I realise NiFi 1.x is/will remain based on JDK 8 but with all the work gone
> into enabling JDK 11 compilation and deployment, along with the planned
> move to JDK 11 in the future for NiFi 2.x, it would seem sensible to start
> making it easier for people to move towards using JDK 11 now that it's
> available.
> 
> The Dockerfiles used to build NiFi (I've not looked at Toolkit, MiNiFi or
> Registry) can be given a build ARG to use different base images/versions,
> so it should be relatively straightforward to do this and maybe publish the
> Image to Docker Hub as *apache/nifi:-jdk11*?
> 
> Users can, of course, download the NiFi source to build this image
> themselves, but to make it easier for the community it would seem sensible
> to consider the additional release artifact. This avoids lots of people
> having to pull all of the code (it's not a small repo) or build the image,
> which can take a long time, etc.
> 
> 
> ---
> *Chris Sampson*
> IT Consultant
> chris.samp...@naimuri.com

Re: [ANNOUNCE] New Apache NiFi Committer Margot Tien

[Kevin Doran]

Congratulations Margot! Well deserved.

> On Dec 15, 2021, at 13:47, Joe Witt  wrote:
> 
> Congrats Margot!   And thanks
> 
> On Wed, Dec 15, 2021 at 11:46 AM Matt Gilman  wrote:
> 
>> Apache NiFi community,
>> 
>> On behalf of the Apache NiFi PMC, I am very pleased to announce that Margot
>> has accepted the PMC's invitation to become a committer on the Apache NiFi
>> project. We greatly appreciate all of Margot's hard work and generous
>> contributions to the project. We look forward to continued involvement in
>> the project.
>> 
>> Margot has been contributing to NiFi and NiFi Registry for years. Her
>> contributions have covered both back-end and front-end improvements in both
>> projects in addition to release verification and thoughtful PR reviews.
>> 
>> Welcome and congratulations!
>> 

Re: [VOTE] Release Apache NiFi MiNiFi C++ 0.11.0 RC2

[Kevin Doran]

+1 (binding)

Checked sigs and hashes and did my usual docker-based build and test. Looks 
good, nice work everyone!

Kevin

> On Dec 8, 2021, at 11:48, Marton Szasz  wrote:
> 
> +1 (binding)
> Went through the usual checks, built, ran tests and packaged on gentoo
> with gcc 11.2.1 and clang 13.0.0, then tested the convenience binary
> on ubuntu 16.04 collecting logs with ConsumeJournald -> InvokeHTTP
> sending it to the gentoo clang version ListenHTTP -> LogAttribute.
> 
> Thanks,
> Marton
> 
> On Wed, 8 Dec 2021 at 12:17, Martin Zink  wrote:
>> 
>> +1 (non binding)
>> Verified the hashes and built on Manjaro and win10
>> Tested a couple example flows (\examples\pdh_config.yml,
>> \examples\tailfile_config.yml)
>> Everything works as expected
>> 
>> Thanks,
>> Martin
>> 
>> On Wed, Dec 8, 2021 at 1:03 PM Marc Parisi  wrote:
>> 
>>> +1 verified sigs and hashes and ran some test flows from a local cluster
>>> gathering log data sending to nifi via site to site.
>>> 
>>> Works great!
>>> 
>>> On Wed, Dec 8, 2021 at 6:51 AM Ádám Markovics 
>>> wrote:
>>> 
 +1 (non-binding)
 Verified and built on Ubuntu 20.04. Ran tests and also ran a simple
 (GetFile-PutFile) flow.
 Regards,
 
 Ádám
 
 On Mon, Dec 6, 2021 at 12:06 PM Adam Debreceni 
 wrote:
 
> Hello,
> 
> I am pleased to be calling this vote for the source release of Apache
 NiFi
> MiNiFi C++ 0.11.0.
> 
> The source tarball, the binary build, plus signatures and digests can
>>> be
> found at:
> https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/0.11.0/
> 
> The Git tag is minifi-cpp-0.11.0-RC2
> The Git commit ID is 0553df446aefb395b34c1e4e2b5ced31f07a4e04
> 
> 
 
>>> https://git-wip-us.apache.org/repos/asf?p=nifi-minifi-cpp.git;a=commit;h=0553df446aefb395b34c1e4e2b5ced31f07a4e04
> 
> Checksums of nifi-minifi-cpp-0.11.0-source.tar.gz:
> SHA256:
>>> 98e161436f2ae1b9eacf27493fe3420891aa5e4e70c20216ec186c5e23c2c11d
> SHA512:
> 
> 
 
>>> 8e968d9d58ea793d1f6f064374c07ac0ef296c2fd895941ea74c879e06fc95c48100fd9c2d28bc2bc5c523c8ad229a77a5626f8311c038aeb87d8fd4324dfe0e
> 
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/adebreceni.asc
> 
> KEYS file available here:
> https://dist.apache.org/repos/dist/release/nifi/KEYS
> 
> 86 issues were closed/resolved for this release:
> https://issues.apache.org/jira/projects/MINIFICPP/versions/12350247
> 
> Release note highlights can be found here:
> 
> 
 
>>> https://cwiki.apache.org/confluence/display/MINIFI/Release+Notes#ReleaseNotes-Versioncpp-0.11.0
> 
> The vote will be open for 72 hours.
> Please download the release candidate and evaluate the necessary items
> including checking hashes, signatures, build
> from source, and test. Then please vote:
> 
> [ ] +1 Release this package as nifi-minifi-cpp-0.11.0
> [ ] +0 no opinion
> [ ] -1 Do not release this package because...
> 
 
>>> 

Re: [VOTE] Release Apache NiFi NAR Maven Plugin 1.3.3

[Kevin Doran]

+1, binding

Verified sigs/hashes/license/notice. Tried it out and it works as described. 
Thanks Bryan!

> On Dec 2, 2021, at 12:09, Matt Gilman  wrote:
> 
> +1 (binding)
> 
> Ran through the release helper. Looked great! Thanks for RMing Bryan!
> 
> Matt
> 
> On Thu, Dec 2, 2021 at 11:28 AM Matt Burgess  wrote:
> 
>> +1 (binding), ran through release helper and verified NARs were loaded
>> successfully into a NiFi instance.  Thanks for RM'ing Bryan!
>> 
>> On Tue, Nov 30, 2021 at 3:56 PM Bryan Bende  wrote:
>>> 
>>> Hello,
>>> 
>>> I am pleased to be calling this vote for the source release of Apache
>>> NiFi NAR Maven Plugin 1.3.3.
>>> 
>>> The source zip, including signatures, digests, etc. can be found at:
>>> https://repository.apache.org/content/repositories/orgapachenifi-1188
>>> 
>>> The source being voted upon and the convenience binaries can be found at:
>>> https://dist.apache.org/repos/dist/dev/nifi/nifi-nar-maven-plugin-1.3.3/
>>> 
>>> A helpful reminder on how the release candidate verification process
>> works:
>>> 
>> https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+release+candidate
>>> 
>>> The Git tag is nifi-nar-maven-plugin-1.3.3-RC1
>>> The Git commit ID is 99f1ff7184e00cecc4763b7bcbdf0d12dfeffef2
>>> 
>> https://gitbox.apache.org/repos/asf?p=nifi-maven.git;a=commit;h=99f1ff7184e00cecc4763b7bcbdf0d12dfeffef2
>>> 
>>> Checksums of nifi-nar-maven-plugin-1.3.3-source-release.zip:
>>> SHA256: 36d6579dfdbc4e1450a13457196ff399dbd344624348a62ee5e247cd5962dc77
>>> SHA512:
>> 0e90100d90e9dd142283aab729957e12cc6abbfdf2f86447f488bcbe5890d55564c19a0efc473307744f813bcdac2636b027ad4e5beebf1ce1ed6ee44deaccbe
>>> 
>>> Release artifacts are signed with the following key:
>>> https://people.apache.org/keys/committer/bbende.asc
>>> 
>>> KEYS file available here:
>>> https://dist.apache.org/repos/dist/release/nifi/KEYS
>>> 
>>> 1 issue was closed/resolved for this release:
>>> 
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12348815
>>> 
>>> Release note highlights can be found here:
>>> 
>> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-NiFiNARMavenPluginVersion1.3.3
>>> 
>>> The vote will be open for 72 hours. Please download the release
>>> candidate and evaluate the necessary items including checking hashes,
>>> signatures, build from source, and test. Then please vote:
>>> 
>>> [ ] +1 Release this package as nifi-nar-maven-plugin-1.3.3
>>> [ ] +0 no opinion
>>> [ ] -1 Do not release this package because...
>> 

Re: [DISCUSS] The future of (Mi)NiFi Command and Control (C2)

[Kevin Doran]

Hi Matt,

Thanks for kicking of this thread. The discussion here puts into words some 
things that have been on my mind for a while, and its really exciting to see a 
revival of these conversations. 

Overall, I support the proposal. Here are some specific thoughts, in no 
particular order.

One of the valuable things I see emerging in the NiFi ecosystem is the 
separation of flow design and flow runtime, with runtime options being NiFi, 
MiNiFi (C++/Java), and NiFi Stateless — and that is before you even look at the 
underlying infrastructure options such as bare metal, virtual, containerized, 
or server-less —  so standardizing a portable, serialized format of flow 
definitions seems like a huge advantage for the ecosystem. The 
VersionedFlowSnapshot has emerged as the best option for that. I see there is 
work on NiFi to even replace the flow.xml.gz with this format, so updating 
MiNiFi to support it as well as an alternative (and perhaps eventually 
replacement) for config.yml would be in line with that.

I think a reference Java implementation of the C2 Spec implemented by the 
MiNiFi C++ agent would be a huge step forward for the goal of unified C2 across 
the NiFi ecosystem. For the capabilities we would like to support, the MiNiFi 
C++ C2 Protocol is the correct one to standardize on in order to support the 
wide array of C2 capabilities we would like to (compared to, for example, the 
PullHttpChangeIngestor currently supported by MiNiFi Java).

Regarding process control vs. flow / metadata control: I think the C2 Protocol 
Spec is flexible enough to support both, and that how a C2 client implements 
support for C2 operation commands is an implementation detail for the client. I 
know that the current MiNiFi C++ client can handle both process and flow 
control, and I don’t think that needs to change. I think for the MVP for the 
proposed MiNiFi Java client, focusing on flow control makes sense. I agree with 
Marc that beyond the MVP, process control of a MiNiFi Java agent may be 
desirable, but I don’t think the proposed approach makes that infeasible. 
Because the Bootstrap<->MiNiFi control bus is bidirectional, I could foresee 
the C2 client in the MiNiFi process forwarding process control operations to a 
C2 helper in the bootstrap process. In other words, a C2 client in the core 
(Mi)NiFi framework could send a message to bootstrap saying “please change my 
config to X and restart me”. I view the C2 Protocol as being a superset of all 
possible functionality a NiFi Runtime could support, and process control 
commands might not even exist for a runtime such as NiFi Stateless on 
serverless infrastructure (but metadata exchange might), so such a runtime that 
wants to implement a subset of the C2 Protocol operations could just choose not 
to support such things that don’t make sense.

One last thought: anything that more closely aligns the implementation of 
MiNiFi Java and NiFi is a big step in the right direction, so building this C2 
capability out in NiFi such that we can take advantage of it in MiNiFi Java 
seems to be the best thing to do. If NiFi is able to run with a smaller 
footprint and pull in extensions at runtime, then supporting C2 in NiFi proper 
probably also makes sense as a way of central control for say, a fleet of 
containerized NiFi instances.

Thanks,
Kevin



> On Nov 22, 2021, at 10:03, Matt Burgess  wrote:
> 
> I'm the same, historically I've viewed and implemented C2 as process
> control as well. These days with sophisticated containerization and
> deployment tools, I'm thinking we leave the process orchestration to
> them and concentrate on controlling what the processes are doing.
> 
> All, any other thoughts, questions, or concerns? If not, I will update
> the C2 page(s) on the Wiki as discussed and start writing up some
> Jiras to cover the work, and we can continue individual feature
> discussions there.
> 
> Thanks,
> Matt
> 
> On Sat, Nov 20, 2021 at 6:19 AM Marc Parisi  wrote:
>> 
>> " This would align it more to the way NiFi works as
>> well, allowing C2 to be used for flow control and metadata exchange
>> rather than process control."
>> 
>> This particularly caught my eye and is something that makes sense from an
>> evolutionary perspective.
>> 
>> I've previously viewed command and control as a mechanism to control the
>> agent processes and their flows.
>> 
>> From an operational perspective, I think that agent process control would
>> be nice to have (if not a necessity for some ); however, if C2 is scoped to
>> metadata and flow control at least -- through the MVP or permanently --
>> then the conversation is simpler and I think your proposal is great.
>> 
>> Thanks for the additional insight, Matt.
>> 
>> Thanks,
>> Marc
>> 
>> 
>> 
>> 
>> 
>> On Thu, Nov 18, 2021 at 4:37 PM Matt Burgess  wrote:
>> 
>>> Marc,
>>> 
>>> That's a great point and reminds me that I missed two whole sections
>>> of the proposal: 1) The refactor of minifi-bootstrap, and 2) the

Re: [DISCUSS] MiNiFi C++ 0.11.0 release

[Kevin Doran]

+1 thanks all!

> On Nov 18, 2021, at 11:30 AM, Arpad Boda  wrote:
> 
> +1
> 
> On Thu, Nov 18, 2021 at 5:23 PM Ádám Markovics  wrote:
> 
>> I also agree on releasing. Let's do it!
>> 
>> Ádám
>> 
>> On Thu, Nov 18, 2021 at 4:05 PM Joe Witt  wrote:
>> 
>>> Sounds like a great time to cut a new release.
>>> 
>>> On Thu, Nov 18, 2021 at 7:32 AM Gábor Gyimesi 
>> wrote:
 
 Sounds good to me as well!
 
 Thanks,
 Gabor
 
 On Thu, 18 Nov 2021 at 15:27, Ferenc Gerlits 
>>> wrote:
 
> Yes, it's definitely time for a new release, and 0.11.0 sounds good.
> Thanks for RMing!
> 
> Ferenc
> 
> 
> On Wed, Nov 17, 2021 at 12:09 PM Marton Szasz 
>>> wrote:
> 
>> I agree that it's time for a new release, thank you for taking the
>> RM
>> duties. I'm not aware of any blockers at the moment.
>> 
>> Thanks,
>> Marton
>> 
>> On Wed, 17 Nov 2021 at 10:28, Adam Debreceni <
>> adebrec...@apache.org>
>> wrote:
>>> 
>>> Hi community,
>>> 
>>> I'd like to initiate a discussion about the next release of
>> MiNiFi
>>> C++.
>> The
>>> last release was five months ago, and there have been many new
> features,
>>> bug fixes and stability improvements committed to the development
> branch
>>> since.
>>> I would be happy to take on RM duties for this release.
>>> 
>>> New features since the 0.10.0 release:
>>> - new processors:
>>>   * AttributesToJson
>>>   * DefragmentText
>>>   * PutAzureDataLakeStorage
>>>   * ReplaceText
>>>   * RouteText
>>> - support for funnels
>>> - shared rocksdb repository
>>> - repository encryption (flow-file, content)
>>> - support for Azure managed identity
>>> - modularization of extensions
>>> - ConsumeKafka security protocol
>>> - platform independent AppendHostInfo
>>> - agent configuration checksum in the c2 heartbeat
>>> 
>>> We now use C++17 throughout the codebase and C++20 wherever
>>> possible.
>>> 
>>> The core API is still not mature enough to be able to commit to
>>> it, so
>>> in line with previous discussions I suggest releasing it as
>> 0.11.0.
>>> 
>>> Do you agree it is time for a new release?  Are there any
>> blockers
>>> that
>> we
>>> should definitely include in this release?
>>> 
>>> Thanks,
>>> Adam
>> 
> 
>>> 
>> 

Re: [discuss] NiFi 1.15

[Kevin Doran]

Thanks, Chris! I’ll take a look at that PR.

Regarding this: 

> Might be worth considering building the docker build & push into the CI
> pipeline for the release if it's not already (and if that would fit how the
> release process works).

I’ve looked into automating in the past, and it might be possible to setup as a 
(manual) GitHub Action workflow with some help from ASF Infra. There is some 
concern about leaking credentials, so we left it at needing to do some 
investigation for if GitHub Actions Secrets meets their criteria for security.

In any case, I intent to write up the manual process I use now, which could be 
a starting point for how to automate in the future. Will share this next week 
most likely.

Cheers,
Kevin


> On Nov 6, 2021, at 15:58, Chris Sampson  
> wrote:
> 
> I've updated NIFI-8779 PR [1] to at least remove the duplicated scripts
> between nifi docker hub & maven builds (as well as update the plugin
> versions and make the integration tests work again).
> 
> There's still work to do to rationalise the builds properly in future, but
> this might be a step in the right direction at least (although we might
> decide to use the learnings from the PR and this discussion and instead
> rework things more fully in future).
> 
> Might be worth considering building the docker build & push into the CI
> pipeline for the release if it's not already (and if that would fit how the
> release process works).
> 
> 
> [1] https://github.com/apache/nifi/pull/5213
> 
> 
> Cheers,
> 
> Chris Sampson
> 
> On Fri, 5 Nov 2021, 14:15 David Handermann, 
> wrote:
> 
>> Thanks for the update Chris!
>> 
>> I agree with the suggestion to streamline the Dockerfiles for NiFi builds,
>> there is a lot of duplication between dockermaven and dockerhub, so
>> unifying the modules and parameterizing necessary differences would be a
>> helpful improvement.
>> 
>> Regards,
>> David Handermann
>> 
>> On Fri, Nov 5, 2021 at 9:10 AM Kevin Doran  wrote:
>> 
>>> Hi Chris,
>>> 
>>> Thanks for the summary of your findings.
>>> 
>>> I agree that we should clear up our process for generating Docker images
>>> and that the process should be consistent as possible across NiFi, MiNiFi
>>> Java, Registry, and Toolkit given they are all part of the same
>> repository
>>> and maven project. This will clear up confusion and improve
>>> maintainability.
>>> 
>>> I think both of these methods are important and useful:
>>> 
>>> 1. building from downloaded convenience binaries for previously released
>>> versions
>>> 2. building from a local assembly output
>>> 
>>> That said, I think we could probably consolidate to a single Dockerfile
>>> that takes the binary location as an argument that supports either a URL
>> or
>>> local file path (or a version which could default to the current behavior
>>> of inferring a URL location). This would let us continue to support the
>>> flexibility we have today while maintaining a single Docker file rather
>>> than dockermaven and dockerhub variants. If you and others on the list
>>> agree, I can open up a Jira summarizing what needs to be done.
>>> 
>>> Thanks,
>>> Kevin
>>> 
>>>> On Nov 5, 2021, at 05:00, Chris Sampson > .INVALID>
>>> wrote:
>>>> 
>>>> So the good news is that I realised what I was doing wrong yesterday -
>>> I'd
>>>> started a local installation after building the RC, then not shut that
>>> down
>>>> before booting up the Docker instance, so the username/password I was
>>>> trying to use from the Docker logs was wrong against the local
>>>> installation, d'oh!
>>>> 
>>>> Having corrected that this morning, I've successfully booted up and
>>> logged
>>>> into a Docker instance built using the RC (with my NIFI-8779 changes
>> so I
>>>> could build from the Dev server instead of the main Apache Archive).
>>>> 
>>>> The reason the dockermaven build works is that it uses the locally
>> built
>>>> archive files (i.e. you have to do a full Maven build locally first to
>>>> generate the ZIP files and then create teh Docker image). The
>>>> dockerhub build actually downloads published artifacts from the Apache
>>>> servers - to do this the Dockerfile needs to know the exact path to the
>>>> artifacts it's trying to download, of course.
>>>> 
>>

Re: [VOTE] Release Apache NiFi 1.15.0 (rc3)

[Kevin Doran]

+1 (binding)

- Verified sigs and hashes (see note below)
- Built from source
- Built docker images for nifi, registry, minifi, minifi-c2, nifi-toolkit
- Ran nifi and nifi-registry in docker compose
- Used nifi to create a versioned PG to save to registry
- Used minify-toolkit to test converting PG from json and xml to yaml
- Used minifi-c2 convienence binary to host resulting yaml
- Tested MiNiFi java to pull config.yml from minifi-c2 server using 
PullHttpChangeIngestor

One important note for Joe:

For the convenience binaries, minifi-c2-1.15.0-bin.tar.gz.sha256 and 
minifi-c2-1.15.0-bin.zip.sha256 hashes do not match SHA 256 hash digests. They 
contain the sha512 values. Those file names should be updated to 
minifi-c2-1.15.0-bin.tar.gz.sha512 and minifi-c2-1.15.0-bin.zip.sha512 assuming 
this RC passes.

Other observations

- NiFi docker readme instructions should updated for sensitive properties keys. 
I will do this as part of pushing docker images to docker hub following the 
1.15 release
- NiFi Registry Dockerfile needs to add a step to chmod +x the startup script, 
in case it is not in the source checkout. I will open a jira for this.

Thanks all!
Kevin


> On Nov 5, 2021, at 17:58, Marton Szasz  wrote:
> 
> +1 (binding)
> 
> Followed the release helper guide, tested systemd-journald message
> collection from three minifi c++ linux agents to a single nifi
> instance via putudp/listenudp.
> Environment:
> Apache Maven 3.8.3 (ff8e977a158738155dc465c6a97ffaf31982d739)
> Maven home: /usr/share/maven-bin-3.8
> Java version: 1.8.0_252, vendor: IcedTea, runtime: /opt/icedtea-bin-3.16.0/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.14.14-gentoo-x86_64", arch: "amd64",
> family: "unix"
> 
> Marton
> 
> On Fri, 5 Nov 2021 at 21:33, Joey Frazee  
> wrote:
>> 
>> +1 (binding)
>> 
>> - Verified signatures and checksums (except for prior comment on minifi-c2)
>> - Ran full build on Linux with Java 1.8.0_292
>> - Ran various flows and ITs
>> - Built and ran dockermaven Docker build
>> 
>> -joey
>> 
>>> On Nov 5, 2021, at 1:50 PM, Andrew Lim  wrote:
>>> 
>>> +1 (binding)
>>> 
>>> -Ran full clean install on OS X (Catalina 10.15.2, OpenJDK version 
>>> 1.8.0_252)
>>> -Tested secure NiFi with secure NiFi Registry
>>> -Ran basic flows successfully; tested basic versioned flow functionality
>>> -Reviewed UI fixes and documentation updates
>>> 
>>> Drew
>>> 
 On Nov 3, 2021, at 3:29 PM, Joe Witt  wrote:
 
 Hello,
 
 I am pleased to be calling this vote for the source release of Apache
 NiFi 1.15.0.
 
 The source zip, including signatures, digests, etc. can be found at:
 https://repository.apache.org/content/repositories/orgapachenifi-1186
 
 The source being voted upon and the convenience binaries can be found at:
 https://dist.apache.org/repos/dist/dev/nifi/nifi-1.15.0/
 
 A helpful reminder on how the release candidate verification process works:
 https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+release+candidate
 
 The Git tag is nifi-1.15.0-RC3
 The Git commit ID is 7fdc07cccdc0e23d4986557a9314e36859704a3b
 https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=7fdc07cccdc0e23d4986557a9314e36859704a3b
 
 Checksums of nifi-1.15.0-source-release.zip:
 SHA256: 56fe317248941fdbc6216ec973e6ce898d0f682a54e2d063edbabf8542f5288a
 SHA512: 
 63f10d9127cf1613c29bf2306be3d7a5b931b31304920706e0df5ea2fe87b58c410efed6ac37afc38d12c65e69f14aec7afb926000fc90cc13f15c738cd15c7f
 
 Release artifacts are signed with the following key:
 https://people.apache.org/keys/committer/joewitt.asc
 
 KEYS file available here:
 https://dist.apache.org/repos/dist/release/nifi/KEYS
 
 234 issues were closed/resolved for this release:
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12350382
 
 Release note highlights can be found here:
 https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.15.0
 
 The vote will be open for 72 hours.
 Please download the release candidate and evaluate the necessary items
 including checking hashes, signatures, build from source, and test.
 Then please vote:
 
 [ ] +1 Release this package as nifi-1.15.0
 [ ] +0 no opinion
 [ ] -1 Do not release this package because...
>>> 

Re: [discuss] NiFi 1.15

[Kevin Doran]

Hi Chris,

Thanks for the summary of your findings.

I agree that we should clear up our process for generating Docker images and 
that the process should be consistent as possible across NiFi, MiNiFi Java, 
Registry, and Toolkit given they are all part of the same repository and maven 
project. This will clear up confusion and improve maintainability. 

I think both of these methods are important and useful:

1. building from downloaded convenience binaries for previously released 
versions
2. building from a local assembly output

That said, I think we could probably consolidate to a single Dockerfile that 
takes the binary location as an argument that supports either a URL or local 
file path (or a version which could default to the current behavior of 
inferring a URL location). This would let us continue to support the 
flexibility we have today while maintaining a single Docker file rather than 
dockermaven and dockerhub variants. If you and others on the list agree, I can 
open up a Jira summarizing what needs to be done.

Thanks,
Kevin

> On Nov 5, 2021, at 05:00, Chris Sampson  
> wrote:
> 
> So the good news is that I realised what I was doing wrong yesterday - I'd
> started a local installation after building the RC, then not shut that down
> before booting up the Docker instance, so the username/password I was
> trying to use from the Docker logs was wrong against the local
> installation, d'oh!
> 
> Having corrected that this morning, I've successfully booted up and logged
> into a Docker instance built using the RC (with my NIFI-8779 changes so I
> could build from the Dev server instead of the main Apache Archive).
> 
> The reason the dockermaven build works is that it uses the locally built
> archive files (i.e. you have to do a full Maven build locally first to
> generate the ZIP files and then create teh Docker image). The
> dockerhub build actually downloads published artifacts from the Apache
> servers - to do this the Dockerfile needs to know the exact path to the
> artifacts it's trying to download, of course.
> 
> There was a question recently in one of the Slack channels about whether
> both of these builds (dockerhub and dockermaven) were still valid/needed -
> I think Joe replied that he wasn't sure (Docker not being an area he
> ventures into much, which is fair enough). It may be worth considering
> whether these two modules are both still needed or can be rationalised and
> if the latter, which approach should be used - download from the archive
> server or build from local (both have dis/advantages, but the more
> "official" way is arguably to download from the server).
> 
> Also maybe worth noting:
> * NiFi Registry only has the "build from local" Dockerfile setup
> * MiniFi (Java) has both local and archive download options, but the latter
> cannot be used to build an image from the Dev server (the BASE_URL cannot
> be changed via a build arg/env var... this is the issue addressed by
> NIFI-8779 for NiFi)
> * NiFi Toolkit has both local and archive download options, but are located
> in a single assembly module (instead of split into two like NiFi and MiniFi)
> 
> Assuming the "nifi/" path will be used for the actual release
> artifacts, this shouldn't be a blocker, but it's one to note/remember when
> the time comes (assuming the "dockerhub" module is what's used to publish
> the "apache/nifi" image to Docker Hub that is).
> 
> 
> ---
> *Chris Sampson*
> IT Consultant
> chris.samp...@naimuri.com
> 
> 
> On Fri, 5 Nov 2021 at 03:34, David Handermann 
> wrote:
> 
>> Chris,
>> 
>> I am running through several verification steps, but I built 1.15.0 RC 3
>> from sources and then ran "mvn install -pl :dockermaven -P docker" to build
>> the Docker image.  When starting with the following command, I was able to
>> use the generated username and password to access the running NiFi
>> container:
>> 
>> docker run --name nifi -p 8443:8443 apache/nifi:1.15.0-dockermaven
>> 
>> If you are still having issues, it would be helpful to provide any logs or
>> error messages you are seeing.
>> 
>> Regards,
>> David Handermann
>> 
>> On Thu, Nov 4, 2021 at 8:10 PM Kevin Doran 
>> wrote:
>> 
>>> Oh meant to send a link to this too:
>>> 
>>>> ARG
>>> 
>> NIFI_BINARY_PATH=${NIFI_BINARY_PATH:-/nifi/${NIFI_VERSION}/nifi-${NIFI_VERSION}-bin.zip}
>>> 
>>> 
>>> 
>> https://github.com/apache/nifi/blob/373498445fe589e2d4855a0730fbb9127f0b4452/nifi-docker/dockerhub/Dockerfile#L30
>>> 
>>>> On Nov 4, 2021, at 9:09 PM, Kevin Doran 
>&

Re: [discuss] NiFi 1.15

[Kevin Doran]

Oh meant to send a link to this too:

> ARG 
> NIFI_BINARY_PATH=${NIFI_BINARY_PATH:-/nifi/${NIFI_VERSION}/nifi-${NIFI_VERSION}-bin.zip}

https://github.com/apache/nifi/blob/373498445fe589e2d4855a0730fbb9127f0b4452/nifi-docker/dockerhub/Dockerfile#L30

> On Nov 4, 2021, at 9:09 PM, Kevin Doran  wrote:
> 
> Hi Joe and Chris,
> 
> Our Dockerfile that we use to build the Dockerhub image defaults to looking 
> for 1.15.0 instead of NiFi-1.15.0, but it is a variable that we can override, 
> so this is easy to workaround incase the release folder does change. Agree 
> its nice to keep the tree structure consistent when we can.
> 
> I’m about to do my verification and will also check the single user with the 
> docker image as part of that.
> 
> Cheers,
> Kevin
> 
>> On Nov 4, 2021, at 6:44 PM, Joe Witt  wrote:
>> 
>> Chris,
>> 
>> Yeah I should have just put it in 1.15.0 instead of nifi/1.15.0.
>> Should generally not really matter so the docker angle there is
>> interesting.  Not sure why our docker images would have any
>> relationship to our dist/dev storage.  But when I move them into the
>> release folder I can try to ensure I place them only in 1.15.0 instead
>> of nifi/1.15.0.
>> 
>> That directory the prov stuff makes does linger and can be annoying so
>> thanks for tackling that.  Saw the PR.  Will take a look soon if
>> nobody else has.
>> 
>> Will keep an eye on your findings related to docker builds not working
>> with username/password things.  Hopefully others can chime in there.
>> 
>> Thanks
>> Send
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Thu, Nov 4, 2021 at 2:06 PM Chris Sampson
>>  wrote:
>>> 
>>> Worryingly, when I do get the Docker Image to build (further changes to the
>>> Dockerfile), the auto-generated username and password from the startup logs
>>> aren't being accepted for login via my browser.
>>> 
>>> I'll try to spend a little more time looking at this (but await input on my
>>> earlier question/concern also).
>>> 
>>> 
>>> ---
>>> *Chris Sampson*
>>> IT Consultant
>>> chris.samp...@naimuri.com
>>> 
>>> 
>>> On Thu, 4 Nov 2021 at 20:47, Chris Sampson 
>>> wrote:
>>> 
>>>> I've got most of the way through the release check process in order to
>>>> vote for 1.15.0, but I wanted to check on a change in the distribution
>>>> release artifacts.
>>>> 
>>>> For 1.14.0, the Dev artifacts were located at:
>>>> https://dist.apache.org/repos/dist/dev/nifi/1.14.0/*
>>>> For 1.15.0, the Dev artifacts are located at:
>>>> https://dist.apache.org/repos/dist/dev/nifi/nifi-1.15.0/*
>>>> 
>>>> i.e. there's been a change of directory/path from  to
>>>> nifi-.
>>>> 
>>>> The reason I raise this is that I can no longer build a Docker Image using
>>>> the dockerhub/DockerBuild.sh script because it cannot find the artifacts to
>>>> download. This may not be a problem if the path change is only for the Dev
>>>> artifacts, but if the same change is going to happen for the released
>>>> artifacts, then the apache/nifi image (and presumably the
>>>> apache/nifi-registry, apache/nifi-toolkit and any minifi) convenience
>>>> images will no longer be possible as part of the Release, which will likely
>>>> be an issue for a number of users that have deployments using these images.
>>>> 
>>>> I spotted this after rebasing my outstanding PR [1] for NIFI-8779 [2]
>>>> 
>>>> 
>>>> Additionally, I noted NIFI-9366 [3] after an unwanted directory was
>>>> created by the unit tests executed during building and testing 1.15.0-RC3.
>>>> I raised a PR [4] - this is a minor issue and not a reason to block any
>>>> release.
>>>> 
>>>> 
>>>> 
>>>> [1] https://github.com/apache/nifi/pull/5213
>>>> [2] https://issues.apache.org/jira/browse/NIFI-8779
>>>> 
>>>> [3] https://issues.apache.org/jira/browse/NIFI-9366
>>>> [4] https://github.com/apache/nifi/pull/5510
>>>> 
>>>> ---
>>>> *Chris Sampson*
>>>> IT Consultant
>>>> chris.samp...@naimuri.com
>>>> 
>>>> 
>>>> On Sat, 30 Oct 2021 at 01:52, Joe Witt  wrote:
>>>> 
>>>>> Otto
>>>>> 
>>>>&

Re: [discuss] NiFi 1.15

[Kevin Doran]

Hi Joe and Chris,

Our Dockerfile that we use to build the Dockerhub image defaults to looking for 
1.15.0 instead of NiFi-1.15.0, but it is a variable that we can override, so 
this is easy to workaround incase the release folder does change. Agree its 
nice to keep the tree structure consistent when we can.

I’m about to do my verification and will also check the single user with the 
docker image as part of that.

Cheers,
Kevin

> On Nov 4, 2021, at 6:44 PM, Joe Witt  wrote:
> 
> Chris,
> 
> Yeah I should have just put it in 1.15.0 instead of nifi/1.15.0.
> Should generally not really matter so the docker angle there is
> interesting.  Not sure why our docker images would have any
> relationship to our dist/dev storage.  But when I move them into the
> release folder I can try to ensure I place them only in 1.15.0 instead
> of nifi/1.15.0.
> 
> That directory the prov stuff makes does linger and can be annoying so
> thanks for tackling that.  Saw the PR.  Will take a look soon if
> nobody else has.
> 
> Will keep an eye on your findings related to docker builds not working
> with username/password things.  Hopefully others can chime in there.
> 
> Thanks
> Send
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Thu, Nov 4, 2021 at 2:06 PM Chris Sampson
>  wrote:
>> 
>> Worryingly, when I do get the Docker Image to build (further changes to the
>> Dockerfile), the auto-generated username and password from the startup logs
>> aren't being accepted for login via my browser.
>> 
>> I'll try to spend a little more time looking at this (but await input on my
>> earlier question/concern also).
>> 
>> 
>> ---
>> *Chris Sampson*
>> IT Consultant
>> chris.samp...@naimuri.com
>> 
>> 
>> On Thu, 4 Nov 2021 at 20:47, Chris Sampson 
>> wrote:
>> 
>>> I've got most of the way through the release check process in order to
>>> vote for 1.15.0, but I wanted to check on a change in the distribution
>>> release artifacts.
>>> 
>>> For 1.14.0, the Dev artifacts were located at:
>>> https://dist.apache.org/repos/dist/dev/nifi/1.14.0/*
>>> For 1.15.0, the Dev artifacts are located at:
>>> https://dist.apache.org/repos/dist/dev/nifi/nifi-1.15.0/*
>>> 
>>> i.e. there's been a change of directory/path from  to
>>> nifi-.
>>> 
>>> The reason I raise this is that I can no longer build a Docker Image using
>>> the dockerhub/DockerBuild.sh script because it cannot find the artifacts to
>>> download. This may not be a problem if the path change is only for the Dev
>>> artifacts, but if the same change is going to happen for the released
>>> artifacts, then the apache/nifi image (and presumably the
>>> apache/nifi-registry, apache/nifi-toolkit and any minifi) convenience
>>> images will no longer be possible as part of the Release, which will likely
>>> be an issue for a number of users that have deployments using these images.
>>> 
>>> I spotted this after rebasing my outstanding PR [1] for NIFI-8779 [2]
>>> 
>>> 
>>> Additionally, I noted NIFI-9366 [3] after an unwanted directory was
>>> created by the unit tests executed during building and testing 1.15.0-RC3.
>>> I raised a PR [4] - this is a minor issue and not a reason to block any
>>> release.
>>> 
>>> 
>>> 
>>> [1] https://github.com/apache/nifi/pull/5213
>>> [2] https://issues.apache.org/jira/browse/NIFI-8779
>>> 
>>> [3] https://issues.apache.org/jira/browse/NIFI-9366
>>> [4] https://github.com/apache/nifi/pull/5510
>>> 
>>> ---
>>> *Chris Sampson*
>>> IT Consultant
>>> chris.samp...@naimuri.com
>>> 
>>> 
>>> On Sat, 30 Oct 2021 at 01:52, Joe Witt  wrote:
>>> 
 Otto
 
 Got ya.  Yeah it was this way in 1.14 as well.  And to be clear with every
 release what we are actually voting upon is the source release.  Now the
 source release includes nifi, minifi, nifi registry, stateless nifi and
 toolkits among all the other having always been there goodies.
 
 Some of these things we make available in the form of convenience binaries
 to make it easier on folks to consume.
 
 I think you dont need to do any verification you would not have done
 before.
 
 But I do hope folks help maintain various ways of easing more folks
 knowing
 what to vet with a given release
 
 On Fri, Oct 29, 2021 at 5:34 PM Otto Fowler 
 wrote:
 
> This release, we are verifying not only Nifi, but also Minifi Java. At
> least that is my understanding.
> 
> This would be my first time having *anything* to do with minifi, i’ve
 not
> even run it before.
> 
> As such, I think the RC validation guide needs to be update to include
 the
> information about now validating nifi and minifi together.
> 
> 
> 
> 
> From: Joe Witt  
> Reply: dev@nifi.apache.org  
> Date: October 25, 2021 at 11:59:39
> To: dev@nifi.apache.org  
> Subject:  [discuss] NiFi 1.15
> 
> Team,
> 
> I thought I had already started such a thread but I dont see it so here
> goes...
> 
>

Re: Minifi Docker Image

[Kevin Doran]

To Daniel and everyone on the thread - 

Thanks for bringing this to our attention. I have updated the 
apache/nifi-minifi-cpp images on Docker Hub [1] to add the latest version, 
which you can now fetch using:

docker pull apache/nifi-minifi-cpp:latest
docker pull apache/nifi-minifi-cpp:0.10.0

[1] https://hub.docker.com/repository/docker/apache/nifi-minifi-cpp 
<https://hub.docker.com/repository/docker/apache/nifi-minifi-cpp> 

Cheers,
Kevin

> On Oct 19, 2021, at 10:32, Kevin Doran  wrote:
> 
> Hi all,
> 
> I was also not aware we had been publishing docker images for nifi-minifi-cpp 
> to Docker Hub. I can update the those image repositories to have the latest, 
> and I will help document the process on our wiki that is used so that others 
> can follow it in the future as part of a normal release.
> 
> Cheers,
> Kevin
> 
>> On Oct 11, 2021, at 12:10 PM, Marton Szasz  wrote:
>> 
>> Hi,
>> 
>> For MiNiFi C++, I think it was simply forgotten since 0.7.0 and not
>> documented. At least since 0.9.0, we're following the release guide on
>> the confluence wiki. [1]
>> I'm not too familiar with docker-related processes, but added a stub
>> point to the guide in the finalize section. If someone knows the
>> workflow and could contribute it to the guide, that would be awesome
>> and would ensure that a docker image is published with every new
>> release.
>> 
>> Thanks,
>> Marton
>> 
>> [1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=70254849
>> 
>> On Mon, 11 Oct 2021 at 15:48, Pierre Villard
>>  wrote:
>>> 
>>> Hi Daniel, the images are available here:
>>> https://hub.docker.com/r/apache/nifi-minifi (MiNiFi Java)
>>> https://hub.docker.com/r/apache/nifi-minifi-cpp (MiNiFi C++)
>>> 
>>> MiNiFi Java has not been updated in a while because we merged the MiNiFi
>>> Java code into NiFi and it's now a NiFi headless version. I believe the
>>> existing image could be used or a dedicated one could be created for
>>> headless.
>>> 
>>> For MiNiFi C++, not sure why the latest versions have not been published.
>>> Someone here may know the answer.
>>> 
>>> Thanks,
>>> Pierre
>>> 
>>> Le lun. 11 oct. 2021 à 17:37, Daniel Beicht  a
>>> écrit :
>>> 
>>>> Hello,
>>>> 
>>>> since I couldn't find the Minifi Docker Image on Docker Hub I wanted to
>>>> ask why it is not available and if you plan to do so.
>>>> 
>>>> Best regards,
>>>> Daniel Beicht
>>>> 
> 

Re: Minifi Docker Image

[Kevin Doran]

Hi all,

I was also not aware we had been publishing docker images for nifi-minifi-cpp 
to Docker Hub. I can update the those image repositories to have the latest, 
and I will help document the process on our wiki that is used so that others 
can follow it in the future as part of a normal release.

Cheers,
Kevin

> On Oct 11, 2021, at 12:10 PM, Marton Szasz  wrote:
> 
> Hi,
> 
> For MiNiFi C++, I think it was simply forgotten since 0.7.0 and not
> documented. At least since 0.9.0, we're following the release guide on
> the confluence wiki. [1]
> I'm not too familiar with docker-related processes, but added a stub
> point to the guide in the finalize section. If someone knows the
> workflow and could contribute it to the guide, that would be awesome
> and would ensure that a docker image is published with every new
> release.
> 
> Thanks,
> Marton
> 
> [1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=70254849
> 
> On Mon, 11 Oct 2021 at 15:48, Pierre Villard
>  wrote:
>> 
>> Hi Daniel, the images are available here:
>> https://hub.docker.com/r/apache/nifi-minifi (MiNiFi Java)
>> https://hub.docker.com/r/apache/nifi-minifi-cpp (MiNiFi C++)
>> 
>> MiNiFi Java has not been updated in a while because we merged the MiNiFi
>> Java code into NiFi and it's now a NiFi headless version. I believe the
>> existing image could be used or a dedicated one could be created for
>> headless.
>> 
>> For MiNiFi C++, not sure why the latest versions have not been published.
>> Someone here may know the answer.
>> 
>> Thanks,
>> Pierre
>> 
>> Le lun. 11 oct. 2021 à 17:37, Daniel Beicht  a
>> écrit :
>> 
>>> Hello,
>>> 
>>> since I couldn't find the Minifi Docker Image on Docker Hub I wanted to
>>> ask why it is not available and if you plan to do so.
>>> 
>>> Best regards,
>>> Daniel Beicht
>>> 

Re: Jira Contributor Access Request

[Kevin Doran]

Hi Mikayla,

You should have access to the NiFi Jira projects now. Let me know if you need 
anything else, and welcome to the project!

Cheers,
Kevin

> On Sep 27, 2021, at 14:29, Mengke Yang  wrote:
> 
> Hello,
> 
> I'm new to the NiFi project and my username is *mikayla.yang*. I would love
> to request Jira contributor access so that I can contribute. If you receive
> a previous email from my other email address, please ignore it and I prefer
> use this email address instead.
> 
> Thank you!
> 
> Best,
> Mikayla

Re: [ANNOUNCE] New NiFi PMC Member David Handermann

[Kevin Doran]

Congratulations, David!

> On Sep 17, 2021, at 10:09, Joe Gresock  wrote:
> 
> Congrats, David!
> 
> On Fri, Sep 17, 2021 at 9:57 AM Marton Szasz  wrote:
> 
>> Congratulations David!
>> 
>> On Fri, 17 Sept 2021 at 13:07, Chris Sampson
>>  wrote:
>>> 
>>> Congrats David, very well deserved!
>>> 
>>> 
>>> On Fri, 17 Sept 2021 at 13:56, Bryan Bende  wrote:
>>> 
 NiFi Community,
 
 On behalf of the Apache NiFI PMC, I am very pleased to announce that
 David Handermann has accepted the PMC's invitation to join the Apache
 NiFi PMC.
 
 David has made significant improvements in a number of security
 related areas, he continues to improve the stability of our tests and
 CI builds, and regularly helps out the community through the mailing
 lists, Slack, and PR reviews.
 
 Please join us in congratulating and welcoming David to the Apache NiFi
 PMC.
 
 Congratulations David!
 
>> 

Re: Flood of JIRAs and presumably PRs to follow for junit-5 migration?

[Kevin Doran]

Hi all,

JUnit 5 certainly contains a number of benefits, so I’m glad to see some 
interest and effort around it. 

As long as we are taking the time to update tests in each module and line up 
reviewers for these bulk refactoring, I agree with David that we should make 
improvements aside from just JUnit 4 to 5 syntax/compatibility migrations. This 
is a good opportunity to bring consistency and improvements to our tests.

Just an idea, but maybe it would be a good idea to start a list of 
anti-patterns and code smell in existing tests. This could be maintained on the 
wiki or similar, and any PRs opened as part of this effort can address those 
issues in addition to upgrading to JUnit 5. Here are examples of things I would 
include:

Don’t:
- Leave dead/commented code in test classes
- @Ignored tests
- Using try/catch with fail() to expect exceptions
- Use thread.sleep() or other unreliable methods for asynchronous logic 
assertions

Do:
- Use granular unit tests
- Use arrange/act/assert or given/when/then pattern where possible
- Use assertThrows() to check for expected exceptions
- Use libraries such as AssertJ or Awaitility to write clear, concise, reliable 
tests.
- Use Spock where possible (Just joking! I know this is a heated issue. But 
also, do use it! 😂)

Thanks!
Kevin


> On Aug 25, 2021, at 4:01 PM, David Handermann  
> wrote:
> 
> Mike,
> 
> Thanks for moving things forward on the JUnit 5 migration. I posted a
> couple comments on the PR for nifi-commons (NIFI-9080) with concerns
> related to breaking tests and perpetuating ignored unit tests.
> 
> Summarizing in this thread for general discussion, I am concerned about
> breaking unit tests as part of the migration process. As long as NiFi
> supports both JUnit 4 and JUnit 5, the migration should improve the overall
> testing environment. Breaking existing tests will require additional work
> to go back and fix, and spending the effort upgrading and reviewing test
> classes doesn't seem worth it if we continue marking tests as ignored.  In
> some particular cases, it may be worthwhile to remove a test method or test
> class. For test methods related to performance, migrating to JUnit 5 seems
> like an ideal opportunity to make tests conditional on environment
> variables or system properties.  I would be glad to help with the migration
> process, but it would be helpful to avoid having to revisit code multiple
> times to address these issues.
> 
> Regards,
> David Handermann
> 
> On Wed, Aug 25, 2021 at 2:24 PM Mike Thomsen  wrote:
> 
>> I broke up the tickets because it is A LOT of individual tasks that
>> can break the overall build and wanted to scope the work appropriately
>> so that people looking for a chance to contribute could snatch up a
>> few easy wins.
>> 
>> I'm still going to take point on making the changes, but the plan
>> going forward is to submit PRs that bundle a bunch of tickets so that
>> we don't overwhelm reviewers and the CI/CD pipeline.
>> 
>> Most of the changes are automated by IntelliJ Ultimate's migration
>> tool, which from my testing is really good at migrating about 95% of
>> our JUnit 4 unit and integration tests.
>> 
>> Thanks,
>> 
>> Mike
>> 
>> On Wed, Aug 25, 2021 at 1:05 PM Joe Witt  wrote:
>>> 
>>> Joey
>>> 
>>> I personally dont care all that much about the number of commits in PR
>>> - I think that rule is sort of soft already.
>>> 
>>> I dont think there is any inherent value in having a single module per
>>> JIRA (and PR or PR commit) on this.  These can be done in much coarser
>>> grained chunks.  It will have to be to get review cycles for instance
>>> (much less having the Github infra to run these builds).
>>> 
>>> Thanks
>>> Joe
>>> 
>>> On Wed, Aug 25, 2021 at 9:44 AM Joey Frazee
>>>  wrote:
 
 Maybe this is an exception to the single squashed commit guidance for
>> the initial pull?
 
 I assume the intent is to make incremental progress and not have a PR
>> with a hundred files affected, but if the different module changes
>> corresponded to a different commit, GH will make it easy enough to have a
>> draft and review each commit in isolation.
 
 Would that be a reasonable approach?
 
 -joey
 
> On Aug 25, 2021, at 9:36 AM, Joe Witt  wrote:
> 
> Mike,
> 
> Seeing a pretty stunning flood of JIRAs for 'Refactor nifi-bla to use
> JUnit 5' and I'm guessing we'll see the same in terms of PRs.  This
>> is
> a really high administrative overhead approach to this.
> 
> Why not break this into one or maybe a few JIRAs/PRs total?
> 
> Thanks
>> 

Re: [DISCUSS] NiFi 2.0 Release Goals

[Kevin Doran]

Outside of core NiFi, for MiNiFi, I think it would be beneficial to align 
MiNiFi Java and MiNiFI C++ to use the same method(s) for command and control / 
flow deployment. This was discussed when MiNiFi Java was merged into the NiFi 
codebase [1].

My proposal would be to create a Java implementation of the C2 Protocol used by 
MiNiFi C++, both server-side and client-side, to allow deploying to MiNiFi Java 
instances from a centralize flow definition. Thanks to the unification of 
MiNiFi Java and NiFi, this could likely also be added as a capability of NiFi 
at that same time.

If we are able to do this on the 1.x line, then I would also support 
deprecating other methods of flow deployment to MiNiFi outlined in [1] and 
removing them in a 2.x release.

[1] https://github.com/apache/nifi/pull/4933#issuecomment-808411977 

[2] https://cwiki.apache.org/confluence/display/MINIFI/C2+Design 
 

Thanks,
Kevin

> On Aug 3, 2021, at 10:07 AM, David Handermann  
> wrote:
> 
> Thanks for the continued discussion around what can or should be removed.
> Having a clear migration path from version 1 to version 2 will be very
> important for supporting current deployments.
> 
> Following the example of some other projects, one way to consider the
> upgrade is from the point of view of deprecation warnings. If implemented
> correctly, an installation of NiFi running the latest minor release of
> version 1, and showing no deprecation warnings, should be upgradeable to
> version 2 without any changes. Making this work involves accurately tagging
> components and methods with deprecation indicators, and providing a clear
> way to observe deprecation warnings. With the current version containing
> both deprecated components and deprecated methods in various classes, this
> would involve some work to get right. A simple approach might be a named
> logger for deprecation warnings, which would write a separate log file. A
> more advanced approach might involve a tool to analyze the system and flow
> configurations. Either way, it seems that some additional work in a minor
> release version is necessary before considering a major release version.
> 
> One other point on compatibility: as long as the core component API
> definition remains backwards compatible, it should be possible to run older
> components. This provides a transition option for customers using
> components such as PostHTTP, or any others that are not actively
> maintained. At some point it may become necessary to break compatibility at
> that level, but at least for version 2, maintaining component API
> compatibility is key.
> 
> Regards,
> David Handermann
> 
> On Sun, Aug 1, 2021 at 10:23 AM Mark Bean  wrote:
> 
>> I created a JIRA ticket to investigate and improve the performance of
>> InvokeHTTP. It includes a flow definition for benchmarking the performance
>> of both PostHTTP and InvokeHTTP.
>> 
>> https://issues.apache.org/jira/browse/NIFI-8968
>> 
>> Thanks,
>> Mark
>> 
>> On Fri, Jul 30, 2021 at 6:41 PM Adam Taft  wrote:
>> 
>>> I'm not seeing the side thread that was going to discuss deprecation of
>>> PostHTTP.  Has that thread started and I just don't see it?
>>> 
>>> One (significant?) concern with PostHTTP is the smooth integration of
>>> NiFi-to-NiFi communication that is very transparently enabled with the
>>> ListenHTTP and PostHTTP processors. There's some special logic in there
>> for
>>> handling flowfiles that InvokeHTTP doesn't really (nor should really)
>> have.
>>> 
>>> I know of several (large) NiFi installations that rely on the PostHTTP /
>>> ListenHTTP combination. It has enabled NiFi to NiFi communication for
>> folks
>>> reluctant or unable to enable site-to-site type configuration.
>>> 
>>> Honestly, I don't know why we'd want to "deprecate" any processor, as
>>> opposed to just moving it to a new location. If these processors can be
>>> ported and maintained to whatever the 2.0 API looks like, there's
>> possibly
>>> little harm keeping them around.
>>> 
>>> And by the way, what happened to the "marketplace" concept? Is this being
>>> considered for 2.0 as well?  Because relocating the deprecated processors
>>> to an external nar might be the best solution. Losing PostHTTP entirely I
>>> think would be a mistake, but I'd conceptually support relocating it.
>>> 
>>> Thanks,
>>> 
>>> /Adam
>>> 
>>> On Tue, Jul 27, 2021 at 2:11 PM Joe Witt  wrote:
>>> 
 Looks like we just need to knock out 5 JIRAs :) [1]
 
 I felt like we had a label folks were using at one point but quickly
 looking revealed nothing exciting.  After this confluence page
 stabilizes a bit we can probably knock out some JIRAs and such.
 
 [1] https://issues.apache.org/jira/projects/NIFI/versions/12339599
 
 On Tue, Jul 27, 2021 at 1:06 PM Otto Fowler 
 wrote:
> 
> I find myself wishing I had a l

Re: [DISCUSS] NiFi Registry -> NiFi consensus

[Kevin Doran]

+1.

> On Jul 16, 2021, at 2:28 PM, Joe Witt  wrote:
> 
> Yep definitely. Thought this was sorted via the JIRA.
> 
> +1
> 
> On Fri, Jul 16, 2021 at 11:26 AM David Handermann
>  wrote:
>> 
>> Thanks for handling this, Matt. As one of the reviewers on the PR, I vote
>> +1 (non-binding).
>> 
>> Regards,
>> David Handermann
>> 
>> On Fri, Jul 16, 2021 at 1:20 PM Matt Burgess  wrote:
>> 
>>> All,
>>> 
>>> We've been asked to record our consensus for the move of NiFi Registry
>>> to the NiFi codebase in a mailing list thread for posterity. Most
>>> discussion happened on the PR but INFRA would like a link to this
>>> thread showing consensus from PMC members, committers, and the
>>> community.
>>> 
>>> I didn't put my +1 on the PR but I am in favor of moving the NiFi
>>> Registry codebase into NiFi :) Please feel free to share your thoughts
>>> as well.
>>> 
>>> Thank you,
>>> Matt
>>> 

Re: wget during build

[Kevin Doran]

I just compared the contents of the swagger UI tarball from GitHub artifacts 
and the jar from maven central, and they definitely look like they both contain 
the same files we are rebuilding in NiFi Registry, so I have opened a ticket to 
migrate from using the download-maven-plugin pulling from GitHub artifacts to 
use the maven artifact:

https://issues.apache.org/jira/browse/NIFIREG-456 
<https://issues.apache.org/jira/browse/NIFIREG-456>

Thanks again, Mark!

> On Jul 16, 2021, at 10:15 AM, Kevin Doran  wrote:
> 
> Good find! At a glance, I think this maven jar could work as a replacement. 
> I’ll look into it.
> 
> Regarding how we use the Swagger UI. When included, the NiFi Registry web 
> server hosts the Swagger UI in addition to the Registry web app and REST API.
> 
> I believe it is hosted at 
> http(s)://:/nifi-registry-api/swagger/ui.html
> 
> The Swagger UI is an alternative to the REST API documentation that is also 
> included in the Registry self-hosted docs (or here [1]). One of the main 
> benefits of the Swagger UI, is that in addition to documenting usage of the 
> REST API, it offers interactivity. If you’ve never seen Swagger UI before, 
> can see a demo of it here [2]. It is completely data driven by a swagger.json 
> spec, so in Registry it dynamically generates our REST API endpoints.
> 
> [1] https://nifi.apache.org/docs/nifi-registry-docs/index.html
> [2] https://petstore.swagger.io/ 
> 
>> On Jul 16, 2021, at 8:49 AM, Mark Bean  wrote:
>> 
>> Thanks for laying out some clear options Kevin.
>> 
>> I haven't dug into the inner workings of this component, and don't yet
>> understand why a tarball is necessary. I looked at your first option. While
>> I didn't find a tarball, there does appear to be org.webjars.swagger-ui
>> JAR component in common maven repositories. I'm not sure if this is
>> applicable - or could be made to be applicable.
>> 
>> https://mvnrepository.com/artifact/org.webjars/swagger-ui
>> https://search.maven.org/artifact/org.webjars/swagger-ui
>> 
>> As a more general question, can you explain what option uses the Swagger
>> UI? What feature or capability is not available without this component
>> being available at build time?
>> 
>> Thanks,
>> Mark
>> 
>> On Thu, Jul 15, 2021 at 4:52 PM Kevin Doran  wrote:
>> 
>>> It’s certainly worth discussing. The binary in question is ~6MB, which
>>> while not huge, if changed over time (to pull in new versions) could lead
>>> to undesirable repository sizes. It's also debatable that it is “necessary”
>>> as the bundled Swagger UI is an optional piece of NiFi Registry, which
>>> itself is an optional component. Still we could handle it more gracefully.
>>> 
>>> Options I can think of:
>>> - See if there is an alternative Nexus / maven repository location, that
>>> hosts the Swagger UI in a Jar format or something we could use as a Maven
>>> dependency.
>>> - Include the tarball in the source repo as Mark suggested
>>> - Add an option to provide the swagger tarball as a local file, eg build
>>> property to location
>>> - Do what we do now, but detect if the tarball is not reachable via the
>>> network and gracefully continue the build without that piece
>>> 
>>>> On Jul 15, 2021, at 3:23 PM, Mark Bean  wrote:
>>>> 
>>>> Thanks. That profile is what I needed to get beyond that point. (I ran
>>> into
>>>> other dependency issues I still need to resolve, so I don't yet have a
>>>> complete build to test.)
>>>> 
>>>> A more general question: should the wget functionality really be part of
>>> a
>>>> build? It seems to me that if a necessary component or dependency can't
>>> be
>>>> obtained from the user-configured maven repository, then that resource
>>>> should be included in the source for the project. Comments?
>>>> 
>>>> Thanks,
>>>> Mark
>>>> 
>>>> On Thu, Jul 15, 2021 at 2:11 PM Kevin Doran 
>>> wrote:
>>>> 
>>>>> Hi Mark,
>>>>> 
>>>>> I’m not sure the two errors are related, but for the first one you can
>>>>> pass -Pno-swagger-ui to mvn when building:
>>>>> 
>>>>> See:
>>>>> 
>>> https://github.com/apache/nifi/blob/main/nifi-registry/nifi-registry-core/nifi-registry-web-api/pom.xml#L136
>>>>> <
>>>>> 
>>> https://github.com/apache/nifi/blob/main/nifi-registry/nifi

Re: wget during build

[Kevin Doran]

Good find! At a glance, I think this maven jar could work as a replacement. 
I’ll look into it.

Regarding how we use the Swagger UI. When included, the NiFi Registry web 
server hosts the Swagger UI in addition to the Registry web app and REST API.

I believe it is hosted at 
http(s)://:/nifi-registry-api/swagger/ui.html

The Swagger UI is an alternative to the REST API documentation that is also 
included in the Registry self-hosted docs (or here [1]). One of the main 
benefits of the Swagger UI, is that in addition to documenting usage of the 
REST API, it offers interactivity. If you’ve never seen Swagger UI before, can 
see a demo of it here [2]. It is completely data driven by a swagger.json spec, 
so in Registry it dynamically generates our REST API endpoints.

[1] https://nifi.apache.org/docs/nifi-registry-docs/index.html
[2] https://petstore.swagger.io/ 

> On Jul 16, 2021, at 8:49 AM, Mark Bean  wrote:
> 
> Thanks for laying out some clear options Kevin.
> 
> I haven't dug into the inner workings of this component, and don't yet
> understand why a tarball is necessary. I looked at your first option. While
> I didn't find a tarball, there does appear to be org.webjars.swagger-ui
> JAR component in common maven repositories. I'm not sure if this is
> applicable - or could be made to be applicable.
> 
> https://mvnrepository.com/artifact/org.webjars/swagger-ui
> https://search.maven.org/artifact/org.webjars/swagger-ui
> 
> As a more general question, can you explain what option uses the Swagger
> UI? What feature or capability is not available without this component
> being available at build time?
> 
> Thanks,
> Mark
> 
> On Thu, Jul 15, 2021 at 4:52 PM Kevin Doran  wrote:
> 
>> It’s certainly worth discussing. The binary in question is ~6MB, which
>> while not huge, if changed over time (to pull in new versions) could lead
>> to undesirable repository sizes. It's also debatable that it is “necessary”
>> as the bundled Swagger UI is an optional piece of NiFi Registry, which
>> itself is an optional component. Still we could handle it more gracefully.
>> 
>> Options I can think of:
>> - See if there is an alternative Nexus / maven repository location, that
>> hosts the Swagger UI in a Jar format or something we could use as a Maven
>> dependency.
>> - Include the tarball in the source repo as Mark suggested
>> - Add an option to provide the swagger tarball as a local file, eg build
>> property to location
>> - Do what we do now, but detect if the tarball is not reachable via the
>> network and gracefully continue the build without that piece
>> 
>>> On Jul 15, 2021, at 3:23 PM, Mark Bean  wrote:
>>> 
>>> Thanks. That profile is what I needed to get beyond that point. (I ran
>> into
>>> other dependency issues I still need to resolve, so I don't yet have a
>>> complete build to test.)
>>> 
>>> A more general question: should the wget functionality really be part of
>> a
>>> build? It seems to me that if a necessary component or dependency can't
>> be
>>> obtained from the user-configured maven repository, then that resource
>>> should be included in the source for the project. Comments?
>>> 
>>> Thanks,
>>> Mark
>>> 
>>> On Thu, Jul 15, 2021 at 2:11 PM Kevin Doran 
>> wrote:
>>> 
>>>> Hi Mark,
>>>> 
>>>> I’m not sure the two errors are related, but for the first one you can
>>>> pass -Pno-swagger-ui to mvn when building:
>>>> 
>>>> See:
>>>> 
>> https://github.com/apache/nifi/blob/main/nifi-registry/nifi-registry-core/nifi-registry-web-api/pom.xml#L136
>>>> <
>>>> 
>> https://github.com/apache/nifi/blob/main/nifi-registry/nifi-registry-core/nifi-registry-web-api/pom.xml#L136
>>>>> 
>>>> 
>>>> Kevin
>>>> 
>>>>> On Jul 15, 2021, at 1:54 PM, Mark Bean  wrote:
>>>>> 
>>>>> I'm trying to build rel/nifi-1.14.0 on a private, non-Internet
>> connected
>>>>> network. The nifi-registry portion is failing.
>>>>> 
>>>>> [ERROR] Failed to execute goal
>>>>> com.googlecode.maven-download-plugin:download-maven-plugin:1.2.1:wget
>>>>> (download-swagger-ui) on project nifi-registry-web-api: IO Error: Error
>>>>> while
>>>>> expalnding
>>>> 
>> ~/nifi/nifi-registry/nifi-registry-core/nifi-registry-web-api/target/v3.12.0.tar.gz:
>>>>> Not in GZIP format
>>>>> [ERROR] Failed to execute goal
>>>>> com.github.eirslett:frontend-maven-plugin:1.5:npm (npm-install) on
>>>> project
>>>>> nifi-registry-web-ui: Failed to run task: 'npm --silent ci' failed.
>>>>> org.apache.commons.exec.ExecuteException: Process exited with an
>> error: 1
>>>>> (Exit value: 1)
>>>>> 
>>>>> The two errors may be related (?) Either way, it appears to me that the
>>>>> build is attempting to use wget to reach out to an Internet location to
>>>>> download the v3.12.0.tar.gz.
>>>>> 
>>>>> Can someone confirm that is the problem? Is there a way around this?
>> Can
>>>>> this file be provided from a reachable/local source location?
>>>>> 
>>>>> Thanks,
>>>>> Mark
>>>> 
>>>> 
>> 
>> 

Re: wget during build

[Kevin Doran]

It’s certainly worth discussing. The binary in question is ~6MB, which while 
not huge, if changed over time (to pull in new versions) could lead to 
undesirable repository sizes. It's also debatable that it is “necessary” as the 
bundled Swagger UI is an optional piece of NiFi Registry, which itself is an 
optional component. Still we could handle it more gracefully.

Options I can think of:
- See if there is an alternative Nexus / maven repository location, that hosts 
the Swagger UI in a Jar format or something we could use as a Maven dependency.
- Include the tarball in the source repo as Mark suggested
- Add an option to provide the swagger tarball as a local file, eg build 
property to location
- Do what we do now, but detect if the tarball is not reachable via the network 
and gracefully continue the build without that piece

> On Jul 15, 2021, at 3:23 PM, Mark Bean  wrote:
> 
> Thanks. That profile is what I needed to get beyond that point. (I ran into
> other dependency issues I still need to resolve, so I don't yet have a
> complete build to test.)
> 
> A more general question: should the wget functionality really be part of a
> build? It seems to me that if a necessary component or dependency can't be
> obtained from the user-configured maven repository, then that resource
> should be included in the source for the project. Comments?
> 
> Thanks,
> Mark
> 
> On Thu, Jul 15, 2021 at 2:11 PM Kevin Doran  wrote:
> 
>> Hi Mark,
>> 
>> I’m not sure the two errors are related, but for the first one you can
>> pass -Pno-swagger-ui to mvn when building:
>> 
>> See:
>> https://github.com/apache/nifi/blob/main/nifi-registry/nifi-registry-core/nifi-registry-web-api/pom.xml#L136
>> <
>> https://github.com/apache/nifi/blob/main/nifi-registry/nifi-registry-core/nifi-registry-web-api/pom.xml#L136
>>> 
>> 
>> Kevin
>> 
>>> On Jul 15, 2021, at 1:54 PM, Mark Bean  wrote:
>>> 
>>> I'm trying to build rel/nifi-1.14.0 on a private, non-Internet connected
>>> network. The nifi-registry portion is failing.
>>> 
>>> [ERROR] Failed to execute goal
>>> com.googlecode.maven-download-plugin:download-maven-plugin:1.2.1:wget
>>> (download-swagger-ui) on project nifi-registry-web-api: IO Error: Error
>>> while
>>> expalnding
>> ~/nifi/nifi-registry/nifi-registry-core/nifi-registry-web-api/target/v3.12.0.tar.gz:
>>> Not in GZIP format
>>> [ERROR] Failed to execute goal
>>> com.github.eirslett:frontend-maven-plugin:1.5:npm (npm-install) on
>> project
>>> nifi-registry-web-ui: Failed to run task: 'npm --silent ci' failed.
>>> org.apache.commons.exec.ExecuteException: Process exited with an error: 1
>>> (Exit value: 1)
>>> 
>>> The two errors may be related (?) Either way, it appears to me that the
>>> build is attempting to use wget to reach out to an Internet location to
>>> download the v3.12.0.tar.gz.
>>> 
>>> Can someone confirm that is the problem? Is there a way around this? Can
>>> this file be provided from a reachable/local source location?
>>> 
>>> Thanks,
>>> Mark
>> 
>> 

Re: wget during build

[Kevin Doran]

Hi Mark,

I’m not sure the two errors are related, but for the first one you can pass 
-Pno-swagger-ui to mvn when building:

See: 
https://github.com/apache/nifi/blob/main/nifi-registry/nifi-registry-core/nifi-registry-web-api/pom.xml#L136
 


Kevin

> On Jul 15, 2021, at 1:54 PM, Mark Bean  wrote:
> 
> I'm trying to build rel/nifi-1.14.0 on a private, non-Internet connected
> network. The nifi-registry portion is failing.
> 
> [ERROR] Failed to execute goal
> com.googlecode.maven-download-plugin:download-maven-plugin:1.2.1:wget
> (download-swagger-ui) on project nifi-registry-web-api: IO Error: Error
> while
> expalnding 
> ~/nifi/nifi-registry/nifi-registry-core/nifi-registry-web-api/target/v3.12.0.tar.gz:
> Not in GZIP format
> [ERROR] Failed to execute goal
> com.github.eirslett:frontend-maven-plugin:1.5:npm (npm-install) on project
> nifi-registry-web-ui: Failed to run task: 'npm --silent ci' failed.
> org.apache.commons.exec.ExecuteException: Process exited with an error: 1
> (Exit value: 1)
> 
> The two errors may be related (?) Either way, it appears to me that the
> build is attempting to use wget to reach out to an Internet location to
> download the v3.12.0.tar.gz.
> 
> Can someone confirm that is the problem? Is there a way around this? Can
> this file be provided from a reachable/local source location?
> 
> Thanks,
> Mark

Re: [ANNOUNCE] New Apache NiFi Committer Denes Arvay

[Kevin Doran]

Congrats, Denes! Well deserved.

> On Jun 25, 2021, at 07:19, Chris Sampson  
> wrote:
> 
> Congrats, look forward to your continued contributions!
> 
> ---
> *Chris Sampson*
> IT Consultant
> chris.samp...@naimuri.com
> 
> 
> 
> On Fri, 25 Jun 2021 at 11:41, Pierre Villard 
> wrote:
> 
>> Congrats!
>> 
>> Le ven. 25 juin 2021 à 00:23, Joe Witt  a écrit :
>> 
>>> Well done Denes!
>>> 
>>> On Thu, Jun 24, 2021 at 3:09 PM Otto Fowler 
>>> wrote:
>>> 
 Congratulations!
 
 
 
 
 From: Arpad Boda  
 Reply: dev@nifi.apache.org  
 Date: June 24, 2021 at 15:01:09
 To: NiFi Developers List  
 Subject:  [ANNOUNCE] New Apache NiFi Committer Denes Arvay
 
 On behalf of the Apache NiFI PMC, I am very pleased to announce that
 Denes has accepted the PMC's invitation to become a committer on the
 Apache NiFi project. We greatly appreciate all of Denes' hard work and
 generous contributions to the project and look forward to the
 continued involvement.
 
 Welcome and congratulations!
 
>>> 
>> 

Re: [ANNOUNCE] New NiFi PMC Member Marton Szasz

[Kevin Doran]

Well done, Marton!

> On Jun 25, 2021, at 07:20, Chris Sampson  
> wrote:
> 
> Congrats, well deserved!
> 
> 
> ---
> *Chris Sampson*
> IT Consultant
> chris.samp...@naimuri.com
> 
> 
> 
> On Fri, 25 Jun 2021 at 11:42, Pierre Villard 
> wrote:
> 
>> Congrats Marton!
>> 
>> Le ven. 25 juin 2021 à 01:56, Tony Kurc  a écrit :
>> 
>>> congratulations!
>>> 
>>> On Thu, Jun 24, 2021 at 6:23 PM Joe Witt  wrote:
>>> 
 Congrats and thanks Marton
 
 On Thu, Jun 24, 2021 at 3:10 PM Otto Fowler 
 wrote:
 
> Congratulations!
> 
> 
> 
> 
> From: Arpad Boda  
> Reply: dev@nifi.apache.org  <
>> dev@nifi.apache.org>
> Date: June 24, 2021 at 15:01:31
> To: NiFi Developers List  
> Subject:  [ANNOUNCE] New NiFi PMC Member Marton Szasz
> 
> On behalf of the Apache NiFI PMC, I am very pleased to announce that
 Marton
> has accepted the PMC's invitation to join the Apache NiFi PMC. We
>>> greatly
> appreciate the PR reviews and code contributions of Marton.
> 
> Please join us in congratulating and welcoming Marton to the Apache
>>> NiFi
> PMC.
> 
> Congratulations Marton!
> 
 
>>> 
>> 

Re: Request for review - NIFI-5573

[Kevin Doran]

Hi Lars,

Thanks for the contribution! This is an area I should be able to help out in. I 
will take a look at your PR sometime in the next couple days and collaborate 
directly with you over on GitHub.

Cheers,
Kevin

> On Jun 16, 2021, at 10:56, Lars Francke  wrote:
> 
> Hi everyone,
> 
> I've opened a PR for NIFI-5573[1] in 2018 and never had time to incorporate
> review feedback (it's tiny). I actually closed it earlier this year but it
> turns out I still want the change so I just brought it up to date.
> 
> If anyone has time to look at my Pull Request that'd be greatly
> appreciated: 
> 
> It fixes a long-standing issue that makes it harder than necessary to build
> Docker images for NiFi
> 
> Thank you!
> 
> Cheers,
> Lars
> 
> [1] 

Re: [VOTE] Release Apache NiFi MiNiFi C++ (RC2)

[Kevin Doran]

+1 (binding)

verified sig / hashes
built using docker makefile targets and verified resulting images

Nice work all! Thank you for RM’ing Ferenc.

> On Jun 10, 2021, at 13:20, Tony Kurc  wrote:
> 
> +1 (binding)
> 
> Went through the release helper, verified signatures and hashes, reviewed
> NOTICE and LICENSE, and built without issues on Amazon Linux 2. Qualifier
> on my +1 vote - I only tested the build with simple a very simple flow.
> 
> 
> On Mon, Jun 7, 2021 at 3:50 PM Ferenc Gerlits  wrote:
> 
>> Hello,
>> 
>> I am pleased to be calling this vote for the source release of Apache NiFi
>> MiNiFi C++ 0.10.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.10.0/
>> 
>> The Git tag is minifi-cpp-0.10.0-RC2
>> The Git commit ID is 60d5bc70b567fa7c6689f313a75be17fe7c94080
>> 
>> https://git-wip-us.apache.org/repos/asf?p=nifi-minifi-cpp.git;a=commit;h=60d5bc70b567fa7c6689f313a75be17fe7c94080
>> 
>> Checksums of nifi-minifi-cpp-0.10.0-source.tar.gz:
>> SHA256: f7dc86ef6e35ea0d9c9c39891ea281a9851b1e6fc382b16d3a5931814f5ebc22
>> SHA512:
>> 
>> 484d3196d087e7c1acb5d703b827929edf0d8dae295878e1f79232ab8de4fd358f12fa223201c92e0cd9e0c59f2314da9001ac12eb91eabeda751e5d46c4f6b7
>> 
>> Release artifacts are signed with the following key:
>> https://people.apache.org/keys/committer/fgerlits.asc
>> 
>> KEYS file available here:
>> https://dist.apache.org/repos/dist/release/nifi/KEYS
>> 
>> 67 issues were closed/resolved for this release:
>> https://issues.apache.org/jira/projects/MINIFICPP/versions/12349956
>> 
>> Release note highlights can be found here:
>> 
>> https://cwiki.apache.org/confluence/display/MINIFI/Release+Notes#ReleaseNotes-Versioncpp-0.10.0
>> 
>> The vote will be open for 72 hours.
>> Please download the release candidate and evaluate the necessary items
>> including checking hashes, signatures, build
>> from source, and test. Then please vote:
>> 
>> [ ] +1 Release this package as nifi-minifi-cpp-0.10.0
>> [ ] +0 no opinion
>> [ ] -1 Do not release this package because...
>> 

Re: Jira contributor access

[Kevin Doran]

Welcome and thanks for your interest in contributing! I’ve added you to Jira.

-Kevin

> On Apr 29, 2021, at 08:39, Guillaume Schaer  wrote:
> 
> Hey,
> 
> could you please give me Jira contributor access?
> 
> My username is gschaer.
> 
> Thanks
> G

Re: request Jira contributor access

[Kevin Doran]

Welcome! I’ve added you, and you should have access to all the NiFi Jira 
projects now.

Cheers,
Kevin

> On Apr 6, 2021, at 11:03, Paul Grey  wrote:
> 
> Jira username: pgrey

Re: Dropping support for Java 8

[Kevin Doran]

That’s awesome, Joey. I was not aware of that new capability, and certainly is 
an improvement over maintaining multiple Dockerfiles that only differ in their 
base image. I’ll add that to our readme instructions for building the Docker 
image, and if there is enough interest, we could use that method to put out a 
java 11 based image in the future.

> On Mar 26, 2021, at 13:40, Joey Frazee  wrote:
> 
> Kevin, it’s recently possible to specify the underlying openjdk image tag as 
> a property in the Maven build, e.g., -Pdocker  -Ddocker.image.tag=11-jre so 
> it should be easier to start publishing those now too if it’s decided it’s a 
> good idea.
> 
> The default remains 8 for the sorts of concerns being discussed, but this 
> provides the flexibility for people to use an official source release to 
> build 11-based images.
> 
> -joey
> 
>> On Mar 26, 2021, at 8:13 AM, Joe Witt  wrote:
>> 
>> Good thread.  I'd say when a NiFi 2 line happens Java 8 would be gone
>> completely and we would/should consider only supporting the latest LTS
>> line perhaps.
>> 
>>> On Fri, Mar 26, 2021 at 8:05 AM Kevin Doran  wrote:
>>> 
>>> Hi JL,
>>> 
>>> It’s worth discussing/considering changes such as this periodically, so 
>>> thanks for bringing it up.
>>> 
>>> Personally, I would be hesitant to make such a large change. While it would 
>>> likely be a net-positive for the NiFi image itself, I think it would impact 
>>> a number of community members that have Dockerfile’s that use our image as 
>>> a starting point.
>>> 
>>> A GitHub code search [1] seems to confirm this, showing >100 Dockerfiles 
>>> that contain “FROM apache/nifi*”
>>> 
>>> For NiFi 1.x, I think the best we could do is leverage tagging to offer 
>>> image variants that differ in layers we build upon, for example OS or 
>>> JDK/JRE variants. This seems to be a popular method, for example, Apache 
>>> Tomcat offers a multiple of combinations of version, JDK, and OS [2].
>>> 
>>> So if it would be beneficial, we could add official images for other jdk 
>>> versions indicated by tags, for example apache/nifi:1.13.2, 
>>> apache/nifi:1.13.2-jre11, etc.
>>> 
>>> I believe this was part of the plan for the (empty) apache/nifi-container 
>>> code repository [3]. I think the intention was always to build out a richer 
>>> set of diverse container images based on files in this repository, which 
>>> could be maintained/released decoupled from the NiFi source code itself. 
>>> With so many in the community running containerized NiFi, perhaps it's 
>>> worth reviving that discussion to see what, if anything, would be most 
>>> valuable to add to our container offerings.
>>> 
>>> For NiFi 2 we can and should definitely consider what changes we want to 
>>> make to our “default” base image, including which JRE.
>>> 
>>> [1] 
>>> https://github.com/search?l=&q=%22FROM+apache%2Fnifi%22+language%3ADockerfile&type=code
>>>  
>>> <https://github.com/search?l=&q=%22FROM+apache/nifi%22+language:Dockerfile&type=code>
>>> [2] https://hub.docker.com/_/tomcat?tab=description 
>>> <https://hub.docker.com/_/tomcat?tab=description>
>>> [3] https://github.com/apache/nifi-container 
>>> <https://github.com/apache/nifi-container>
>>> 
>>> Thanks!
>>> Kevin
>>> 
>>>>> On Mar 26, 2021, at 07:49, José Luis Pedrosa  wrote:
>>>> 
>>>> Hi All
>>>> 
>>>> I see that the docker images generated are based "openjdk:8-jre" should we
>>>> (I volunteer) to update them to "11-jre"? as both versions are supported (8
>>>> and 11) I don't see any reason why not, and will be more future proof.
>>>> 
>>>> Any opinions?
>>>> 
>>>> JL
>>>> 
>>>> 
>>>> 
>>>>> On Thu, Mar 18, 2021 at 1:59 PM Joe Witt  wrote:
>>>> 
>>>>> Mark
>>>>> 
>>>>> That we can do with a NiFi 2 release for sure. Before then it isnt great.
>>>>> 
>>>>> Oracles JVM is not what I see mostly in the wild any longer and we do see 
>>>>> a
>>>>> ton of Java 8 usage still.
>>>>> 
>>>>> We can and should drop Java 8 but itll be important to do it when we cut a
>>>>> lot of crud out as well.
>>>>> 
>>>>> Thanks
>>>>> 
>>>>> On Thu, Mar 18, 2021 at 6:03 AM Mark Bean  wrote:
>>>>> 
>>>>>> I'd like to discuss migrating to Java 11 as the minimum required Java
>>>>>> version for NiFi. We've been supporting both Java 8 and Java 11 for some
>>>>>> time now. There is increased overhead in verifying builds with two
>>>>>> different versions. There are some features and syntax available in Java
>>>>> 11
>>>>>> which cannot be used in order for NiFi to remain compatible with both
>>>>>> versions. Java 8 premier support (Oracle) runs out in one year. Java 17 -
>>>>>> the next LTS version - is due out later this year.
>>>>>> 
>>>>>> There should be plenty of lead time for users to prepare for the
>>>>>> transition. So I wanted to start the discussion well in advance of when
>>>>> we
>>>>>> discontinue Java 8 support. And, logistically how do we best inform the
>>>>>> community of upcoming changes like this?
>>>>>> 
>>>>>> Thanks,
>>>>>> Mark
>>>>>> 
>>>>> 
>>> 

Re: Dropping support for Java 8

[Kevin Doran]

Hi JL,

It’s worth discussing/considering changes such as this periodically, so thanks 
for bringing it up.

Personally, I would be hesitant to make such a large change. While it would 
likely be a net-positive for the NiFi image itself, I think it would impact a 
number of community members that have Dockerfile’s that use our image as a 
starting point.

A GitHub code search [1] seems to confirm this, showing >100 Dockerfiles that 
contain “FROM apache/nifi*”

For NiFi 1.x, I think the best we could do is leverage tagging to offer image 
variants that differ in layers we build upon, for example OS or JDK/JRE 
variants. This seems to be a popular method, for example, Apache Tomcat offers 
a multiple of combinations of version, JDK, and OS [2].

So if it would be beneficial, we could add official images for other jdk 
versions indicated by tags, for example apache/nifi:1.13.2, 
apache/nifi:1.13.2-jre11, etc.

I believe this was part of the plan for the (empty) apache/nifi-container code 
repository [3]. I think the intention was always to build out a richer set of 
diverse container images based on files in this repository, which could be 
maintained/released decoupled from the NiFi source code itself. With so many in 
the community running containerized NiFi, perhaps it's worth reviving that 
discussion to see what, if anything, would be most valuable to add to our 
container offerings.

For NiFi 2 we can and should definitely consider what changes we want to make 
to our “default” base image, including which JRE.

[1] 
https://github.com/search?l=&q=%22FROM+apache%2Fnifi%22+language%3ADockerfile&type=code
 

[2] https://hub.docker.com/_/tomcat?tab=description 
 
[3] https://github.com/apache/nifi-container 
 

Thanks!
Kevin

> On Mar 26, 2021, at 07:49, José Luis Pedrosa  wrote:
> 
> Hi All
> 
> I see that the docker images generated are based "openjdk:8-jre" should we
> (I volunteer) to update them to "11-jre"? as both versions are supported (8
> and 11) I don't see any reason why not, and will be more future proof.
> 
> Any opinions?
> 
> JL
> 
> 
> 
> On Thu, Mar 18, 2021 at 1:59 PM Joe Witt  wrote:
> 
>> Mark
>> 
>> That we can do with a NiFi 2 release for sure. Before then it isnt great.
>> 
>> Oracles JVM is not what I see mostly in the wild any longer and we do see a
>> ton of Java 8 usage still.
>> 
>> We can and should drop Java 8 but itll be important to do it when we cut a
>> lot of crud out as well.
>> 
>> Thanks
>> 
>> On Thu, Mar 18, 2021 at 6:03 AM Mark Bean  wrote:
>> 
>>> I'd like to discuss migrating to Java 11 as the minimum required Java
>>> version for NiFi. We've been supporting both Java 8 and Java 11 for some
>>> time now. There is increased overhead in verifying builds with two
>>> different versions. There are some features and syntax available in Java
>> 11
>>> which cannot be used in order for NiFi to remain compatible with both
>>> versions. Java 8 premier support (Oracle) runs out in one year. Java 17 -
>>> the next LTS version - is due out later this year.
>>> 
>>> There should be plenty of lead time for users to prepare for the
>>> transition. So I wanted to start the discussion well in advance of when
>> we
>>> discontinue Java 8 support. And, logistically how do we best inform the
>>> community of upcoming changes like this?
>>> 
>>> Thanks,
>>> Mark
>>> 
>>