Re: NiFi codebase warnings
Hi Joe Understanding completely the situation, I see a lot of open PRs, and the challenge reviewing them may present specially. I also understand the extra care with PRs from non regular contributors. I'll keep only once open at a time from now on. If you'd like that I create a set of Jira issues and someone can assign them to me when there's bandwidth available to review, that is also ok for me. If there's any extra way I can facilitate the process, let me know. JL On Thu, Apr 1, 2021 at 6:13 PM Joe Witt wrote: > Jose > > Thanks for your contributions and note. Such contributions and intent > are welcome and appreciated. > > The challenge is our PR review bandwidth. We receive far more > contributions than we have review bandwidth for. Four of your PRs > touch a lot of files and the problem is if we don't get to them > quickly your PR will get out of date/have merge conflicts. The energy > to contribute is awesome and I dont want to deter you. I just want to > recommend an approach to make it more enjoyable. Try to focus on a > single PR at a time for instance. Once you build some momentum and > folks in the community and doing reviews get more familiar with your > work it can get easier too. > > Anyway just wanted to give a little perspective. What you have done > is perfectly fine. Just sharing the challenge so many substantive PRs > at once can present. > > Thanks > > On Wed, Mar 31, 2021 at 3:54 AM José Luis Pedrosa > wrote: > > > > Hi Devs/Maintainers > > > > I've recently started using NiFi and I thought it would be a good idea to > > give something back to the community while getting familiar with the > > different areas of NiFi. I am writing to explain the relation between few > > PRs that are submitted and check with you if it's a good idea and if it > > would require a different approach. > > > > I saw during compilation that are some warnings related to deprecated > APIS, > > that could be solved without a lot of issues, so I've submitted a PR for > > each of the different APIs being deprecated, some of them internal, some > of > > them external, [1],[2],[3],[4]. > > I've also submitted an small PR regarding code inspections [5] (Make > inner > > classes static where possible). I guess after some more PRs all warnings > > would be gone and it would be possible to enable warnings as error during > > compilation. > > > > So those are the questions that popped in my mind: > > > >- Are these kind of initiatives wellcome? > >- Should I handle it differently at code level? > >- Should I do something different at Jira rather than creating > >individual issues? (Maybe an epic level that comprises all of this?) > >- Any particular improvement that sounds more urgent or you'd like to > >get it done first? > > > > > > Kind Regards > > JL > > > > [1] https://github.com/apache/nifi/pull/4947 > > [2] https://github.com/apache/nifi/pull/4945 > > [3] https://github.com/apache/nifi/pull/4942 > > [4] https://github.com/apache/nifi/pull/4941 > > [5] https://github.com/apache/nifi/pull/4940 >
NiFi codebase warnings
Hi Devs/Maintainers I've recently started using NiFi and I thought it would be a good idea to give something back to the community while getting familiar with the different areas of NiFi. I am writing to explain the relation between few PRs that are submitted and check with you if it's a good idea and if it would require a different approach. I saw during compilation that are some warnings related to deprecated APIS, that could be solved without a lot of issues, so I've submitted a PR for each of the different APIs being deprecated, some of them internal, some of them external, [1],[2],[3],[4]. I've also submitted an small PR regarding code inspections [5] (Make inner classes static where possible). I guess after some more PRs all warnings would be gone and it would be possible to enable warnings as error during compilation. So those are the questions that popped in my mind: - Are these kind of initiatives wellcome? - Should I handle it differently at code level? - Should I do something different at Jira rather than creating individual issues? (Maybe an epic level that comprises all of this?) - Any particular improvement that sounds more urgent or you'd like to get it done first? Kind Regards JL [1] https://github.com/apache/nifi/pull/4947 [2] https://github.com/apache/nifi/pull/4945 [3] https://github.com/apache/nifi/pull/4942 [4] https://github.com/apache/nifi/pull/4941 [5] https://github.com/apache/nifi/pull/4940
Re: Dropping support for Java 8
Hi All thanks for the replies, I may say some quite incorrect things as I am new to NiFi. I see that there are two docker images: https://github.com/apache/nifi/tree/master/nifi-docker/dockermaven https://github.com/apache/nifi/tree/master/nifi-docker/dockerhub I am assuming what Joey is mentioning (mvn) applies only to "dockermaven"? Indeed the usual way is to have different tags for different versions of the underlying bases, which is also already present for us, as nifi chose (by omission) the default flavour for it (there are a lot of openjdk XX images, even windows), so one extreme we could generate one per the different openjdk on the other extreme we could generate only one. Not sure if any of the JVM settings done in the scripts apply only to one Java version, potentially there would be the need to add flexibility to work with both on the scripts. >From my perspective as a user: I use the container as a container, in this case I just want the recommended option (performance, stability...) and after those criterias, the smaller the image the better. Happy to help if you have a clear idea if you (apache committers) of what is the destination desired. Kind regards JL On Fri, Mar 26, 2021 at 6:07 PM Kevin Doran wrote: > 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==%22FROM+apache%2Fnifi%22+language%3ADockerfile=code > < > https://github.com/search?l==%22FROM+apache/nifi%22+language:Dockerfile=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! > >
Re: Dropping support for Java 8
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 > > >
