[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [buckminster-dev] Re: Transient resolve and generated version types
|
ken1 wrote:
Well...I'm probably missing something obvious, but shouldn't a component
search path (i.e. at the granularity down to a specific component if need
be), describe how that component handles versions? It is supposed that it
uses the same version number strategy is used for all the forms the
component can take (probably an obvious requirement, as things would likely
be impossible to resolve otherwise...).
For one component yes, but assume that the following:
At the top you have a query for component A, version 1.0.2, version type
OSGi. The resolver finds A in the form of a jar file in a Maven repo. In
its associated POM descriptor, the cspec generator discovers a
dependency on component B version 1.0.beta-20060102. Although not a
valid OSGi version, it might well be some other well known type.
Question is, how do we figure that out and where do we keep the
knowledge of such types?
Even if we had a search path for each component, that wouldn't help
much. The resolver used a search path in order to find component A. Now,
when generating the cspec for A, it discovers a dependency to component
B. It needs to add that dependency to the cspec. This happens long
before an attempt is made to resolve component B (if ever).
And, the only way to make this fully generic is to make 'versionType' a
required attribute for a component in the rmap.
'a component in the rmap' might not be applicable. Consider the case
where we use a default search path that appoints ibiblio or where we map
all components that match a certain pattern to some repo. A repo that
handles many components can potentially have many version types.
Right now we have
versionType in the cspec, is that really the right place for it...?
The version type tells us how to parse the version string and how to
interpret the version semantics. I think it's essential that those two
(the version and its type) are kept together as a part of a dependency
description.
Again, maybe I'm off on the wrong tangent here, but dealing with a priority
based scheme sounds messy and easily goes non-deterministic.
I agree with this. But what is the alternative? Traversing a list of
types in the order they are declared perhaps? Not that different from
priority though (order == priority). Whatever we can come up with should
be as simple and deterministic as possible.
- thomas
