Conflicts:
	lib/puppet/feature/base.rb
	lib/puppet/file_serving/configuration.rb
	spec/unit/indirector/ssl_file_spec.rb
	spec/unit/parser/functions/extlookup_spec.rb
	spec/unit/resource/catalog_spec.rb
	test/language/ast/variable.rb

These specs were assuming that paths such as /foo were always absolute, which
is not the case on Windows. Thus, when run on Windows, the provider was
complaining about receiving relative paths when it expected absolute, rather
than succeeding or failing in the intended way. Now we expand all paths we want
to be absolute, to guarantee they will be absolute everywhere.

Also, some specs were failing because they were trying to test the case where a
file isn't executable. That's not something we can reliably check on Windows,
so instead just stub the appropriate executable? methods.

Reviewed-By: Matt Robinson <matt@puppetlabs.com>
(cherry picked from commit e9b558dd35eec6e221aef9de3f300a5843347454)

Because this provider only applies when the posix feature is present (and thus
not the windows feature), it can never be used on Windows. Thus, the
Windows-specific command handling is unnecessary and unused.

Also added more specific error messages for the cases where a command doesn't
exist, isn't a file, and isn't executable. These only apply when the command
path is absolute (otherwise the message is simply command not found).

Reviewed-By: Matt Robinson <matt@puppetlabs.com>
(cherry picked from commit b28bcb031346cfd2026361ec5ffb420c1dcf60d7)

Conflicts:

	spec/unit/provider/exec/posix_spec.rb

Added missing spec tests for Windows service provider methods:
  :stop, :enable, :disable, and :manual_start
Refactored to match Nick's previous work.

Reviewed By: Nick Lewis [nick@puppetlabs.com]
(cherry picked from commit d08ae7fd2180c95d1fcafa149128d25cc4680c6c)

This provider, windows_adsi, uses the Puppet::Util::ADSI module to manage
groups. It can only manage group existence and memberships, but is fully
functional in those regards.

Based on work by: Joel Rosario <joel.r@.internal.directi.com>
Based on work by: Cameron Thomas <cameron@puppetlabs.com>
Reviewed-By: Matt Robinson <matt@puppetlabs.com>
(cherry picked from commit 01f09f5f395bab66b90a4e81e958aa89025977b4)

This provider, windows_adsi, uses the Puppet::Util::ADSI module to manage
users. It can currently only manage group memberships, comments, and home
directories, which are the only fields that can be managed via ADSI.

Based on work by: Joel Rosario <joel.r@.internal.directi.com>
Based on work by: Cameron Thomas <cameron@puppetlabs.com>
Reviewed-By: Matt Robinson <matt@puppetlabs.com>
(cherry picked from commit ac00e9e289f8fdc81f060e7dd289e1a8e0f133c0)

The host provider did not work on Windows because it didn't know where
to find its hosts file. The provider now uses Win32::Resolv, which is
part of the standard ruby library, to find it.

Several host type/provider spec tests were marked as fails_on_windows,
but now that the provider is working, I removed the tag from those
tests, and verified that the tests now pass. There are two tests in
resources_spec that fail because the user and exec providers are not
supported on Windows yet, so those tests are marked as fails_on_windows.

Reviewed-by: Pieter van de Bruggen <pieter@puppetlabs.com>
(cherry picked from commit 82c6b3cb41397c989c011cf767066bcf1e403db2)

The mount, shell, and ssh_authorized_key types are not supported on
Windows, so these spec tests have been disabled when running on
Windows.

One of the compiler spec tests fails on Windows because
Puppet::Util.execute attempts to execute a program named "git rev-parse
HEAD". This has different semantics than Unix, where the command is
splatted, Kernel.exec(*command). Since this truly is a Windows bug, I
removed the fails_on_windows tag and updated ticket #8410.

Reviewed-by: Jacob Helwig <jacob@puppetlabs.com>
(cherry picked from commit d9ce88d10707268fe41c8f3ad1166137fe8e202f)

Because Windows allows a service to be both running and disabled, we now
support that capability. If a service is explicitly requested to be running and
disabled, we will set it to manual start if necessary, start it, and then
disable it. If the service is requested to be running and enabled, we will now
enable it before attempting to start it (previously, this would simply try to
start it and fail).

The exception to this rule is a service which is disabled, and for which we are
not managing the enable property. In that case, we assume that some other
authority has disabled the service, and respect that, failing to start. Thus,
if the user actually wants a service to be running and disabled, they must
explicitly declare that intent.

Reviewed-By: Jacob Helwig <jacob@puppetlabs.com>
(cherry picked from commit 12d0018f93e5a72a728c6decffb351a693a86344)

These were using fake objects when that's not really necessary, so replace them
with real ones. Additionally, many of these specs were doing the same thing
(like creating a resource), so that has been extracted to the before block.

Reviewed-By: Jacob Helwig <jacob@puppetlabs.com>
(cherry picked from commit f5e8dbef9e16bf05e4c05a43407e94027faa2410)