<feed xmlns='http://www.w3.org/2005/Atom'>
<title>delta/ruby-gems/chef.git/spec/data/lwrp/resources, branch https</title>
<subtitle>github.com: opscode/chef.git
</subtitle>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/ruby-gems/chef.git/'/>
<entry>
<title>Chef-13: Chef::Resource cleanup</title>
<updated>2017-03-08T22:16:39+00:00</updated>
<author>
<name>Lamont Granquist</name>
<email>lamont@scriptkiddie.org</email>
</author>
<published>2017-03-08T22:16:39+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/ruby-gems/chef.git/commit/?id=4650185d366874c175bd043d11fad6244ba33e6f'/>
<id>4650185d366874c175bd043d11fad6244ba33e6f</id>
<content type='text'>
most of this deletes useless old code.

the change to lookup_provider_constant changes to more strictly
stop using class name based lookups and to go through the resource
resolver and provider resolver.

as a result in order to find the provider class for a given dsl name
you have to go through the resource resolver to find the resource in
order to be able to pass a resource instance through the provider
resolver.  since the provider resolver api passes resources into blocks
passed into provides api you must construct a resource instance.

that means that providers need to be associated with resources in order
to be looked up (which makes sense in Real Life(tm) use of Chef, but
breaks quite a few lazy tests we had where we constructed providers
without doing the work of wrapping them in a resource.

note that as the deploy resource shows this filters into a changed
behavior of the `provider` syntax where before `provider :revision`
would look up Chef::Provider::Deploy::Revision via class-name based
magic.  this breaks that API so that `provider :deploy_revision` is
used instead -- the symbol (or string) there is turned into a resource
first via the Chef::ResourceResolver and then looked up via the
Chef::ProviderResolver into Chef::Provider::Deploy::Revision.  this
is a breaking change but is also a bug fix so that the symbol here
goes through the same lookup that you get when you type it in the DSL.

i had considered implementing a lookup from a resource_name symbol to
a provider, but in looking at how to implement that in the
ProviderResolver the issue is that we really need to have a resource
instance order to pass to the ProviderResolver.

Signed-off-by: Lamont Granquist &lt;lamont@scriptkiddie.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
most of this deletes useless old code.

the change to lookup_provider_constant changes to more strictly
stop using class name based lookups and to go through the resource
resolver and provider resolver.

as a result in order to find the provider class for a given dsl name
you have to go through the resource resolver to find the resource in
order to be able to pass a resource instance through the provider
resolver.  since the provider resolver api passes resources into blocks
passed into provides api you must construct a resource instance.

that means that providers need to be associated with resources in order
to be looked up (which makes sense in Real Life(tm) use of Chef, but
breaks quite a few lazy tests we had where we constructed providers
without doing the work of wrapping them in a resource.

note that as the deploy resource shows this filters into a changed
behavior of the `provider` syntax where before `provider :revision`
would look up Chef::Provider::Deploy::Revision via class-name based
magic.  this breaks that API so that `provider :deploy_revision` is
used instead -- the symbol (or string) there is turned into a resource
first via the Chef::ResourceResolver and then looked up via the
Chef::ProviderResolver into Chef::Provider::Deploy::Revision.  this
is a breaking change but is also a bug fix so that the symbol here
goes through the same lookup that you get when you type it in the DSL.

i had considered implementing a lookup from a resource_name symbol to
a provider, but in looking at how to implement that in the
ProviderResolver the issue is that we really need to have a resource
instance order to pass to the ProviderResolver.

Signed-off-by: Lamont Granquist &lt;lamont@scriptkiddie.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>add resource_resolver and resource_priority_map</title>
<updated>2015-04-16T00:50:15+00:00</updated>
<author>
<name>Lamont Granquist</name>
<email>lamont@scriptkiddie.org</email>
</author>
<published>2015-04-11T19:48:22+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/ruby-gems/chef.git/commit/?id=e3a6565927e854cd5968bd3a6bd2248ec1245549'/>
<id>e3a6565927e854cd5968bd3a6bd2248ec1245549</id>
<content type='text'>
also wire them up through the Chef class.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
also wire them up through the Chef class.
</pre>
</div>
</content>
</entry>
<entry>
<title>Added comment about change in bar.rb</title>
<updated>2014-12-06T00:41:53+00:00</updated>
<author>
<name>Jay Mundrawala</name>
<email>jdmundrawala@gmail.com</email>
</author>
<published>2014-12-06T00:41:53+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/ruby-gems/chef.git/commit/?id=210beca7f05ad05443cf8876ca5afe915e32acc6'/>
<id>210beca7f05ad05443cf8876ca5afe915e32acc6</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Added a provides to lwrp in spec to cover that case</title>
<updated>2014-12-06T00:34:57+00:00</updated>
<author>
<name>Jay Mundrawala</name>
<email>jdmundrawala@gmail.com</email>
</author>
<published>2014-12-06T00:34:57+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/ruby-gems/chef.git/commit/?id=02e30cf7d3236e2fb3b80fc89835922ca7cb245c'/>
<id>02e30cf7d3236e2fb3b80fc89835922ca7cb245c</id>
<content type='text'>
Note -- This test fails
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Note -- This test fails
</pre>
</div>
</content>
</entry>
<entry>
<title>Don't override LWRP resources or providers anymore in Chef 12.</title>
<updated>2014-10-08T22:01:30+00:00</updated>
<author>
<name>Serdar Sutay</name>
<email>serdar@opscode.com</email>
</author>
<published>2014-10-08T21:55:33+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/ruby-gems/chef.git/commit/?id=02fb9664331e88f1abc159bc673f813e9299952a'/>
<id>02fb9664331e88f1abc159bc673f813e9299952a</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[OC-3564] move core Chef to the repo root \o/ \m/</title>
<updated>2012-10-30T14:39:35+00:00</updated>
<author>
<name>Seth Chisamore</name>
<email>schisamo@opscode.com</email>
</author>
<published>2012-10-30T14:39:35+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/ruby-gems/chef.git/commit/?id=24dc69a9a97e82a6e4207de68d6dcc664178249b'/>
<id>24dc69a9a97e82a6e4207de68d6dcc664178249b</id>
<content type='text'>
The opscode/chef repository now only contains the core Chef library code
used by chef-client, knife and chef-solo!</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The opscode/chef repository now only contains the core Chef library code
used by chef-client, knife and chef-solo!</pre>
</div>
</content>
</entry>
</feed>
