|Re: [p2-dev] Dependency management synergies|
I'm glad to hear from you and your team. Trying to unify/share is definitely interesting and after taking a brief look at the goals of Mercury, I think there is place for an even bigger collaboration than just at the dependency resolution level. For example transport, repository API, version range mgt, etc. and even probably higher up, but we should talk about that someplace else. Will you or anyone from your group attend EclipseCon?
Now when it comes down to resolution, I agree that there is an even larger potential for collaboration and we should explore this opportunity seriously. I initially designed p2 metadata with the goal of being able to express any kind of dependency that could be found out there, unfortunately I got caught back by the reality of shipping p2 in 3.4 and since then I never got much time to focus on this again. So I'm definitely excited to the idea of continuing this work and see this potential collaboration to finish this up for good :) A few things that I had in mind relied around _expression_ of negation, or'ing, removal of singleton as a special concept, use of dependency on something else than version ranges, etc.
> On the side issue: P2 uses an indirect way of creating those inequations
> - creates a file and then feeds it to solver. In Mercury we took a
> different approach and bypass file stage, feeding expressions directly
> to the solver, which is more efficient. If you'd like we can work
> together to fix that.
I think Daniel covered that one. This is work in progress in a branch that will find its way in the main codebase in 3.5.
The main reason for using an opb file was to ease the debugging and also run our encoding against other opb solvers to compare perfs etc.