|Re: [p2-dev] Dependency management synergies|
Congratulations with your acceptance!
Daniel Le Berre wrote:
What do you think about this synergy? I think that together we can come up with a very cool standard dependency resolution library.Hi Oleg, Oleg Gusakov a Ãcrit :To introduce myself - I lead the Mercury project (http://docs.codehaus.org/display/MAVEN/Mercury, http://blogs.sonatype.com/people/author/oleg/), in which we try to clearly externalize Maven dependency management into a separate library, consumable by any client, not necessarily Maven. And the nature of the project calls for generalization - after all we all are trying to solve the same problem - calculate dependency graph, given a set of requirements and a set of repositories, that can satisfy those requirements. It really does not matter whether we calculate java or OSGi dependencies because all boils down to creating a system of linear inequations and solving it, in both cases with SAT4J. Why don't we try to unite our efforts and produce a library that all of can use: express our requirements in the unified intermediate language and process these statements with this library to produce a solution. Which could then be interpreted into either environment.
Actually - I already looked at it and am eagerly waiting for 2.1 to start using it. Do you have any schedule in mind?The mancoosi project - http://mancoosi.org as one of it's goals - states "Develop better algorithms and tools to plan upgrade paths based on various information sources about software packages and on optimization criteria". Why don't we try similar approach in the java world? Please share what you think about it. Pascal ? :) 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.The code of p2 available in the branch "explanation_work" does use direct calls to SAT4J API. This was needed to gather explanations from SAT4J when no solution can be found. All the translation is done through a Facade called "DependencyHelper". http://svn.forge.objectweb.org/cgi-bin/viewcvs.cgi/sat4j/maven/trunk/org.sat4j.pb/src/main/java/org/sat4j/pb/tools/DependencyHelper.java?rev=300&view=markup That class allows to express constraints with domain objects without worrying about the details of the SAT encoding. You need the code of SAT4J HEAD to get that class (upcoming release 2.1).