You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pirk.apache.org by Suneel Marthi <sm...@apache.org> on 2016/07/17 17:05:24 UTC

Establish Coding Standards for Apache Pirk

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.

Re: Establish Coding Standards for Apache Pirk

Posted by Suneel Marthi <sm...@apache.org>.
Cool with Java 8.

I was just playing safe (and being diplomatic :) ) by proposing >= Java 7.
The Beam project is still on Java 7, but I agree that Java 7 is EOL.



On Sun, Jul 17, 2016 at 1:29 PM, Joe Witt <jo...@gmail.com> 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 <sm...@apache.org> 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.
>

Re: Establish Coding Standards for Apache Pirk

Posted by Suneel Marthi <sm...@apache.org>.
Sl4j is kind'a the standard now for logging in Java, I've been using it
since 2008 in both open source and on the job.

Its an abstraction over all the java logging frameworks out there, so
something like slf4j - log4j2 would be an option to consider; we can then
do away with present LogUtils :)


On Mon, Jul 18, 2016 at 11:03 AM, Ellison Anne Williams <
eawilliamspirk@gmail.com> wrote:

> Unless someone objects, I will create a JIRA issue for upgrading to Java 8
> and another for upgrading to log4j2.
>
> It seems that the jury is still out on using Slf4j -- I will mention it in
> the issue for log4j2.
>
> On Mon, Jul 18, 2016 at 6:30 AM, Tim Ellison <t....@gmail.com>
> wrote:
>
> > On 17/07/16 18:29, Joe Witt wrote:
> > > 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)
> >
> > I agree.  Unless any of Pirk's dependencies refuse to work with Java 8
> > then moving to the latest supported version of Java makes sense for all
> > the good reasons Joe has listed (and I'll add "improved performance" as
> > another).
> >
> > > 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.
> >
> > While not really to my taste, it is good to see a consistent standard
> > applied.  This really is up to committers to agree upon one and stick
> > with it.  Having the tooling support is makes it trivial.
> >
> > > 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).
> >
> > Ah, so /you're/ the Netbeans guy.  Good to meet you at last ;-)
> >
> > > 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.
> >
> > +1 - definitely personal taste and not a project requirement.
> >
> > Regards,
> > Tim
> >
> > > On Sun, Jul 17, 2016 at 1:05 PM, Suneel Marthi <sm...@apache.org>
> > 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.
> >
>

Re: Establish Coding Standards for Apache Pirk

Posted by Ellison Anne Williams <ea...@gmail.com>.
Unless someone objects, I will create a JIRA issue for upgrading to Java 8
and another for upgrading to log4j2.

It seems that the jury is still out on using Slf4j -- I will mention it in
the issue for log4j2.

On Mon, Jul 18, 2016 at 6:30 AM, Tim Ellison <t....@gmail.com> wrote:

> On 17/07/16 18:29, Joe Witt wrote:
> > 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)
>
> I agree.  Unless any of Pirk's dependencies refuse to work with Java 8
> then moving to the latest supported version of Java makes sense for all
> the good reasons Joe has listed (and I'll add "improved performance" as
> another).
>
> > 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.
>
> While not really to my taste, it is good to see a consistent standard
> applied.  This really is up to committers to agree upon one and stick
> with it.  Having the tooling support is makes it trivial.
>
> > 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).
>
> Ah, so /you're/ the Netbeans guy.  Good to meet you at last ;-)
>
> > 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.
>
> +1 - definitely personal taste and not a project requirement.
>
> Regards,
> Tim
>
> > On Sun, Jul 17, 2016 at 1:05 PM, Suneel Marthi <sm...@apache.org>
> 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.
>

Re: Establish Coding Standards for Apache Pirk

Posted by Tim Ellison <t....@gmail.com>.
On 17/07/16 18:29, Joe Witt wrote:
> 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)

I agree.  Unless any of Pirk's dependencies refuse to work with Java 8
then moving to the latest supported version of Java makes sense for all
the good reasons Joe has listed (and I'll add "improved performance" as
another).

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

While not really to my taste, it is good to see a consistent standard
applied.  This really is up to committers to agree upon one and stick
with it.  Having the tooling support is makes it trivial.

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

Ah, so /you're/ the Netbeans guy.  Good to meet you at last ;-)

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

+1 - definitely personal taste and not a project requirement.

Regards,
Tim

> On Sun, Jul 17, 2016 at 1:05 PM, Suneel Marthi <sm...@apache.org> 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.

Re: Establish Coding Standards for Apache Pirk

Posted by Ellison Anne Williams <ea...@gmail.com>.
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 <sm...@apache.org> 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 <sm...@apache.org> 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 <
> > eawilliamspirk@gmail.com> 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 <jo...@gmail.com> 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 <sm...@apache.org>
> >> 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.
> >> >
> >>
> >
> >
>

Re: Establish Coding Standards for Apache Pirk

Posted by Suneel Marthi <sm...@apache.org>.
... 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 <sm...@apache.org> 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 <
> eawilliamspirk@gmail.com> 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 <jo...@gmail.com> 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 <sm...@apache.org>
>> 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.
>> >
>>
>
>

Re: Establish Coding Standards for Apache Pirk

Posted by Suneel Marthi <sm...@apache.org>.
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 <
eawilliamspirk@gmail.com> 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 <jo...@gmail.com> 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 <sm...@apache.org>
> 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.
> >
>

Re: Establish Coding Standards for Apache Pirk

Posted by Ellison Anne Williams <ea...@gmail.com>.
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 <jo...@gmail.com> 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 <sm...@apache.org> 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.
>

Re: Establish Coding Standards for Apache Pirk

Posted by Joe Witt <jo...@gmail.com>.
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 <sm...@apache.org> 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.