[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