One point of clarification, the following sentence should read Java 17 as a consideration for the minimum in a subsequent major release:
> It is probably necessary to consider *Java 17* support in a future version, but Java 11 provides more of a transitional timeline. Regards, David Handermann On Wed, Dec 7, 2022 at 2:00 PM David Handermann <exceptionfact...@apache.org> wrote: > Thanks to everyone for the feedback thus far! > > Regarding making Java 11 the minimum version versus 17, it is a good > question, particularly in light of the fact that Spring Framework 6 has > made Java 17 the minimum version as noted. NiFi will not be able to use > Spring Framework 6 until Java 17 is the minimum version, so that is a key > concern. One of the key differences in Java 17 is that it enforces > modularization of access, so access to internal JDK classes log warnings on > Java 11, but cause failures on Java 17. It is probably necessary to > consider Java 11 support in a future version, but Java 11 provides more of > a transitional timeline. With the large number of NiFi dependencies, Java > 11 seems to provide the broadest level of compatibility for now. > > The question of the Jakarta namespace is a good one, particularly as it > relates to JAXB components. Some of that can be addressed in individual > modules. Jetty 11 requires the Jakarta namespace, so that should be the > initial target in absence of any other constraints. > > Regarding Controller-Service based configuration, that seems to be a good > goal in general. This applies to features such as the Proxy Configuration > Service, versus individual Proxy properties, and would also apply to > features like MongoDB. This should fall into point 3, removing deprecated > component properties. InvokeHTTP already has deprecation warnings for those > properties, and this would be an item where those properties should be > logged as deprecated in a subsequent version 1 release. > > Regards, > David Handermann > > On Wed, Dec 7, 2022 at 1:50 PM ski n <raymondmees...@gmail.com> wrote: > >> I read the proposal and seems like a very clear plan. The only thing I >> noticed: >> >> "Spring 6 <https://spring.io/blog/2022/11/16/spring-framework-6-0-goes-ga >> > >> removed support for Java 8 in November 2022 " >> >> On the release notes of Spring Framework 6.0 it says: >> >> " As a major revision of the core framework, Spring Framework 6.0 comes >> with a Java 17+ baseline and a move to Jakarta EE 9+ " >> >> When JDK 11 is the baseline for NiFi, can it use Spring Framework 6.0? >> >> And on Jakarta EE 9+, I see a lot of projects now switching from Javax to >> Jakarta (for example Camel: >> https://issues.apache.org/jira/browse/CAMEL-14680) >> >> What will NiFi do with Jakarta namespace? >> >> Raymond >> >> >> >> >> On Wed, Dec 7, 2022 at 8:20 PM Mark Bean <mark.o.b...@gmail.com> 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 <mikerthom...@gmail.com> >> > 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 <marka...@hotmail.com> >> 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 <joe.w...@gmail.com> 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/interface from the runtime/operations and >> > one >> > > > >> which is more fundamentally K8S based. But we can cross that >> > bridge a >> > > > >> bit later. Does seem more and more like folks in the community >> > would >> > > > >> like to know more about the potential directions we can go. >> > > > >> >> > > > >> Thanks! >> > > > >> Joe >> > > > >> >> > > > >> On Tue, Dec 6, 2022 at 1:53 PM David Handermann >> > > > >> <exceptionfact...@apache.org> wrote: >> > > > >>> >> > > > >>> Team, >> > > > >>> >> > > > >>> With the release of NiFi 1.19.0 deprecating support for Java 8, >> the >> > > end >> > > > >> of >> > > > >>> the year provides a good opportunity for finalizing general >> release >> > > goals >> > > > >>> for NiFi 2.0. >> > > > >>> >> > > > >>> Based on previous discussions from July 2021 [1] and June 2022 >> [2], >> > > there >> > > > >>> seems to be general agreement with focusing a NiFi 2.0 release >> on >> > > > >> reducing >> > > > >>> technical debt while providing a straightforward upgrade path >> for >> > > current >> > > > >>> deployments. >> > > > >>> >> > > > >>> I have updated the NiFi 2.0 Proposed Release Goals [3] to >> reflect >> > > more >> > > > >>> recent progress in several areas. I also linked the Deprecated >> > > Components >> > > > >>> and Features [4] page outlining the current state of deprecated >> > > > >>> capabilities. >> > > > >>> >> > > > >>> The most recent update to the Proposed Release Goals outlines >> > > > >> implementing >> > > > >>> migration tooling to make the upgrade process as easy as >> possible. >> > > The >> > > > >>> addition of dedicated deprecation logging in NiFi 1.18.0 makes >> it >> > > easier >> > > > >> to >> > > > >>> warn of breaking changes, but the goal of migration tooling is >> to >> > > make it >> > > > >>> easier to upgrade configurations. >> > > > >>> >> > > > >>> The Proposed Release Goals does not include any release >> timelines >> > > right >> > > > >>> now, and we should anticipate supporting version 1 for a >> reasonable >> > > > >> period >> > > > >>> of time. As more and more libraries deprecate and drop support >> for >> > > Java >> > > > >> 8, >> > > > >>> it will become increasingly difficult to maintain a support >> branch, >> > > which >> > > > >>> is one of the main drivers behind a NiFi 2.0 release that drops >> > > support >> > > > >> for >> > > > >>> Java 8. >> > > > >>> >> > > > >>> The general development strategy should involve transitioning >> the >> > > main >> > > > >>> branch to a 2.0.0-SNAPSHOT version so new features and fixes >> will >> > be >> > > > >>> targeted to the new version. Migration tooling will need to be >> > > > >> implemented >> > > > >>> on a version 1 support branch, and fixes can be backported where >> > > > >> possible, >> > > > >>> in preparation for subsequent version 1 releases. >> > > > >>> >> > > > >>> With that background, I would like to move to a formal vote >> soon, >> > > > >> changing >> > > > >>> the Proposed Release Goals document to Planned Release Goals. >> > Please >> > > > >> weigh >> > > > >>> the general goals highlighted, and if there are no major >> roadblocks >> > > > >>> identified, I will follow up soon with a vote thread. >> > > > >>> >> > > > >>> Regards, >> > > > >>> David Handermann >> > > > >>> >> > > > >>> [1] >> > https://lists.apache.org/thread/yj8scrdbx3pdo7990123mc03q24rn1m7 >> > > > >>> [2] >> > https://lists.apache.org/thread/mm1xf3b9nvrcgytb92oy3swvvc45fl34 >> > > > >>> [3] >> > > > >>> >> > > > >> >> > > >> > >> https://cwiki.apache.org/confluence/display/NIFI/NiFi+2.0+Proposed+Release+Goals >> > > > >>> [4] >> > > > >>> >> > > > >> >> > > >> > >> https://cwiki.apache.org/confluence/display/NIFI/Deprecated+Components+and+Features >> > > > >> >> > > > >> > > >> > >> >
