Re: logging: Since log4j is EOL, it seems to make sense to upgrade to log4j2. Also, since obtaining the logger for each class is abstracted out via a call to the org.apache.pirk.utils.LogUtils (private static Logger logger = LogUtils.getLoggerForThisClass()) and since we aren't currently doing anything 'fancy' with the logging, upgrading to log4j2 would be pretty straightforward. I've never personally used Slf4j, so I can't speak to its ease of integration. Anyone else been down the road with Slf4j + log4j2 before?
Honestly, I don't know enough about Apache Beam at this point to have a strong opinion yet about whether we should tie our implementations into their framework. I think that we can incorporate/use Beam, but I don't want to be dependent on Beam. It appears that they support Java 8 (in taking a look at their pom file - https://github.com/apache/incubator-beam/blob/master/pom.xml); Storm/Heron/Spark Streaming/Flink all support Java 8 too. On Sun, Jul 17, 2016 at 3:10 PM, Suneel Marthi <[email protected]> wrote: > ... and this article went on wire today about log4j > https://blogs.apache.org/logging/entry/moving_on_to_log4j_2 > > On Sun, Jul 17, 2016 at 3:06 PM, Suneel Marthi <[email protected]> wrote: > > > Sorry for being a pest today, more questions: > > > > 1. Seeing that the project's presently using Log4j for logging. Do we > > wanna continue with that or shuld we switch to using Sl4j? > > > > 2. Regarding the previous discussion about Java 8 being the minimum > > required JDK, we may have to base that decision on whether Beam project > > plans to support Java 8 yet or not. > > > > The reasoning for that being, I see a bunch of Streaming and Batch > > integrations on the roadmap here - > > http://pirk.incubator.apache.org/roadmap/ > > > > It may be much more efficient to just integrate with Beam and then > > delegate to Spark/Flink/Apex./Storm/Heron runners. That way we don't have > > to code maintenance for different versions of Storm/Spark/Flink etc. and > > their changing APIs and just focus on Beam. > > > > Thoughts? > > > > Suneel > > > > > > On Sun, Jul 17, 2016 at 1:58 PM, Ellison Anne Williams < > > [email protected]> wrote: > > > >> Agree with Java 8 - we actually talked about doing this before granting > >> the > >> code... Perhaps we should put a JIRA issue in to this effect. > >> > >> There is a 'Coding Standards' section on the 'For Developers' page on > the > >> website ( > >> https://pirk.incubator.apache.org/for_developers#coding-standards) > >> -- the standards, style file, etc were largely borrowed from Accumulo, > >> with > >> some minor modifications. A 'eclipse-pirk-codestyle.xml > >> <https://github.com/apache/incubator-pirk>' file is provided to format > >> the > >> code for Eclipse or Intellij. This can certainly be modified if folks > >> believe that it is best for us to do so. > >> > >> I too would prefer not to specify a preferred IDE as that tends to be > >> quite > >> a personal productivity choice for folks. > >> > >> > >> On Sun, Jul 17, 2016 at 1:29 PM, Joe Witt <[email protected]> wrote: > >> > >> > Hello > >> > > >> > I would recommend at this stage to consider Java 8 as the basis. In > >> > NiFi our upcoming major release establishes java 8 as the baseline. I > >> > believe the community went that route because: > >> > > >> > - It contains language features that are beneficial and that > >> > developers wanted to use. > >> > > >> > - It can make it easier to accept PRs as you may find contributors > >> > wanting to use those features so could be important for community > >> > growth > >> > > >> > - Some popular dependency libraries have moved to Java 8 > >> > > >> > - Java 7 is EOL (https://java.com/en/download/faq/java_7.xml) > >> > > >> > As for coding standards I suspect there are projects that have taken a > >> > stronger stance on this than we have in NiFi. But, the checkstyle > >> > configuration we have seems to work out pretty well and is largely > >> > based on Java standards plus what Accumulo had. So, you might want to > >> > look around a bit to find a style that works well. > >> > > >> > As for preferred IDE - Good luck with that! I'm definitely in favor > >> > of avoiding having an opinion here. By integrating things like > >> > checkstyle, using Maven, and using Git then much of the need to have a > >> > preference is eliminated in my experience. NiFi has have folks using > >> > Eclipse, IntelliJ (admittedly seems to be the favorite), and Netbeans > >> > (ok fine i might be the only one). But more importantly this is > >> > something which is quite personal in terms of developer productivity > >> > and I think there is value in the community avoiding having a > >> > preferred IDE. > >> > > >> > Thanks > >> > Joe > >> > > >> > On Sun, Jul 17, 2016 at 1:05 PM, Suneel Marthi <[email protected]> > >> wrote: > >> > > I have been looking over the code the past week (mostly me getting > >> > > familiarized with the project), I did not notice that the coding > >> > standards > >> > > are more in line with what Eclipse enforces (which is barely > >> anything). > >> > > > >> > > I think all committers should be using IntelliJ for coding, u get an > >> > Apache > >> > > committer's license from Jetbrains for the Ultimate edition of > >> IntelliJ - > >> > > > >> > > <goog_1576328420> > >> > > https://www.jetbrains.com/shop/eform/apache?product=ALL > >> > > > >> > > The coding standards are pretty standard across most Apache Java > >> > projects - > >> > > we could follow NiFi on this. > >> > > > >> > > Also what would be the minimal supported JDK for Pirk ? We shuld > >> baseline > >> > > at Java >= 7 IMO. > >> > > >> > > > > >
