Add check for bundle name for components in services.xml to match artifactId during package step

[jobergum]

Saves lifes and resources when misspelling bundle names in services.xml which gets deployed all the way and is not clear before your deployment job has been waiting for a container to start which it fails to do due to a silly misspelling (artificatId was paged_tensor)

Container.com.yahoo.jdisc.core.StandaloneMain JDisc exiting: Throwable caught: exception= java.lang.IllegalArgumentException: Could not create a component with id 'ai.vespa.searcher.KeyValueSearcher'. Tried to load class directly, since no bundle was found for spec: paged_tensors.

[gjoranv]

There are three cases to consider here:

1. components with only componentId (bundle name = componentId)
2. components with classId but no bundleId (bundle name = classId)
3. components with explicit bundleId

In all cases, if the bundle does not exist, a class lookup is performed in

1. container-disc
2. jdisc_core (system bundle)

I would say that in case 3, the current behavior is wrong and we should just fail. However, we still would have to wait for the container to start for a decent error message. Plus, it would not help the other cases. To handle all cases, we would need a registry of all our internal bundles in the config-model, plus all available components in container-disc and jdisc_core, and keep it updated. This is not maintainable.

Case 1 is probably most common among users that experience this issue. The implicit class lookups make it hard to come up with a foolproof solution. An alternative be to look for application package bundles that are not mentioned in any components in the services.xml, and warn about those upon deployment. However, this is also valid if the classes are used from another application bundle. But this solution might be "good enough" for applications with only one bundle for the time being.

The proposed warning may have to be removed in the future, if we change how components are instantiated. We could allow user bundles to implement an interface of ours (or the Java platform) and prefer the provided user class instead of our default class. (This is not currently possible AFAIK, because all components must be declared in services.xml or the config-model. But, we are considering a move towards a less declarative model and more "magic".)

[bratseth]

I would say that in case 3, the current behavior is wrong and we should just fail.

Agreed.

To handle all cases, we would need a registry of all our internal bundles in the config-model, plus all available components in container-disc and jdisc_core

We could auto-generate it.

[gjoranv]

List available application bundles in the error message.

[gjoranv]

Fixed in #25423