Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] [prov] Is the director a constraint solver

Hi,

In the ITEA OSIRIS project (http://www.itea-osiris.org) we are carrying out a strong effort to automate bundle deployment. I have been personally involved because of my PhD dissertation (on automated software deployment) and the followed approach is quite similar to what you are proposing.

Solving cycles, detecting dependencies to JRE versions (some packages are already available in the runtime) and distinguishing optional dependencies was a tough work. In order to help us carry on we built a graphical visualizer on top of Eclipse Zest to understand and filter dependencies (some come from Require-Bundle others from Import-Package). Attached you can find an image of the visualizer solving Eclipse JDT UI component.

A bundle repository is part of the architectural elements included in the developed solution.We have a beta version of the repository available at http://pereira.dit.upm.es:9090/repository/index.html. For testing purposes we populated the repository with bundles included in Eclipse 3.3 (a prior version to Europa, but the repository can be automatically fed with new bundle versions), some of the Apache Felix bundles and also OS4OS bundles (http://forge.os4os.org).

Under the hood, the repository is running on Equinox with EMF-based models that describe bundles. You can have a grasp of the information included in the models following any of the links included in the "Bundles List" section (takes a while to load, it is still a beta version ;-)

Resources can be found at the repository using the Web interface available at http://pereira.dit.upm.es:9090/repository/find.html. Searches support SQL wildcards (%, _ and so on) in the resource name and version ranges (e.g. [0.0.0, 1.3.0]).

In addition to the HTML interface, the repository also exposes its functionalities by means of Web services.WSDL files can be found at http://pereira.dit.upm.es:9090/servlet/AxisServlet. Using the Web Service interface automatic dependency resolution can be achieved

Perhaps there is a chance for collaboration here. Let me know if you are interested.

/jose

--
Jose L. Ruiz
DIT Departamento de Ingeniería de Sistemas Telemáticos
UPM Universidad Politécnica de Madrid
http://www.dit.upm.es/jlruiz



Pascal Rapicault escribió:
Hello,

Our provisioning system is made of installable units (things that can be
installed by a user). These installable units have "capabilities" and
"requirements". The capabilities are what satisfy the requirements. The
installation of an installable unit can only be successful if all the
"requirements" of this IU are satisfied, and thus recursively. Therefore it
looks like any operation installing, uninstalling, updating, etc is
equivalent to solving a constraint system.

That said, the few readings I have done on the topic of CSP seem to
indicate that the variables, constraints and domains constituting the
system to be satisfied are fixed. However it seems this approach would not
really work in our case since entities available in the domain may be
incompatible with each others (for example we could have installable unit
for multiple versions of eclipse in the repository). Therefore, I was
thinking of a more incremental approach where constraints and variables
would be added as new elements for the domain are being instantiated, but I
have not seen anything related to that in the literature.

So here are the questions:
- Is CSP applicable to this problem?
- Is there any algorithm that I should take a close look at (note that
there can be cycles between installable units) ?
- How scalable are the constraint solvers in presence of tens of thousands
of constraints and variables?

If you know someone (who know someone)* who can help, please pass it on.

Thanks in advance,

PaScaL

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

PNG image


Back to the top