#### Description
At the moment, `receiver`, `scraper`, `processor`, `exporter`, and
`extension` each have their own version of the `MakeFactoryMap`
function, which takes a list of Factories and returns it as a map, with
the component name as the key (and an error if there is overlap).
Because all versions are near-identical except for the Factory type
used, and this function is only used in tests and in the code generated
by OCB (`components.go`), it was suggested to make it generic and move
it to the `otelcol` package.
This PR does exactly that. The old `MakeFactoryMap` functions are
deprecated (and may be removed alongside their tests in a future
release). I also had to make a few other odd changes to fit the new
dependency graph.
#### Link to tracking issue
Resolves#12222
---------
Co-authored-by: Alex Boten <223565+codeboten@users.noreply.github.com>
This change makes the names to be more "Go" friendly. Also it will not
become an issue that types will try to implement different Factory types
(receiver,processor) because that is forbidden because of our design.
This also makes the names consistent with connector.Factory.
Signed-off-by: Bogdan Drutu <bogdandrutu@gmail.com>
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
This is the last PR to add profiles support, adding it to the service
package.
This is based after #11023.
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
This allows building profiles in the receiver builder.
As this is only changing internal modules, I am marking it as chore (and
skipping changelog entry).
<!-- Issue number if applicable -->
#### Link to tracking issue
https://github.com/open-telemetry/opentelemetry-collector/pull/10375
cc @mx-psi
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
This moves the connector builder out of the `connector` package, and
into `service/internal/builders`.
There's no real reason for this struct to be public (folks shouldn't
call it), and making it private will allow us to add profiling support
to it.
<!-- Issue number if applicable -->
#### Link to tracking issue
https://github.com/open-telemetry/opentelemetry-collector/pull/10375#pullrequestreview-2144929463
#### Description
This moves the receiver builder out of the `receiver` package, and into
`service/internal/builders`.
There's no real reason for this struct to be public (folks shouldn't
call it), and making it private will allow us to add profiling support
to it.
#### Link to tracking issue
https://github.com/open-telemetry/opentelemetry-collector/pull/10375#pullrequestreview-2144929463