Dependency Resolution questions.

[Graham Jenson <gr...@maori.geek.nz>]

Hello, some questions from an interested party.

1) I was wondering what method you are using (will use?) for your dependency
resolution?
Eclipse P2 uses SAT4J SAT solver, as I believe Maven will also move to (
http://docs.codehaus.org/display/MAVEN/SAT+Based+Dependency+Resolution).
Nimble from Paramus (http://www.paremus.com/products/products_nimble.html)
uses a custom resolver.

2) What user properties/policies will you allow to let them augment the
resolution process to get the system they want?
What user input can be involved, for instance pinning in APT-GET allows the
ranking of repositories when getting components.

3) Will you also aim for bundle pooling functionality?
http://wiki.eclipse.org/Equinox_p2_Getting_Started#Bundle_pooling
Multiple applications running from the same set of components.

4) a quote from your site :
http://incubator.apache.org/ace/software-architecture.html#SoftwareArchitecture-Domains
"Summing it up, it is important to make sure that you end up deploying sets
of bundles that work together well in the environments in which they're
deployed."
Any ideas on how this can/will be accomplished, giving all the problems that
dependency management can have?

Cheers
Graham

Re: Dependency Resolution questions.

[Marcel Offermans <ma...@luminis.nl>]

Hello Graham,

Somehow I completely missed this mail. Upon scanning my mail folder I found it, and since nobody replied yet, I'll have a go at it. :)

On Jun 14, 2010, at 17:59 , Graham Jenson wrote:

> Hello, some questions from an interested party.
> 
> 1) I was wondering what method you are using (will use?) for your dependency
> resolution?
> Eclipse P2 uses SAT4J SAT solver, as I believe Maven will also move to (
> http://docs.codehaus.org/display/MAVEN/SAT+Based+Dependency+Resolution).
> Nimble from Paramus (http://www.paremus.com/products/products_nimble.html)
> uses a custom resolver.

We are currently following the whole resolver discussion with interest. Our first pick right now would be the Felix resolver, as soon as that's able to run stand-alone (work on that is progressing nicely). At the last EclipseCon I learned that the P2 resolver does not support uses constraints. I don't follow that project on a day to day basis, but that was quite a showstopper to me. I have not looked at the Nimble resolver either I must admit.

> 2) What user properties/policies will you allow to let them augment the
> resolution process to get the system they want?
> What user input can be involved, for instance pinning in APT-GET allows the
> ranking of repositories when getting components.

Let's start with user properties. The system has been designed so each "entity" (artifact, feature, distribution, target) can support arbitrary properties that either come from the system or are supplied by the user.

Going from there, associations (currently created by drag and drop and not user configurable, except for static vs dynamic with respect to bundle versions) can include arbitrary filter conditions based on those properties, so anything that can be written as an expression, can be used here.

Other than that, currently we don't have any policies or mechanisms in place yet, but feel free to dive in or come with suggestions!

> 3) Will you also aim for bundle pooling functionality?
> http://wiki.eclipse.org/Equinox_p2_Getting_Started#Bundle_pooling
> Multiple applications running from the same set of components.

For deploying, we directly install bundles in the OSGi framework. We do not use a plugins directory like Eclipse does, so there is nothing to pool. In theory we could try and let frameworks share part of their bundle cache, but I don't think any of the current frameworks supports that. I certainly have not seen anything in the spec about it yet.

> 4) a quote from your site :
> http://incubator.apache.org/ace/software-architecture.html#SoftwareArchitecture-Domains
> "Summing it up, it is important to make sure that you end up deploying sets
> of bundles that work together well in the environments in which they're
> deployed."
> Any ideas on how this can/will be accomplished, giving all the problems that
> dependency management can have?

Well, this may sound a bit like I'm taking the easy way out, but the best way to accomplish that is to actually test such deployments before you send them to production. So set up a staging area where you can try out these updates. The problem is far larger than just "properly resolving" too, so even if you succeed in completely checking that aspect, you still need to do things like functionally test your application. That part is something I'm personally still looking at, trying to include system tests in such a way that they can be run as part of the deployment so we can actually test an update in different ways.

Greetings, Marcel