To make it easier to apply some minimal checkstyle rules for ACCUMULO-3451,
I'm announcing my intentions to do a full, one-time, auto-format and
organize imports on all our supported branches (1.5, 1.6, and master) to
bring us up to some degree of compliance with our agreed-upon formatting
+1
On Wed, Jan 7, 2015 at 3:12 PM, Christopher ctubb...@apache.org wrote:
To make it easier to apply some minimal checkstyle rules for ACCUMULO-3451,
I'm announcing my intentions to do a full, one-time, auto-format and
organize imports on all our supported branches (1.5, 1.6, and master) to
So the steps I was performing were:
1) Eclipse format all java files
2) Eclipse organize all imports
3) Command-line sed to strip trailing whitespace (which gets those pesky
indented empty javadoc lines)
find . -name '*.java' -print0 | xargs -0 sed -i 's/ *$//'
4) Replace tab indents with spaces
Will the checkstyle rules fail the build or just print warnings?
On Wed, Jan 7, 2015 at 3:11 PM, Christopher ctubb...@apache.org wrote:
In the long run, the rules will (hopefully) save me work following up
fixing bad javadocs and trivial warnings.
--
Christopher L Tubbs II
ack'ed
John Vines wrote:
+1
On Wed, Jan 7, 2015 at 3:12 PM, Christopherctubb...@apache.org wrote:
To make it easier to apply some minimal checkstyle rules for ACCUMULO-3451,
I'm announcing my intentions to do a full, one-time, auto-format and
organize imports on all our supported branches
Please do not do formatting during merge conflict resolution, and make
those be separate commits.
On Wed, Jan 7, 2015 at 2:23 PM, Josh Elser josh.el...@gmail.com wrote:
ack'ed
John Vines wrote:
+1
On Wed, Jan 7, 2015 at 3:12 PM, Christopherctubb...@apache.org wrote:
To make it easier
Can do. It's a bit more work for me, because I have to repeat the same
actions over and over again, but if it helps history look a little cleaner,
i can do it, and just stick to -sours and repeat for the next branch..
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Wed, Jan 7, 2015 at
+1
Are you automating the process so that you can re-apply the same steps
in one year?
On Wed, Jan 7, 2015 at 3:31 PM, Christopher ctubb...@apache.org wrote:
Can do. It's a bit more work for me, because I have to repeat the same
actions over and over again, but if it helps history look a
Also, if you're using Eclipse to do the auto-format, please check for
trailing white-space on otherwise empty javadoc lines.
If you automate this in some fashion outside of Eclipse (because other
people may prefer other editors), this would be a useful script to add to a
top-level dev-tools
+0
I don't think it's worth the disruption, but I don't mind if you're going
to do all the work.
On Wed, Jan 7, 2015 at 3:47 PM, Mike Drob mad...@cloudera.com wrote:
Also, if you're using Eclipse to do the auto-format, please check for
trailing white-space on otherwise empty javadoc lines.
In the long run, the rules will (hopefully) save me work following up
fixing bad javadocs and trivial warnings.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Wed, Jan 7, 2015 at 4:03 PM, Eric Newton eric.new...@gmail.com wrote:
+0
I don't think it's worth the disruption, but I
Basically, hard enforcement (failing the build) makes us share
responsibility for quality control.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Wed, Jan 7, 2015 at 4:28 PM, Christopher ctubb...@apache.org wrote:
Fail (which is what I think we want, especially for the broken
Fail (which is what I think we want, especially for the broken javadoc
issues I've been seeing), but it could be configured either way. What I
wouldn't want to happen is for them to be printed and simply ignored. If
we're going to have to go back and fix them (instead of ignoring), I'd
rather they
+1 for that. I feel bad when I see you constantly come across after my
commits when I inevitably bork some Javadoc.
Christopher wrote:
Basically, hard enforcement (failing the build) makes us share
responsibility for quality control.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On
Some of the checkstyle rules catch stuff in javadocs, which even I don't
typically think to look for (like invalid HTML), and I'm pretty pedantic
already when it comes to javadocs.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Wed, Jan 7, 2015 at 4:36 PM, Josh Elser
15 matches
Mail list logo
