//components/policy depends on //extensions, possibly violating the layering rule
Reported by
most...@opera.com,
May 26 2017
|
|||||||
Issue description//components/policy depends on //extensions which IIUC is specific to the chrome layer. This appears to violate the layering rule, ie that components are only supposed to depend upon lower layers. Reference: https://chromium.googlesource.com/chromium/src/+/master/components/README
,
May 26 2017
,
May 26 2017
,
May 29 2017
Brett, looks like maybe this was added by https://codereview.chromium.org/2479593006 - we don't actually use anything from //extensions, we're just checking if enable_extensions is set in our BUILD.gn file. Is even this dependency (on whether extensions are enabled or not) disallowed? Maksim, maybe we should just nuke our dependency on ENABLE_EXTENSIONS? It's limited to schema_registry.cc, and I think we could safely call SetExtensionsDomainsReady() regardless of whether the platform enables extensions or not - it's just an unnecessary observer invocation, right?
,
May 31 2017
Re schema_registry.cc - I don't think that the change to always call SetExtensionsDomainsReady is safe. It controls the initialization order of different parts (obtaining extensions' schemas, loading policies, exposing them). Normally SetExtensionsDomainsReady() is called from the extensions subsystem (from extensions::ManagedValueStoreCache::ExtensionTracker::Register), and that's why schema_registry.cc has to fake this when under !ENABLE_EXTENSIONS. But we can probably move this stub call of SetExtensionsDomainsReady() out from //components/policy - e.g. into //chrome/browser/policy/schema_registry_service_factory.cc where it's instantiated.
,
Jun 1 2017
Makes sense - maybe you can eliminate this dependency at some point - definitely seems cleaner.
,
Sep 28 2017
,
Aug 1
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by most...@opera.com
, May 26 2017