[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[p2-dev] Dependency management synergies
- From: Oleg Gusakov <oleg.subscriptions@xxxxxxxxx>
- Date: Tue, 03 Feb 2009 21:29:00 -0800
- Delivered-to: firstname.lastname@example.org
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=oJ4XkrtruKMv7ORz05J8Lng1BM/cLjU1pBaydMJJm36FyJ3uWuRjtHfpy6ya8Amhz3 ujeB7uF+tT+KDl5+1AUbtVRrZ0TtUaNw0S0p+qnumPRzQyLi7yYkbSSuBgmtaHoWKnNj rUyilY8HXxQyoiwsDAHjExXK3Ey4AwjJuqgVo=
- User-agent: Thunderbird 220.127.116.11 (Macintosh/20081209)
To introduce myself - I lead the Mercury project
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.
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.