(pup-1952) Add jruby-19mode to travis ci (but under allow_failures)
(pup-1952) Break out jruby versions of gems as needed
(pup-1952) Accomodate that jruby can't fork
(pup-1952) Increase jruby heap size for travis CI
(PUP-1279) Make Class[::p] remove the ::

When transformed to 3x to form a reference to a class, the 3x runtime
does not handle ::p (it expects the :: to have been removed), and
subsequently it is not able to find classes starting with ::.

This fix removes leading '::' when a PHostClassType is created.
(maint) Add File.open to memory_impl abstraction

And provide a to_path so that it can pretend to be a Pathname when
expanding paths.
Merge pull request #2435 from kylog/issue/pup-1952/run-travis-against-jruby19

(pup-1952) Add jruby-19mode to travis ci (but under allow_failures)
(PUP-1596) Add config_version as an explicit env property

Legacy environments could have config_version set in their puppet.conf
stanza, just as any setting in an [env] stanza would shadow if that
setting was looked up in the context of the environment.  But the new
directory environments are intended to explicitly include config_version
as a setting (albeit an optional one).

This change adds a config_version attribute to
Puppet::Node::Environment, looking it up from settings if a new call is
made, or taking it directly from a create call, which is what the Directory
environments loader will do once environment.conf is parsed for
directory environments.
(PUP-1596) Read environment.conf for new directory environments

Prior to this commit, the new directory environments would always have a
set manifest and modules directory relative to their environment
directory.  This is too restrictive compared with the arbitrary
modulepath and manifest settings available to legacy puppet.conf
environments, so we are adding a per directory environment.conf which
allows arbitrary settings for manifest, modulepath and config_version
per directory environment.

The path to the environment.conf is unique per directory environment and
is not configurable.  For a given $environment found through the
$environmentpath, it is always
"<path-in-environmentpath>/$environment/environment.conf"

Sections other than 'main' are ignored in this file, as are any settings
other than manifest, modulepath and config_version.  Adding a section or
other setting will log a warning but otherwise parse.  A relative path
is always taken to be relative to the environment directory itself.
(PUP-1596) Interpolate settings inside an environment.conf

The initial implementation of environment.conf handling for directory
environments did not take into account the interpolation of settings
within environment.conf settings.  The issue was further complicated by
the fact that environment.conf settings are post-processed to make
relative paths absolute from the context of the environment directory.

For instance, given a directory environment
'/some/environments/interpolated' with an environment.conf where
'modulepath=$basemodulepath:relative/modules', lookup of the setting via
Puppet.setting.value(:modulepath, 'interpolated') would previously
create a directory environment via the loader, which would read the
environment.conf and create an EnvironmentConf object, and return a
modulepath looking like
"/some/environments/interpolated/$basemodulepath:/some/environments/interpolated/relative/modules"
This would then be interpolated by the Settings system, inserting the
value of $basemodulepath.

A direct call to the instatiated
Puppet::Node::Environment#full_modulepath, by contrast would return just
the pre-interpolated path.  Neither was correct.

The problem was that the environment.conf values were being obtained
and post-processed for absolute paths, then passed to the instantiated
environment before settings ever had a chance to be involved.
Historically, this was because settings for directory environments were
based on the values obtained from an instantiated env instance, since
the settings were all hard defaults based solely on the environment
directory.

To fix this, the action of obtaining an environment's configuration has
been separated from the process of obtaining an environment, and a
get_conf() method has been added to the Environments loaders.  For a
Directories loader, it returns the EnvironmentConf for the requested
directory environment.  This is now used by Settings to obtain setting
information for a given directory environment.  And Settings values for
an environment are considered canonical and used by the loader to
instantiate new directory environments.

The other half of the fix is a bit of logic in
EnvironmentConf#absolute() which does not prepend the environment
directory to a path section that begins with a '$' since this indicates
a configuration setting to be interpolated by the Settings system.  This
allows the timing between standing up an EnvironmentConf instance, and
interpolating it within Settings to be separated.
Merge pull request #2431 from jpartlow/feature/master/pup-1596-add-environment-conf

Feature/master/pup 1596 add environment conf
(PUP-1978) Fix issues with [] operator error reporting

There were issues when errors where reported from using the [] operator
with LHS being a Type (Class, Resource) and the given keys were given
as an empty array (resulting in no arguments). The error reporting was
faulty in this case and blamed the wrong object. This resulted in the
error reporting logic to not find a source reference.

This also fixes the issue message text when min/max was the same value.
Merge branch 'master' of https://github.com/puppetlabs/puppet