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

[kenneth@xxxxxxxxx]

Hmm, a bit hard to make proper inline comments, so instead I'll just  
write and try to make the connections to the points...and you know the  
cspec/rmap better so there's a fair amount of conjecture here...:-)

Well, looking at what you say I feel more strongly that the place for  
'versionType' is *not* in the cspec. The place should be in the rmap.  
I see no compelling reason that I as a user 'writing' a cspec have to  
know the versionType - all I know is that I need component FOO,  
version x.y.z or whatever version number I know about. The  
admin/whoever made up the rmap is aware however how FOO is structured  
version wise (so, maybe it's myself anyway, but...:-).

Consider what you say: in a POM descriptor you find a version 'number'  
to component B. Given the way we have set things up we transform the  
POM to a cspec. A cspec generally (now) has the notion of versionType.  
A POM however has not, so we can't put one into the cspec - that is  
precisely why we have a quandary. We could fix this if we could put in  
a cspex into B, but we can't (generally speaking).

Instead, the whole mapping thing is in the rmap. That provides the  
glue between a component name and its location(s) - and, I argue,  
between the versionType it uses.

So, assuming the cspec no longers holds the version type, where does  
this take us? Well, when generating the (or reading an actual) cspec  
simply shove the version in the model - it is not used yet anyway (I  
guess...do we need to interpret the version number at this stage?).

Eventually we need to resolve information from the cspec(s). A lookup  
is done into the rmap. Among all the other mappings, a version type is  
appointed - and now we have the information we need. The first thing  
to do is obviously ask the version type is if it recognizes the  
version the cspec knows about - if not, there is evidently an error  
made somewhere, so throw an exception and complain. Assuming all is  
well, resolvement can work as expected at this point.

As to the issue that a repo (say ibiblio) can potentially contain  
components having lots of different version strategies...so? Only  
means that we have a searchpath for each component that are different.  
Oh, presumably the rmap could be more efficient and there actually is  
a single searchpath for ibiblio that by default has one version type,  
but there'd be overrides for particular components - 'aha, well  
component B here, that one is a bit peculiar'. Or something.

Looking at the dogfood rmap, here'a a line from the maven searchpath:

  <mp:entry name="se.tada.util.sax" groupId="se.tada" artifactId="tada-sax" />

Couldn't this be outfitted to read like this instead:

  <mp:entry name="se.tada.util.sax" groupId="se.tada"  
artifactId="tada-sax" versionType="OSGi" />

Couple this with a default versionType attr for the searchpath itself  
(or perhaps the provider or whatever), to be used when the entry  
doesn't list any.

Completely predictable, no guessing or priorities involved (and how  
could we ever have two slightly different version types correctly  
recognize number '1.2.3' where the OSGi version type recognizes it,  
but so does the other because it knows that there may be an optional  
letter at the end (i.e. '1.2.3B' would no longer be acceptable to OSGi).

I again assume that a given component always use the same versionType  
whatever its format (source, binary etc). OTOH, maybe it would be  
possible to actually allow them to shift...???

So...what's the big hole that sinks the ship in this...? And if there  
is, can we adjust it?

ken1