{"push_id":561159649,"size":1,"distinct_size":1,"ref":"refs/heads/2.2-ext-on-ext-action","head":"d57c056c080fb724056dd092b5946958f051f1ca","before":"f4753fe2da2db7a01c4c1c0d4513fa270a620ac2","commits":[{"sha":"d57c056c080fb724056dd092b5946958f051f1ca","author":{"email":"baf86c3afff256eaf1c2be364283246836126d06@gmail.com","name":"Jacob Hansson"},"message":"Allow kernel extensions to depend on other kernel extensions.\n\n- Introduce a simple algorithm for deducing the required instantiation-order\n  of kernel extensions by looping over factories, instantiating each one we\n  have all dependencies for, until none remain.\n\n  Not super efficient, but since kernel extensions are relatively few and only\n  instantiated at boot time, this shouldn't be an issue any time soon.\n\n  This will allow us to move to a more modular approach over time, with major\n  components declaring which components they require, and each properly\n  implementing lifecycle.\n\n  It does move further in a direction that risks obfuscating the dependency\n  tree - but frankly the dependency tree is hard to follow anyway, and this way\n  it will at least be explicitly expressed in the KernelExtensionFactory\n  classes.\n\n  This is desired, although not required, by Mjolnir, which wishes to consist\n  of multiple services with clean interfaces between each other and other\n  database services. Rather than introducing more manually written component\n  wiring code, this solves it in a general way for services in the kernel.","distinct":true,"url":"https://api.github.com/repos/jakewins/neo4j/commits/d57c056c080fb724056dd092b5946958f051f1ca"}]}