ArC: split logic in ComponentsProviderGenerator

[mkouba]

• to support very large deployments
• we use the same strategy for beans, observers and removedBeans
• first we split the processing into multiple groups; each group is represented by a static method
• several groups belong to a container class
• static methods are invoked either directly from the ComponentsProvider or from a dedicated lambda

[mkouba]

FTR the container classes are necessary because of the constant pool limit.

[Ladicek]

This is obviously OK (when I diff with whitespace disabled).

My only objection is that the secondary grouping is way too ugly compared to the primary grouping; it should be done the same way, also in preprocess().

[gsmet]

I added a small comment but feel free to ignore if you have a strong opinion. My point is that we should avoid splitting in the relatively standard case that used to work before.

I kinda agree with @Ladicek that we should make the splitting as consistent as possible.

[mkouba]

I kinda agree with @Ladicek that we should make the splitting as consistent as possible.

@gsmet I'm not sure what this sentence actually means?

[Ladicek]

I kinda agree with @Ladicek that we should make the splitting as consistent as possible.

@gsmet I'm not sure what this sentence actually means?

I'm not sure either, but if we did what I suggested on Zulip (split the bean graph into components and make sure the entire component is generated in a single method), we might get slight performance benefits of avoiding map lookups and using values directly. But I'm not sure how big those benefits would be.

[gsmet]

@gsmet I'm not sure what this sentence actually means?

Sorry it was a reference to the excessive nitpicking on grouping :).

I'm perfectly fine with the general approach.