Remove debug logging on stderr
Tweaks for boot gradle plugin

Fixes gh-152.

... to ease excluding dependencies
eckage changed to bootRepackage

- Register BootRepackage order to use task foo(type: BootRepackage){}
- Allow user to use customConfiguration

configurations {
  hadoopruntime.exclude group: 'log4j'
  hadoopruntime.exclude group: 'org.slf4j'
  hadoopruntime.exclude group: 'org.apache.hadoop'
  hadoopruntime.exclude group: 'org.apache.hive'
  hadoopruntime.exclude group: 'commons-logging'
  hadoopruntime.exclude group: 'org.codehaus.jettison'
  hadoopruntime.exclude group: 'com.thoughtworks.xstream'
}
dependencies {
  compile "org.springframework.batch:spring-batch-core:$springBatchVersion"
  compile "org.springframework.batch:spring-batch-infrastructure:$springBatchVersion"
  compile "org.springframework.data:spring-yarn-batch:$springDataVersion"
  compile "org.springframework.data:spring-yarn-boot:$springDataVersion"
  runtime "org.springframework.data:spring-data-hadoop:$springDataVersion"
  runtime "org.springframework.data:spring-data-hadoop-core:$springDataVersion"
  runtime "log4j:log4j:$log4jVersion"
  runtime "org.slf4j:slf4j-log4j12:$slf4jVersion"
  testCompile "org.springframework.data:spring-yarn-test:$springDataVersion"
  testCompile "org.hamcrest:hamcrest-core:$hamcrestVersion"
  testCompile "org.hamcrest:hamcrest-library:$hamcrestVersion"
  hadoopruntime configurations.runtime
}

springBoot {
  backupSource = true
  customConfiguration = 'hadoopruntime'
}

task appmasterJar(type: Jar) {
  appendix = 'appmaster'
  from sourceSets.main.output
  exclude('**/*Container*')
  exclude('**/*Client*')
}

task clientJar(type: Jar) {
  appendix = 'client'
  from sourceSets.main.output
  exclude('**/*Appmaster*')
  exclude('**/*Container*')
}

task clientBoot(type: BootRepackage, dependsOn: clientJar) {
  withJarTask = clientJar
}

task appmasterBoot(type: BootRepackage, dependsOn: appmasterJar) {
  customConfiguration = "hadoopruntime"
  withJarTask = appmasterJar
}

//jar.enabled = false
//bootRepackage.enabled = false

task bootJars
bootJars.dependsOn = [clientBoot,containerBoot,appmasterBoot]

build.dependsOn(clientBoot)
build.dependsOn(containerBoot)
build.dependsOn(appmasterBoot)
//build.dependsOn(bootJars)
Add build.gradle samples and rename runJar->bootRun
Change interface of CommandFactory slightly

It's super useful to get a reference to the current SpringCli
instance in the CommandFactory. Potentially implementations can
react to the properties of the Cli, or wrap it into something
more complex.

...supports the likely implementation of the REPL use
case that @jbrisbin has been working on.
Refactor metrics to expose richer feature set

Main user-facing interface is still Counter/GaugeService but the
back end behind that has more options. The Default*Services write
metrics to a MetricWriter and there are some variants of that, and
also variants of MetricReader (basic read-only actions).

MetricRepository is now a combination of MetricReader, MetricWriter
and some more methods that make it a bit more repository like.

There is also a MultiMetricReader and a MultiMetricRepository for
the common case where metrics are stored in related (often open
ended) groups. Examples would be complex metrics like histograms
and "rich" metrics with averages and statistics attached (which
are both closed) and "field counters" which count the occurrences
of values of a particular named field or slot in an incoming message
(e.g. counting Twitter hastags, open ended).

In memory and redis implementations are provided for the repositories.
Generally speaking the in memory repository should be used as a
local buffer and then scheduled "exports" can be executed to copy
metric values accross to a remote repository for aggregation.
There is an Exporter interface to support this and a few implementations
dealing with different strategies for storing the results (singly or
grouped).

Codahale metrics are also supported through the MetricWriter interface.
Currently implemented through a naming convention (since Codahale has
a fixed object model this makes sense): metrics beginning with "histogram"
are Histograms, "timer" for Timers, "meter" for Meters etc.

Support for message driven metric consumption and production are provided
through a MetricWriterMessageHandler and a MessageChannelMetricWriter.

No support yet for pagination in the repositories, or for HATEOAS style
HTTP endpoints.