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 > > > > >> > > > > > > > > > >
