Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-dev@hadoop.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
Sender: niels@basj.es
Date: Sun, 30 Dec 2012 00:32:20 +0100
Message-ID: 
 <CADoiZqqTjViCPNWdxWNFZd2VoHw5=UOZ8um8sW0xobSQtdXSuw@mail.gmail.com>
Subject: Sorting user defined MR counters.
From: Niels Basjes <Niels@basjes.nl>
To: hadoop_mailing_list <core-dev@hadoop.apache.org>
Content-Type: multipart/alternative; boundary=bcaec54b4aa0fe1bae04d2063038

--bcaec54b4aa0fe1bae04d2063038
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I've had this 'itch' with Hadoop that it is hard to sort the counters in a
"nice" way.
Now the current trunk sorts the framework counters in such a way that they
follow the flow quite nicely. For the generic counters (i.e. user code
counters) this is not possible.

I've been playing around these last few days to see if I can extend the API
so I can create custom counters from my MR code and have the framework
report them in the sorting order I defined that is useful  for my specific
application.

I currently have a working version of this idea here so I'm wondering ...

Is this something you would like to have in the main source tree? From my
point of view this is very generic and reusable by many projects.

If you say 'yes' then I'll simply create a Jira for this and submit the
patch.

In addition I have a question about the content of such a patch.
In some source files I'll be changing there are numerous very basic
warnings from both the Java compiler, findbugs and checkstyle.
With simple things I mean silly things "unused imports", "an interface that
has directives like private and public", "first line of javadoc must end
with '.'", "unused SuppressWarnings directives" .

I my normal job I commit a source file at least  "just as clean" as what I
got to start with but preferably I make it "cleaner". That way a warning is
something you look at instead of "part of the landslide" which people tend
to ignore.

Now for submitting changes for Hadoop: Is it desirable that I fix these in
my change set or should I leave these as-is to avoid "obfuscating" the
changes that are relevant to the Jira at hand?

-- 
Best regards / Met vriendelijke groeten,

Niels Basjes

--bcaec54b4aa0fe1bae04d2063038--