Ok. So on branch NIFI-271 have added checkstyle (with the exact rules accumulo uses). As you could predict the build does not work at this time because of checkstyle failures in a ton of places. I am happy to go through the entire codebase and make those changes.
But, I'll hold here for two things: 1) Give folks a chance to take a look at those checkstyle rules. They're on branch NIFI-250 in nifi-parent/pom.xml. Now is a good time if you do indeed have a strong opinion to influence the near-term outcome. I think the discussion preceding this suggests we're all open to the fact that formatting is a holy war none of us want. But what we wall want is consistency. So this sets a stake in the ground. We can iterate from there, albeit slowly, over time. Please if you are likely to care about this take a moment to checkout the branch and using your favorite IDE/formatter of choice make sure things seem ok. I use netbeans <hold the jokes please> and found these rules to be perfectly fine without having to tweak much. Specifically for those of you who use Eclipse or IntelliJ or vi please give it a look. 2) There is a very major branch NIFI-250 outstanding for which it would really ruin their party if i made all of these changes now. So please advise when that branch can be folded into develop as well as when it has been. If anyone else has outstanding branches for which they would like to see this initiative held up please identify them so we can minimize the challenge faced later when attempting to merge. Once we're past 1 & 2 here I'll do the following: 1) Rebase/Merge (whatever I can get away with) NIFI-271 against whatever the lastest development line has. 2) Build. Resolve style failures of noted module <repeat until happy> 3) Request a prompt RTC and merge into develop Finally, I do not know whether this resolves all of the formatting cases which can cause merges to require more effort than intuitively necessary. But this should at least get us closer to consistent. We'll need to work quickly on that part because the longer it takes the higher the probably of disruption to folks who might want to do a contribution. We're seeing more and more contributions and that will only continue if we make it easy for people to contribute quality code. So this is a really important step. Thanks! Joe On Sat, Mar 21, 2015 at 11:18 AM, Joe Witt <[email protected]> wrote: > Folks, > > Benson put in a ticket a while back: > https://issues.apache.org/jira/browse/NIFI-271 to make a DRY > nifi-parent we can extend from in the main nifi line and the > nifi-nar-plugin. > > Proposal: > 1) Do what Benson said. > 2) In that nifi-parent ensure checkstyle is always run and thus > consistent across any nifi item. Fail the build if any violations. > 3) In that nifi-parent ensure check-licenses is always run and if any > fails - fail the build. > > Commentary: > - This is not as forgiving as Sean suggested but it also does not > preclude us from doing the QC bot to check higher order items. > - This is more in-line with Adam's suggestion but gives the > contributor direct feedback on what is wrong that they can resolve on > their own without us rejecting their PR. This I am guessing was > Adam's real intent anyway. > - I will go through an make sure all existing code is in-line with the > checkstyle form that we will create. That will require very loud > music and good drinks but whatever - about as much fun as it was > getting all the licensing squared away. > > I noticed that accumulo has this nicely integrated into their build so > that gives a great example to follow. > > Thanks > Joe > > On Tue, Mar 17, 2015 at 10:44 PM, Joe Witt <[email protected]> wrote: >> Sean: >> >> Nope we're still pretty basic. >> >> Thanks >> Joe >> >> On Tue, Mar 17, 2015 at 10:41 PM, Sean Busbey <[email protected]> wrote: >>> On Tue, Mar 17, 2015 at 9:32 PM, Joe Witt <[email protected]> wrote: >>> >>>> >>>> >>>> On the thread itself: Anyone interested in pushing forward the >>>> model/changes to get the formatting process smoothed out please do so. >>>> >>>> >>> Do y'all have a QA bot yet? I'm looking to coalesce the pre-commit testing >>> of Hadoop and HBase in the next ~2-4 weeks. Having a third unrelated >>> project to throw against that would help me ensure I have something >>> reusable that can spread across ASF projects. >>> >>> We haven't determined yet where the shared pre-commit checker will live, >>> but we don't seem too opinionated yet so it's unlikely we'll need lots of >>> changes. >>> >>> -- >>> Sean
