[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [buckminster-dev] Re: Transient resolve and generated version types
|
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