[Core] Rework the component factory

[alxbilger]

Rework the component factory: introduce ComponentFactory

Summary

This PR replaces the legacy ObjectFactory with a new, simpler ComponentFactory, and removes (or disables) the tooling that was built on top of the old factory internals (ComponentLibrary, most of CategoryLibrary, SofaLibrary, and JSON dumping). ObjectFactory is kept as a type alias for backward source compatibility, and a legacy registration path is preserved so existing registerObjects(...) call sites keep compiling — but a full migration to the new API is strongly encouraged, and some behavior is intentionally not preserved (see Breaking changes below).

Motivation

The previous ObjectFactory stored components in a std::map<std::string, ClassEntry>, where each ClassEntry internally held its own map of per-template creators (ObjectTemplateCreatorMap). This design made a few things awkward or impossible to extend cleanly:

• Selecting the right template instantiation for a component relied almost entirely on each class's static canCreate(...) method, which mixed instantiation logic with selection logic.
• There was no clean way to select a template using anything other than the historical template="..." XML attribute, which becomes unreadable once a component has more than one template parameter (e.g. template="Vec3,Hexahedron").
• There was no notion of a "module" a component belongs to, which is a prerequisite for future work on component namespacing (see [#2512]([all] Add namespaces in the factory and a python-like import mechanism #2512)).
• ComponentLibrary / CategoryLibrary / SofaLibrary (used mainly by the old Modeler tooling) were tightly coupled to ObjectFactory internals, which made the factory harder to change safely.

What changed

New registry model

The registry is no longer a map of ClassEntry objects, each containing a nested map of per-template creators. It is now a flat std::vector<ComponentRegistrationData::SPtr>, where each element represents exactly one (component name, template) instantiation.

• Registering the same component name multiple times is allowed; duplicate/ambiguous registrations are reported at runtime via an error message instead of being rejected at compile time.
• Each entry stores its own creator, description, module name, aliases, authors, license, documentation URL, template attributes, instantiation priority, and an optional template-deduction rule.
• Creators (ComponentCreator<T>, in the new ComponentCreator.h) are intentionally simplified: they always use the component's default constructor via sofa::core::objectmodel::New<T>(), instead of relying on a per-class static create(...) function. This is a deliberate simplification — classes that relied on custom create() logic will need to be checked.

Module-qualified names

Components now register with a module name. This makes it possible to instantiate a component using the moduleName.componentName syntax (e.g. Sofa.Component.MechanicalObject), in addition to the plain component name. This isn't used for namespacing yet in this PR, but it lays the groundwork for it (see [#2512](#2512)).

Template selection: deduction rules replace canCreate

Instead of relying on each templated class's static canCreate(context, arg) to decide whether it's a valid candidate, template selection is now driven by explicit template deduction rules (TemplateDeductionRules.h):

• BaseTemplateDeductionRule — the interface, checked against a BaseContext and a BaseObjectDescription.
• OtherComponentsInContextDeductionRule<T...> / MechanicalStateDeductionRule<DataTypes> — matches based on what other components already exist in the current context (e.g. a MechanicalState<DataTypes> sibling).
• CanCreateDeductionRule<T> — a compatibility shim that falls back to the old T::canCreate(...) behavior, used by the legacy registration path.

When multiple candidates remain ambiguous after filtering, ComponentFactory::createComponent(...) resolves the ambiguity in this order of priority:

1. Exact match on all declared template attributes.
2. The legacy template="..." keyword, matched against the full declared attribute list.
3. Partial match on template attributes.
4. General deduction rules (fallback, lowest priority).

If ambiguity remains after all filters, the first candidate (sorted by instantiationPriority) is used, and a warning is emitted listing the other candidates.

Named template attributes instead of the template keyword

Instead of template="...", a component can declare named attributes for its template parameters and be instantiated using those names directly. For example:

<!-- Before -->
<MechanicalObject template="Vec3"/>
<CorotationalFEMForceField template="Vec3,Hexahedron"/>

<!-- After -->
<MechanicalObject dofType="Vec3"/>
<CorotationalFEMForceField dofType="Vec3" elementType="Hexahedron"/>

This scales much better than template="..." once a component has more than one template parameter, since attribute order no longer matters and each parameter is self-documenting. The legacy template="..." attribute is still supported for backward compatibility.

Simplified registration API

Registering a component in the factory now looks like this:

factory->registerComponent(
    core::CreateComponent<CorotationalFEMForceField<DataTypes, ElementType>>("CorotationalFEMForceField")
        .withModule(MODULE_NAME)
        .withDescription(std::string(description))
        .addTemplateAttribute<DataTypes>("dofType")
        .addTemplateAttribute("elementType", sofa::geometry::elementTypeToString(ElementType::Element_type))
        .withDeductionRule<core::MechanicalStateDeductionRule<DataTypes>>()
);

core::CreateComponent<T>(componentName) is mandatory as the entry point: it builds the creator for T and returns a builder that requires a module name (.withModule(...)) and a description (.withDescription(...)) before it can be committed — the code won't compile without them. From there, .addAlias(...), .addTemplateAttribute<T>(name) / .addTemplateAttribute(name, value), .addAuthor(...), .withLicense(...), .withDocumentationURL(...), .withDeductionRule<Rule>(), and .withInstantiationPriority(...) are all available as needed.

Component registration functions were migrated to this new API, for example registerMechanicalObject, registerRequiredPlugin, registerSparseLDLSolver, and registerCorotationalFEMForceField.

Legacy registration path

To avoid breaking every existing registerObjects(...) call site immediately, a compatibility path is preserved:

• LegacyComponentRegistrationData (replacing ObjectRegistrationData) supports the old .add<T>()-based, macro-style registration.
• ComponentFactory::registerObjects(LegacyComponentRegistrationData&) converts a legacy registration into one or more ComponentRegistrationData entries, including deriving a CanCreateDeductionRule<T> for each one so old canCreate-based classes keep working.
• ObjectFactory is now simply using ObjectFactory = ComponentFactory;, and ObjectRegistrationData is using ObjectRegistrationData = LegacyComponentRegistrationData;, so most existing call sites should keep compiling.

All of the legacy-only surface (ClassEntry, registerObjects(LegacyComponentRegistrationData&), createObject(...), ObjectFactory::getInstance(), ObjectFactory::CreateObject(...), ObjectFactory::HasCreator(...)) is now marked deprecated via new macros in config.h.in (SOFA_CORE_DEPRECATED_OBJECTFACTORY_*), targeting removal between v26.12 and v27.12/v27.06 depending on the symbol. Use MainComponentFactory::getInstance(), MainComponentFactory::CreateComponent(...), and MainComponentFactory::HasCreator(...) going forward.

Component creation flow (ComponentFactory::createComponent)

The new creation flow, in ComponentFactory.cpp, adds a few improvements over the old one:

• Renamed/moved/dealiased/uncreatable component detection: known issues are reported directly by name via sofa::helper::lifecycle tables before attempting creation.
• Typo suggestions: if a requested component name isn't found, the closest matching registered names are suggested in the error message (via sofa::helper::getClosestMatch).
• Unloaded-plugin filtering: candidates whose module is a currently unloaded plugin are filtered out before selection, and a clear error is reported if all candidates depend on unloaded plugins.
• Auto-loading: if a component is requested using its fully-qualified moduleName.componentName form and that module/plugin isn't loaded yet, the factory attempts to load it automatically and register its objects.
• Each created component now records the name it was actually instantiated under via a new factoryName data field on BaseComponent (see below), which may differ from its getClassName() when created through an alias.

BaseComponent::d_factoryName

BaseComponent gains a new, read-only Data<std::string> d_factoryName ("Component name registered into the factory"), set by ComponentFactory right after parse(...). This records the exact name used to instantiate the component (which may be an alias, e.g. LegacyAlias rather than DummyComponent), which was previously not recoverable from the object itself.

Tests

• Added Sofa/framework/Core/test/ComponentFactory_test.cpp, a comprehensive new test suite covering: basic creation, creation via alias, hasCreator, per-target entry listing, single- and two-template-attribute selection (both via named attributes and the template keyword), duplicate/ambiguous registration warnings, instantiation priority, fully-qualified module.component creation, typo suggestions on unknown components, and both the new and the legacy (LegacyComponentRegistrationData) registration paths, including legacy templated registration.
• The old ObjectFactory_test.cpp and ObjectFactoryJson_test.cpp are commented out for now rather than rewritten, since they test behavior (raw ClassEntry access, JSON dump) that this PR does not fully port over yet.

Breaking changes

⚠️ This PR removes or disables functionality without a deprecation cycle. In particular:

• ComponentLibrary is now just using ComponentLibrary = DeprecatedAndRemoved; — its implementation is entirely gone.
• CategoryLibrary keeps its class shell for source compatibility, but nearly every method (addComponent, endConstruction, getName, getComponents, getComponent, getNumComponents, createComponent, and even the constructor) is now = delete. Only the static getCategories() helpers still work.
• SofaLibrary (.h/.cpp) is fully commented out. Anything built on top of it (e.g. Modeler-style component browsing) will not compile.
• ObjectFactoryJson dumping (ObjectFactoryJson::dump(...)) is commented out/disabled; it relied directly on the old ClassEntry/creatorMap structure and hasn't been ported to the new registry yet. This is a known gap.
• SceneCheckMissingRequiredPlugin and SceneCheckUsingAlias: their core logic is commented out, since both relied on ObjectFactory::getEntry(...)/creatorMap and ObjectFactory::setCallback(...), which no longer exist in the same form. These scene checks are effectively no-ops until ported.
• Any code that instantiated components by directly constructing them without going through ObjectFactory/ComponentFactory and relying on a custom create(...) static method may behave differently now that ComponentCreator<T> always uses the default constructor.

If your code depends on any of the above, it will need to be updated or ported as part of, or after, this PR.

Follow-ups (not in this PR)

• Port ObjectFactoryJson::dump to the new ComponentRegistrationData model.
• Re-implement SceneCheckMissingRequiredPlugin and SceneCheckUsingAlias against ComponentFactory.
• Decide whether/how to reintroduce SofaLibrary/category browsing for tooling that needs it, on top of the new registry.
• Continue migrating remaining registerObjects(...) call sites to the new registerComponent(...) API and retire LegacyComponentRegistrationData.
• Namespace support building on the new module-qualified names (see [#2512]([all] Add namespaces in the factory and a python-like import mechanism #2512)).

[ci-depends-on https://github.com/sofa-framework/SofaPython3/pull/623]

---

By submitting this pull request, I acknowledge that
I have read, understand, and agree SOFA Developer Certificate of Origin (DCO).

---

Reviewers will merge this pull-request only if

• it builds with SUCCESS for all platforms on the CI.
• it does not generate new warnings.
• it does not generate new unit test failures.
• it does not generate new scene test failures.
• it does not break API compatibility.
• it is more than 1 week old (or has fast-merge label).

[damienmarchal]

I would be happy to discuss this point and it is worth having a look there as there was lengthy discussion on the topic in the past.

If I remember correctly, the general idea was that both canCreate and create should be removed.
The observation was to canCreate/create was mostly used to implement two different things:

• template deduction/inference
• component checking or initialization (regarding input/output correctness checking)

To move forward the idea was thus to:

• 1. move the canCreate code related to templateDeduction in a dedicated mecanism and moving the related code from canCreate into something called deduction rules => (eg: progressive deployement in: [Sofa.Core] Implements a template deduction system in the object factory #3938 then [all] Replace canCreate with the getTemplateFromMechanicalState deduction rule #3987 then [all] Replace the complex canCreate with deductionRule #3992).
• 2. move the initialization checking related code out of the canCreate/create into the init() function. The underlying idea is that an object must always be creatable. It can then be initialized by setting its input data and link, then initialized by calling init(). This was more the kind of move done in: [all] Replace canCreate with init() when approapriate #3990
• 3. refactor canCreate as in [All] Refactor create/cancreate in ObjectFactory #5195

If there is a deep refactoring of ObjectFactory, I would also recommand adding the namespace features and user define aliases suggested in:
#2512 and

And also to remove the use of GetClass which cause a code bloat.

[damienmarchal]

If we are refactoring component factory could we drop this please.

If I remenber correctly this single line is causing a compilation code bloat (just to provide the class name). When we are registering a component into the factory the class name could be passed with a std::string instead of relying a complex custom "reflection" system.

[alxbilger]

For now, the only reason I had to keep this function was to list components deriving from another, using the method hasParent in BaseClass. If we find another mechanism for that (or if we remove this feature), we can remove this usage in the factory.

[sofabot]

[ci-depends-on] detected during build #13.

To unlock the merge button, you must

• Merge or close fix after #6162 SofaPython3#623
  For this build, the following CMake flags will be set
  -DSOFAPYTHON3_GIT_REPOSITORY='https://github.com/sofa-framework/SofaPython3'
  -DSOFAPYTHON3_GIT_TAG='4821cfe6971eb9741675bd61e451e0e574986362'

[sofabot]

[ci-depends-on] detected during build #14.

To unlock the merge button, you must

• Merge or close fix after #6162 SofaPython3#623
  For this build, the following CMake flags will be set
  -DSOFAPYTHON3_GIT_REPOSITORY='https://github.com/sofa-framework/SofaPython3'
  -DSOFAPYTHON3_GIT_TAG='1336e98e4bb16cc274edd3fbf9c6b1070de926ad'