ObjectWeb Consortium
Search ObjectWeb Mail Archive: 

Advanced Search - Powered by Google

Mail Archive Home | oscar List | October 2005 Index

<--  Date Index  --> <--  Thread Index  -->

Re: [oscar] Resolving and Wiring in R4

Nico Goeminne wrote:

Well, in that case, people could write bundles that are correctly in terms
of manifest syntax, imports and exports, but that would never be able to be
deployed on a certain framework deployment. It will definitely be a
difficult bug to figure out. Maybe there should be some tool, or the
framework would have to provide adequate resolving information (exceptions).

Well, this was always the case for incremental installation of bundles.

Isn't resolving already a costly operation.

Yes, but requiring that the resolver always choose the "optimal"
solution would be more costly...still, nothing prevent an implementation
from doing it that way.

In R3 I did resolving by, trying to resolve the whole set of bundles at
once, and reducing the set of possible candidates until a stable set could
be found. Now it seems the incremental approach should be used. When using
that approach, isn't the order of bundles you wish to resolve not an issue?
For example when resolving a bundle with a lot of constraints on the wire
it's possible to chose a set of wires, when first resolving the lesser
constrained bundles and wiring those, the complex bundle couldn't be
resolved anymore.

I essence, yes, it is possible that you cannot resolve bundles. However,
you can either view this as a good thing or a bad thing. The idea behind
"uses" constraints is not to encourage developers to make even more
complex bundles, but to allow them to model the actual constraints that
exist so that the framework can ensure consistency. That's the good
part, right? Because in the past there was a simple consistency model
based on the assumption that everyone saw all the same versions of
shared classes.

Maybe the resolving algorithm should be described more. Now it's rather more
complex and misinterpretations could occur, so deployment of the same set of
bundles could end up in different sets of bundles being resolved. For now
I'll wait and see what happens when Eclipse/KF/Felix are R4 compliant.

Well, you don't have to wait for the "uses" stuff now. Do some tests on
Felix and Eclipse and see what happens. I am sure we'd all be
interested. :-)

There was debate about how much implementation detail to put in to the
resolver algorithm, but there was a deliberate decision to eventually be
more loose. The end result is that it is definitely possible that a set
of bundles could resolve on one framework, but not another. I tend to
believe that this will be the rare case.

The spec does give recommended precedence rules, such as favoring
already resolved packages, then higher version numbers, and then lower
bundle IDs.

Ps. I agree that the "Optional"-things in the spec leads to even more
confusion in some cases. The drive for R4 came out of the need for multiple
package versions. Maybe it went a little to fast. An open development of the
specs could lead to more adaptation and more feedback from users, and other
(outside the members) feedback. Regarding to that, what was discussed on the
open source panel at the world congress?

Trying to make the process more open was discussed, but nothing concrete
was proposed.

-> richard

<--  Date Index  --> <--  Thread Index  -->

Reply via email to:

Powered by MHonArc.

Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster.