Piéroni Raphaël wrote:
Hello,
I have not so much time, but i am volunteering on this if some one can point
me to the 'dependency graph api'.
And i needed some idea of code to work at home. this one is especially
insterresting part (obviously the prolog one - Steve, if you can point me to
the java-prolog library you know. the only one i know (and never used) is
http://sourceforge.net/projects/amine-platform)
> I have not so much time, but i am volunteering on this if some one
can point
> me to the 'dependency graph api'.
> And i needed some idea of code to work at home. this one is especially
> insterresting part (obviously the prolog one - Steve, if you can
point me to
> the java-prolog library you know. the only one i know (and never used) is
> http://sourceforge.net/projects/amine-platform)
I didnt know of that one.
The one I know of is "Jlog": http://jlogic.sourceforge.net/ .
Our deployment runtime (smartfrog) can use this or other logic engines
that can be dropped in to our constraint API, so that when you deploy
things you can declare constraints in the logic language; let the system
work out for itself what a good solution is to some of the constraints.
We explicitly support other back ends so that we remain LGPL instead of
GPL;
I don't know what maven has in terms of a dependency API; what I'd do is
-grab the pom files (well, be pointed at a repository and walk the tree)
-extract the XML data
-assert that all as facts in the prolog database
-add extra rules
resolve out interesting facts
e.g
m(junit,junit,3.8.1).
m(log4j,log4j,1.2.8).
depends(m(junit,junit,3.8.1),m(log4j,log4j,1.2.8)).
Otherwise It is easy to declare transitive dependencies
depends(X,Y) :- depends(X,Z),depends(Z,Y).
Then you can get all solutions to a problem :
depends(m(me,myapp,3.4)),X).
exclusions complicate this model. Not having written proper prolog for a
decade, it doesnt come to me off the top of my head. Something like X
depends on m(G,A,V) if there isnt an excludes(X,m(G,A,_)), but prolog
isnt great for specifying negative facts.
Version rules are the other complexity. You can declare that a module is
newer than something with the same group/artefact if its version tag is
newer:
newversion(m(Group,Artefact,Version),m(Group,Artifact,Version2)) :-
Version > Version2.
Then add rules about only the newest version of anything being used.
If you've never done Prolog, it is a different way of thinking. It
should mesh very well with XML work. I've done RDBMS stuff with it in
the past, and makes some things wonderfully easy (if desperately
inefficient)
-steve
Regards,
Raphaël
2006/2/7, Steve Loughran <[EMAIL PROTECTED]>:
I personally think an interesting project for someone with time on their
hands would be to write some code to walk the repository and derive
useful facts from the dependency graph. I know this is on Brett's todo
list, but it doesnt actually need repository/CVS access, and could be
written by anyone.
Things you could do with the right tool
-reverse analysis, who uses "junit", or junit-3.7
-cycle detection; who depends on a dependency
-missing artifacts: what depends on things that arent there (split into
sun, OSS, proprietary)
-scale: who depends on the most stuff
-stability: who is most bleeding edge, versus trailing
output: generate fancy SVG graphs from it, or RDF triples for the fun of
it.
Having just been doing complex graph work in Java, I'd actually consider
using Prolog for working with the dependency graph; the plugins for java
are usually LGPL or GPL based though, especially the working ones (like
JLog).
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
