| This directory is for features that are intended for reuse. Example use cases: |
| - features that are shared by Chrome on iOS and other Chrome platforms (since |
| the iOS port doesn't use src/chrome) |
| - features that are shared between multiple embedders of content (e.g., Android |
| WebView and Chrome) |
| - features that are shared between Blink and the browser process |
| * Note: It is also possible to place code shared between Blink and the |
| browser process into //third_party/blink/common. The distinction comes |
| down to (a) whether Blink is the owner of the code in question or a consumer |
| of it and (b) whether the code in question is shared by Chrome on iOS as |
| well. If the code is conceptually its own cross-process feature with Blink |
| as a consumer, then //components can make sense. If it's conceptually |
| Blink code, then third_party/blink/common likely makes more sense. (In the |
| so-far hypothetical case where it's conceptually Blink code that is shared |
| by iOS, raise the question on chromium-dev@, where the right folks will see |
| it). |
| |
| In general, if some code is used by a directory "foo" and things above "foo" in |
| the dependency tree, the code should probably live in "foo". |
| |
| By default, components can depend only on the lower layers of the Chromium |
| codebase (e.g. base/, net/, etc.). Individual components may additionally allow |
| dependencies on the content API and IPC; however, if such a component is used |
| by Chrome for iOS (which does not use the content API or IPC), the component |
| will have to be in the form of a layered component |
| (http://www.chromium.org/developers/design-documents/layered-components-design). |
| |
| Components that have bits of code that need to live in different |
| processes (e.g. some code in the browser process, some in the renderer |
| process, etc.) should separate the code into different subdirectories. |
| Hence for a component named 'foo' you might end up with a structure |
| like the following (assuming that foo is not used by iOS and thus does not |
| need to be a layered component): |
| |
| components/foo - DEPS, OWNERS, foo.gypi |
| components/foo/browser - code that needs the browser process |
| components/foo/common - for e.g. IPC constants and such |
| components/foo/renderer - code that needs renderer process |
| |
| These subdirectories should have DEPS files with the relevant |
| restrictions in place, i.e. only components/*/browser should |
| be allowed to #include from content/public/browser. |
| |
| Note that there may also be an 'android' subdir, with a Java source |
| code structure underneath it where the package name is |
| org.chromium.components.foo, and with subdirs after 'foo' |
| to illustrate process, e.g. 'browser' or 'renderer': |
| |
| components/foo/android/OWNERS, DEPS |
| components/foo/android/java/src/org/chromium/components/foo/browser/ |
| components/foo/android/javatests/src/org/chromium/components/foo/browser/ |
| |
| Code in a component should be placed in a namespace corresponding to |
| the name of the component; e.g. for a component living in |
| //components/foo, code in that component should be in the foo:: |
| namespace. |