Allow third-party library developers to create facilities that will behave in similar way to Granitic's
built-in facilities:
Default configuration and component definitions burnt into the application executable
Earlier access to the IOC container
Enabled and disabled via the Facilities.FaciltyName config path
Dependencies on other facilities can be declared
Background
Third party libraries for Granitic applications can provide code and component definitions which are linked to the application during the grnc-bind phase of the build process via a command line argument giving the absolute path to the
library code. This quickly gets unwieldy with more than a couple of dependencies and has a number of other problems:
Build scripts need to know absolute paths of libraries on disk (even if the library was downloaded via a go.mod file)
Default configuration cannot be included in the complied executable (must all be provided at run time)
Components do not have programmatic access to the container
The solution to this problem is to allow libraries to declare themselves as defining one or more facilities. grnc-bind will then scan all first-order dependencies in an application's go.mod file to see if they contain facilities and include those facilities (code and default configuration) in the generated binding file.
Implementation
A library will have a folder facility at the top level. If this folder contains a file facilities.json (or .yml) the library will be considered to have one or more facilities.
The default configuration for the facilities will be expected to be in either facility/config.json or facility/config/*json (or YAML equivalents)
The component definition for the facilities will be expected to be in either facility/comp.json or facility/comp/*json (or YAML equivalents)
Summary
Allow third-party library developers to create facilities that will behave in similar way to Granitic's built-in facilities:
Facilities.FaciltyName
config pathBackground
Third party libraries for Granitic applications can provide code and component definitions which are linked to the application during the
grnc-bind
phase of the build process via a command line argument giving the absolute path to the library code. This quickly gets unwieldy with more than a couple of dependencies and has a number of other problems:The solution to this problem is to allow libraries to declare themselves as defining one or more facilities. grnc-bind will then scan all first-order dependencies in an application's go.mod file to see if they contain facilities and include those facilities (code and default configuration) in the generated binding file.
Implementation
A library will have a folder
facility
at the top level. If this folder contains a filefacilities.json
(or .yml) the library will be considered to have one or more facilities.The default configuration for the facilities will be expected to be in either
facility/config.json
orfacility/config/*json
(or YAML equivalents)The component definition for the facilities will be expected to be in either
facility/comp.json
orfacility/comp/*json
(or YAML equivalents)The facilities.json file will look like:
For example:
Where
FacilityBuilder
is a type in the library that implements (TBD)DependsOn
is an array of the names of the other facilities (internal or third party) that must be enabled in order to use this facilityEnabled
is whether the facility defaults to enabled or disabledCompatibility