ArC - introduce immutable bean archive index

[mkouba]

• this is index is mandatory and is used to discover beans
• the computing index is optional and can be used for other tasks, e.g. during type-safe resolution
• if the computing index is not present the immutable index is used instead
• fixes Unexpected beans added to the index and affecting restarting the application #29575

[Ladicek]

Interesting approach, but makes sense. I guess the intent is that the computing index should be used most of the time (or fallback to the immutable one if the computing doesn't exist), but there are certain occasions where the immutable index must be used unconditionally? It would be nice to have a little more detailed explanation of when the 2nd condition occurs.

Aside: I so wish we had a complete index of everything (both the Quarkus combined index and the ArC bean archive index) so that we don't have to do on-demand indexing at all...

[mkouba]

It would be nice to have a little more detailed explanation of when the 2nd condition occurs.

Yes, well it's described here and here but I can try to add more description to the BeanArchiveIndexBuildItem.

Aside: I so wish we had a complete index of everything (both the Quarkus combined index and the ArC bean archive index) so that we don't have to do on-demand indexing at all...

That would be nice but in that case we would have index the whole classpath (including jdk classes) which is probably unrealistic.

[Ladicek]

It would be nice to have a little more detailed explanation of when the 2nd condition occurs.

Yes, well it's described here and here but I can try to add more description to the BeanArchiveIndexBuildItem.

Those are exactly the descriptions that should be more detailed in my opinion. I mean, as ArC contributor, how do I know which index should I use? The optional one most of the time, probably, but I'm not really sure :-)

Aside: I so wish we had a complete index of everything (both the Quarkus combined index and the ArC bean archive index) so that we don't have to do on-demand indexing at all...

That would be nice but in that case we would have index the whole classpath (including jdk classes) which is probably unrealistic.

It wouldn't have to be the entire JDK, we'd just have to index the transitive closure of the application classes. I didn't try, so I don't know how crazy that would eventually become :-)

[mkouba]

Those are exactly the descriptions that should be more detailed in my opinion. I mean, as ArC contributor, how do I know which index should I use? The optional one most of the time, probably, but I'm not really sure :-)

And my answer would be "it depends" :-). In general, you should use the immutable index to discover the components (beans, observers, etc.) - that's the case we're trying to fix with this PR - and the computing index for any other stuff. That's why we return the computing index from the BeanDeployment.getBeanArchiveIndex().

We should also clarify that the computing index is built on top of the immutable index, i.e. only classes that are not part of the immutable index can be computed.

[Ladicek]

Okay, so basically type discovery should use the immutable index, and bean discovery should use the computing index? Or something like that.

We should also clarify that the computing index is built on top of the immutable index, i.e. only classes that are not part of the immutable index can be computed.

Great point. The BeanProcessor builder currently has 2 setters, so we rely on its caller to maintain this invariant. I guess we can't really build the computing index internally and have to obtain it from the outside?

[mkouba]

Great point. The BeanProcessor builder currently has 2 setters, so we rely on its caller to maintain this invariant. I guess we can't really build the computing index internally and have to obtain it from the outside?

Hm, in theory we could but I'd like to keep it more flexible for now. And given the fact that only the arc extension and ArcTestContainer are the "callers" I think that it's ok.

[quarkus-bot]

Failing Jobs - Building c2ab342

Status	Name	Step	Failures	Logs	Raw logs
✔️	JVM Tests - JDK 11
✖	JVM Tests - JDK 11 Windows	Build	Failures	Logs	Raw logs
✔️	JVM Tests - JDK 17
✖	JVM Tests - JDK 17 MacOS M1	Set up runner	⚠️ Check →	Logs	Raw logs
✔️	JVM Tests - JDK 18

Full information is available in the Build summary check run.

Failures

⚙️ JVM Tests - JDK 11 Windows #

- Failing: extensions/quartz/deployment 
! Skipped: integration-tests/quartz 

📦 extensions/quartz/deployment

✖ io.quarkus.quartz.test.FireTimeTest.testExecution line 39 - More details - Source on GitHub

java.lang.AssertionError: 

Expecting actual: