Service provider module dependency resolving webrev

[Paul Sandoz]

On Jun 20, 2012, at 3:37 PM, Alan Bateman wrote:

> On 19/06/2012 17:53, Paul Sandoz wrote:
>> :
>> I would need to verify but IIUC it will fail, since the service provider dependency is optional module P will not be included in the configuration, the resolver will calculate a successful solution, but will barf when verifying the optional constraint.
>> 
>> It's swings and roundabouts :-) i can come up with situations where the current approach may produce odd results or barf. For example another that happens to be processed before M:
>> 
>>   M'
>>     requires X @>  1.0;
>> 
>> 
>> I am leaning towards a solution that may present a more consistent results to developers. With the current solution it can be harder to predict or understand how the system is affected by the presence of service provider modules since service consumer modules are decoupled from service provider modules.
>> 
>> Paul.
> For this one example (M') then I assume today that it just means that the service module P is be left out of the configuration (assuming requires optional service) as that the result is M, M1, X at 2.0.
> 

Yes.


> In any case, i think it is critical bit is that the result can be "explained" to the user as optional dependencies and services means that the solution isn't always obvious, and in some cases it's possible to have several solutions too.
> 

Yes, that was a motivation to separate out the resolution.


> As to the proposed approach then I think it will continue to some predictability issues, at least when there are multiple service provider modules involved (maybe implementing different service interfaces) with transitive dependencies on the same module, but different versions.
> 

Indeed. I wanted to bucket things into phases as i think that will make a little easier to grok:

Phase 0: application module (explicit) dependency resolution

Phase 1: service provider dependency resolution as a result of traversing service consumer modules in Phase 0

Phase 2: service provider dependency resolution as a result of traversing service consumer modules in Phase 1

...

Phase N: service provider dependency resolution as a result of traversing service consumer modules in Phase N - 1

Paul.