So you are only annotating the class with @Alternative in order for them not to be automatically picked up and used as beans?

Exactly

If you don't have discovery mode all, then you shouldn't need this at all.

They are also annotated @ApplicationScoped, so they would be picked up enabled without @Alternative, this way they are picked up, but not enabled and I just add them a second time but this time as non-alternative.

If you do have it, then Weld will discover these anyway, it will just not enable them (and you might as well just listen for these beans in ProcessAnnotatedType observer and conditionally remove the annotation there which will result in the bean being picked up and used without any manual registration).

Ah, perfect, this is what I actually was after then

Furthermore, if you mean to have them as classes that are normally left alone by discovery, then you can use @Vetoed instead.

Ah, even better, this way I save the "effort" of having all the alternate beans that will not get enabled, so I mark the beans as @Vetoed and then use BeforeBeanDiscovery#addAnnotatedType(...) removing the @Vetoed instead of the @Alternative annotation.

Is it expected that unlike @Alternate you cannot apply @Vetoed using a stereotype?

And last thing I can think of is that you can also specify filters in beans.xml that exclude certain packages from discovery - that way you could leave out the alternative annotation and not have the beans picked up a

Hm, that sounds very interesting, but will not work with standard setup, as this is for integ tests run from Gradle, where the classes and resources are in separate folders on the class path, so the beans.xml would not be picked up as the two directories are considered individual bean archives and I do not see a way to define exclude patterns via SeContainerInitializer.

Or is there a way to configure the excludes via SeContainerInitializer?
Because that is exactly what I would like to have I think, not having any beans in the integ test sources being added explicitly and then using SeContainerInitializer#addBeanClasses to add the bean classes I want for the current test.

But anyway, this was very valuable information, because I actually need <exclude ...><if-class-not-available .../></exclude> in my production code.
Up to now the respective beans just failed to be generated with WELD​-000119, but as this was on INFO level, I just accepted it, but having class-dependent excludes is much better of course.

Why am I explaining that? To illustrate what happens with your current solution (assuming discovery mode "all") - Weld will discover the class annotated with @Alternative on its own a register it, the bean isn't enabled, so it isn't used. The you come in and register another annotated type manually (for the same class) and that one comes without @Alternative and will be used.
So you are basically duplicating that class as a bean (but there will be no clash in this case).

Yeah, I was aware that this is what I'm doing, I just didn't know about the other ways.
So your explanations and expert insight is most appreciated, thanks again.

> .addAnnotatedType(it, null)

Don't use null in place of ID, pick some; even if it's equal to bean's class name plus some suffix. The reason for ID is that there is a situation where you can have multiple annotated types for one underlying class (if I recall correctly).

I see, I just copied the variant with null from BeforeBeanDiscoveryImpl#addAnnotatedType(javax.enterprise.inject.spi.AnnotatedType<?>) where it uses null as second parameter.
Why "plus some suffix"?
Is any random value fine, like for example then beforeBeanDiscovery.addAnnotatedType(clazz, clazz.getName() + " " + UUID.randomUUID())

> as addAnnotatedType(AnnotatedType<?>, String) does not return an AnnotatedTypeConfigurator where I could remove the @Alternative annotation.

Using configurator is just as fine, but like I said above, you might want to look into other ways to conditionally add a bean.

That was more a sad gibe, that addAnnotatedType(AnnotatedType<?>, String) should better also return an AnnotatedTypeConfigurator, but I guess this is not possible due to binary compatibility with code compiled against earlier versions. :-D

Hope this isn't too confusing

Not at all, but rather educating