Container assembly: aggregator modules vs real wiring code

Summary

The seven audited modules contain no Maven aggregator: none declares <packaging>pom</packaging>. Aggregation happens only in the repo-root pom.xml, which lists application, component, container, container-dev, container-search-and-docproc, container-test (pom.xml:28-63) and standalone-container (pom.xml:106) as build modules. Four of the seven are build-only artifacts: container, container-dev, container-test are empty dependency-umbrella jars (zero Java sources), and container-search-and-docproc is a source-less container-plugin that merges container-search, docproc and searchlib into one OSGi bundle. Real assembly is layered: a config-model layer (services.xml -> model objects), jdisc_core primitives (ContainerBuilder, ContainerActivator), and the container-disc runtime (ConfiguredApplication plus com.yahoo.container.di.Container), which the standalone and embedding entry points reuse rather than reimplement. See index for sibling notes.

Aggregator vs code

module	packaging	Java sources	pom/README evidence	verdict
container	jar (pom.xml:18)	0	pom.xml:3-4 “collects all dependencies … external Vespa API”; README: “Convenience dependency … developing OSGi bundles”	build-only umbrella jar
container-dev	jar (pom.xml:18)	0	pom.xml:3 “collects all common dependencies of Vespa-internal modules”; README	build-only umbrella jar
container-test	jar (pom.xml:19)	0	pom.xml:3-4 “dependencies needed to test container components”; README: test-scope companion to container	build-only umbrella jar
container-search-and-docproc	container-plugin (pom.xml:17)	0, no src/	pom.xml:273 bundleType=CORE; pom.xml:282 Bundle-SymbolicName; README: “Packages the search and document processing modules … into one bundle”	build-only bundle assembler
standalone-container	container-plugin (pom.xml:14)	6 main	README: “Standalone JDisc Container … without the configuration system”	real code
component	container-plugin (pom.xml:16)	21 main	Component.java:13 interface; ComponentRegistry.java:27	real code (component model)
application	jar (pom.xml:14)	18 main	README: “API for creating Vespa applications from Java code”	real code (embedding API)

Assembly code paths

1. Bundle production: bundle-plugin defines the container-plugin packaging (plexus components.xml maps package phase to generate-osgi-manifest + assemble-container-plugin), so component, standalone-container and container-search-and-docproc ship as OSGi bundles; application stays a plain jar.
2. Config model: StandaloneContainerApplication.createContainerModel (StandaloneContainerApplication.java:238) parses services.xml into VespaModel/ContainerModel via ContainerModelBuilder or ConfigServerContainerModelBuilder, yielding com.yahoo.vespa.model.container.Container; createConfiguredApplication (line 128) then pulls ConfiguredApplication from a Guice injector with StandaloneSubscriberFactory bound.
3. jDisc core: ContainerBuilder is “the inactive, mutable Container”, activated via ContainerActivator#activateContainer (ContainerBuilder.java:20-23); ApplicationLoader exposes both operations (ApplicationLoader.java:58,63).
4. Runtime assembly: ConfiguredApplication implements Application (ConfiguredApplication.java:83). start() (line 172) creates a builder, createConfigurer (line 178), then initializeAndActivateContainer -> activator.activateContainer(builder) (line 336). doReconfigurationLoop (line 363) waits per config generation for a fresh component graph from com.yahoo.container.di.Container.waitForNextGraphGeneration (di/Container.java:81, holding ComponentDeconstructor, Osgi, bundle configs at lines 48-54) and hot-swaps containers. Registries land on the com.yahoo.container.Container singleton (Container.java:23, setComponentRegistry line 95).
5. Bundle wiring: BundleInstantiationSpecification (id/classId/bundle; CONTAINER_SEARCH_AND_DOCPROC line 17, fromSearchAndDocproc line 40) maps components to bundles; di.Osgi.installPlatformBundles/useApplicationBundles/resolveClass (Osgi.java:27,36,53) installs and resolves per generation.

Standalone vs search container: standalone swaps real OSGi for ClassLoaderOsgiFramework, a mock framework loading bundle jars via URLClassLoader (ClassLoaderOsgiFramework.java:51,83), and Felix is only a test dependency (pom.xml:77-78); the production container keeps the injected real OsgiFramework, subscribes config from config-admin, and registers in slobrok. Embedding path: JDisc (JDisc.java:38,54) wires jdisc TestDriver + ClassLoaderOsgiFramework; fromServicesXml (line 81) materializes a temp package via StandaloneContainerRunner. All of this runs inside container-jdisc.

Open questions

• Production implementation of di.Osgi (installPlatformBundles/useApplicationBundles) lives outside the audited modules; identity unverified.
• container-search-and-docproc README claims it “contains the ApplicationStatus handler”, but the module has no sources; current home unverified.
• ComponentGraph construction internals (container-disc di/componentgraph) not read in this pass; ownership split between HandlersConfigurerDi and di.Container only partially traced.