Let's discuss this on Thursday. We just need to make sure to write up
summary emails from the day and post them back to the list for further
discussion.
Ralph
Oleg Gusakov wrote:
Ralph Goers wrote:
I have no problem with including the wagon. I've read the wiki pages
on Mercury and I'm not satisifed with the dependecy resolution
improvements. As I've said before, any scheme that relies only on
resolving artifact versions isn't going to solve the problem.
Ralph,
Problem I am tackling in regard to dependency resolution is:
* for each Artifact we have a list of dependencies
* each dependency is defined as a tuple: <groupId, artifactId, query>.
o the query part is:
+ good old version
+ osgi-like version range
+ extentions - TBD
* for each Artifact - dependency tuples are supplied by abstracted
out DependenceyProcessor interface
* depending on the goal - build DependencyTree (implemented) for
classical java classpath or DependencyGraph (will be added when
the first one catches up) for OSGi-like resolution
* *given a root Artifact produce* a non-conflicting set (or more
complex structure - tree of DependencyNode's, graph) of dependent
Artifacts
* conflict is defined as: [G1:A1:V1] & [G2:A2:V2] & G2==G1 & A2==A1
& V2 != V1
This is all the dependency resolution does, the rest is outside of it.
Are we talking about the same problem?
Thanks,
Oleg
We can talk more about this on Thursday.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
