Page History

The changeSet for the physical runtime is meant to be very precise and the builder's role is to turn that into runnable code. So it's not SCDL stuff but much lower level. The idea is to keep the builder very simple (and hence quite testable) that means there is a bit more work in the conversion from logical to physical, bascially a "portable" builder.
The conversion will use the introspection results from the store to generate the builder configuration, for example, suppose introspection discovers a component has an @Init method, we store that in the introspection result. The ContributionProcessor might load the java classes to introspect the annotations. (It may not actually load the class using a class loader since it could parse bytecode e.g. with ASM). But the result is an extended implemenation description. We need a langauge neutral form for that so ideally it can be used on both a Java and Native platform. It's something that goes beyond the componentType and it's the PojoComponentType type of thing, but more.

The idea of "portable builders" is about separating the node  responsible for domain assembly from the nodes running component  implementations. In a heterogeneous federation, it could be the  assembly node(s) are running C++ but the user wants to add a Java  component that will actually run on a Java node. If the introspection  results for the Java contribution are portable, it would be possible  for the C++ to set up the physical configuration for the Java  builder; alternatively, it could delegate that to a service running  in a native Java environment. Similarly, if the component was in some  portable language (like Ruby or XSLT), then the configuration could  be done on a Java node and passed to a C++ runtime node.