Hi Oleg, all,
I haven't dug into any of the code yet, but I've read through the
document you were working on. It seems positive and makes sense. I did
get a bit lost on the meaning of the "Tree Builder" section as it
doesn't seem to describe the current tree or graph technique, but
maybe illustrate the possible combinations?
Anyway, a few things caught my attention...
You mentioned about the inconsistency of whether 3.8.1 means "must be
3.8.1" vs "I'm using 3.8.1 right now but I'm not really sure which
versions it works with". Pretty much everyone putting POMs together
does the latter, as they are not trained in specifying ranges, and
because projects do not always follow the guidelines on versioning
such that compatibility can be measured. You also mentioned that some
change to the way ranges are specified might be needed. I'm wondering
what thoughts you have on how we specify dependencies need to be
different from today?
I do think the compatibility question is an interesting one. We could
theoretically build up a compatibility database in the central
repository, even using clirr to make initial assessment on java
artifacts. However this is unfortunately never a binary decision
either, as you may not be using the incompatible parts, and
compatibility can break in non-API ways.
I'm curious about how these work in terms of remote retrieval (ie,
where consulting metadatasource is a costly operation). When I looked
at p2 in Sept last year, they stored all the repository artifact
metadata in a single, large file. Are we expecting to need some
partial or full resolution of the repository content?
Do you think depth resolution is still relevant if we have a better
method? I believe the only depth we really should care about is "1" -
those immediately specified (and particularly those managed by
depMgmt). With that in mind, how can the use of depMgmt help in
reducing the problem space during resolution?
You also mention OSGi resolution at the end. Is it your intent that
one of the goals of the mechanism is to be able to be a complete OSGi
resolver?
I'm also interested in seeing explicit listing of the problems we aim
to solve to ensure we have objectives/scope. For example:
- lack of alternate conflict resolution in current artifact mechanism
- reduction in amount of metadata and artifacts dragged in (ie, stuff
that could use maven 2.0.9 still pulls down whatever version of maven
it was built against, even when it's not used)
- deterministic building over time
Just my initial thoughts - I'll follow your progress as you continue
investigating :)
Cheers,
Brett
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
