Initial commit
Add JRE package management.

Add the ability to install the JRE package at version 1.6.0_25-fcs
Update CHANGELOG for 0.0.1 release

Also make sure module metadata is ready to go.
Add .DS_Store to gitignore
Add JDK 1.6.0_25 as the default package

This adds a new java::jdk_package class and makes
the wrapper class default to this Java runtime.
Update CHANGELOG for 1.0.0 release
Add basic validation to class parameters
Fixup validation for Puppet 2.6.8

Anonymous arrays and comparing booleans does not work in 2.6.8 like they
do in master.  In 2.6.8 we cannot compare a true / false variable to a
string inside of Ruby without forcing the function argument to be a
string.
Merge branch 'feature/master/XXXX_validation'

* feature/master/XXXX_validation:
  Fixup validation for Puppet 2.6.8
  Add basic validation to class parameters
Update CHANGELOG for 1.0.1
Re-version from 1.0.1 to 0.1.1 for semver
Change jre and jdk booleans to a single string

Dan raised the comment in the previous patch set that it doesn't make
sense to provide two options and four states when there are really only
two possibilities; install the jre or the jdk.

This change removes the jdk and jre class parameters and replaces them
with a single distribution parameters.
Merge branch 'comment/master/jre_vs_jdk'

* comment/master/jre_vs_jdk:
  Change jre and jdk booleans to a single string
Update CHANGELOG to 0.1.2
Remove stages from java module

The stages feature of stdlib is turning out to be more trouble than it's
worth.  Integrating the changes from Cody and Gary results in the entire
mcollective class being in the main stage.  We've already found is
preferable to have stages after main rather than before to avoid
dependency cycles.  This only works if all modules use stages.  The
first module to not use stages will create a cycle if it requires and
modules who do use stages and the stages come after main.
Merge branch 'bug/master/get_rid_of_stages'

* bug/master/get_rid_of_stages:
  Remove stages from java module
Update CHANGELOG for version 0.1.3
Fix ordering issues with composed classes

The top level java module was declaring classes depending on what Java
distribution is required.  Similar to the issues encountered with
service and configuration class ordering, the composed classes did not
have an established relationship with other things that require the
module.

This change brings all resources into a single top level java class and
eliminates class composition within the module entirely.
Merge branch 'bug/master/class_ordering'

* bug/master/class_ordering:
  Fix ordering issues with composed classes
Update CHANGELOG for version 0.1.4