[buckminster-dev] Re: Transient resolve and generated version types

["ken1" <kenneth@xxxxxxxxx>]

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...).

And, the only way to make this fully generic is to make 'versionType' a 
required attribute for a component in the rmap. Right now we have 
versionType in the cspec, is that really the right place for it...?

Again, maybe I'm off on the wrong tangent here, but dealing with a priority 
based scheme sounds messy and easily goes non-deterministic.

ken1

"Thomas Hallgren" <thomas@xxxxxxx> wrote in message 
news:44A43F6A.1080804@xxxxxxx...
> The problem:
> When using a provider that finds components that in turn have dependencies 
> to other components, we build a cspec that has dependencies. At present, 
> the Maven provider will set the versionType attributes in such 
> dependencies is set to default, i.e. OSGi. This will sometimes fail since 
> components in a maven repository might use version representations that 
> doesn't comply. The way we resolve that today is to use a CQUERY that 
> contains a version type override for those components but that's far from 
> ideal (the generated CSPEC is still not correct). A better approach would 
> be to somehow control the generation of the version type.
>
> A possible solution:
> A provider could be equipped with automatic recognition of version types. 
> We add a method to each version type that answers yes or no to if a 
> version is recognized. Any given version would then be recognized by 1-M 
> types (there will always be one since the string type accepts all 
> representations). In cases where more then 1 version type would recognize 
> a given version, we would consult a table describing version type 
> priority. Highest priority wins.
>
> The table could either be defined on a per provider basis or in a broader 
> scope using properties (scoped by rmap, site, cquery).
>
> I though about extending the version type extension point with a 
> 'defaultPriority' but priority conflicts may arise since we don't maintain 
> a global repository of all version types. Another con is that different 
> users might have different preferences.
>
> Thoughs?
>
> Regards,
> Thomas Hallgren