Open peter-mcclonski opened 4 hours ago
Q: There are multiple potential paths to resolution here. We can either improve the behavior of the existing method of retrieval, or deem that method undesirable, and add an improved method of retrieving the ModelInstanceRepository
instance. The former has the advantage of not requiring changes to existing downstream code, while the latter is probably the overall 'better' approach in a vacuum.
Feedback required from maintainers.
Currently, the only mechanism to retrieve the configured
ModelInstanceRepository
implementation instance, and thus to interrogate the underlying schemas informing generation, is to use this static method provided in theModelInstanceRepositoryManager
class:Suppose a fermenter-based project
Project_A
provides their ownModelInstanceRepository
implementation,MIR_A
. Within the project's generators, they may be forced to include code such as the following:This will work fine for this initial project. However, if another project
Project_B
is created to extendProject_A
, with its ownModelInstanceRepository
implementationMIR_B extends MIR_A
, then existing calls of the above snippet will fail with null pointer exceptions. This is due to the naive string-name lookup method found in thegetMetamodelRepository
method above. Extension patterns are thus inhibited.