[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [buckminster-dev] Re: Transient resolve and generated versiontypes
|
From a purely technical standpoint, the crucial question is this:
Is the version type information for a given component important to know
*before* or *after* mapping the component name to the info in the rmap?
I'm assuming/understanding that it is only important to know *after*. As you
say, the code *must* know about it, otherwise the whole deck of cards fail,
but the issue is still when it's needed.
Considering your comment about that it sounds like a good idea having
version type information in the mp:entry element, it seems to me that the
above assumption is correct. Continuing that thought: if it is ok for 'a
Maven component' to get that information from the rmap, then logically, it
must be ok for *any* component.
Can we agree on this as correct in principle?
Assuming yes, it's then a bit of a 'philosophical' issue perhaps; is it ok
to separate the information about the version designator and the type for
that designator into two separate locations?
Well, I don't see why not. The component name and version designator is a
'logical/soft' thing (perhaps, 'what I want'). The version type is
'physical/hard', just as in what repository/ies it can be found and how it
should be accessed from there (i.e. perhaps 'how to turn what I want into
reality). So a component query (or more specifically then, the component
name and version designator in it) by itself is really of little use (in
this particular respect) without an rmap that can turn the 'logical'
component name into some hard facts. Therefore, it seems to me to be fairly
reasonable to have the rmap carry the version type information as well.
If we think in terms of *human* roles (which is what I mean by the statement
about '...all I know...') it might go something like this:
I, the 'plain Buckminster user' reads about a fabulous new component
'CoolThing' that I would like to try. I also read that it is now available
as version '0.1beta-1'. So I cobble up a cquery for that combination of
name/designator.
However, when trying that out Buckminster throws an error and complains that
'sorry, don't know anything about a CoolThing component'.
So, I turn to my friendly Buckminster-and-components savvy
partner/consultant/whatever and point them to the CoolThing information.
He/she examines it a bit deeper and soon figures out one of two things: 1)
the CoolThing developers uses a version type known and implemented, or, 2)
the version type as described has no version type handler implented, so one
is created (that was quick :-). Finally, they enter the required information
into the rmap I use, and get back to me.
Now I can run my query, blissfully unaware of how it was all achieved.
Assuming the version type was implemented correctly everything should still
work the next week when I upgrade my version designator to [0.1beta-1,0.2)
or some such. Obviously at that time I probably need more knowledge about
the nuances on the semantics of what constitutes a 'later' version etc, but
that's not quite the same as knowing *exactly* what the version type is
called and the *absolute* details.
?
ken1
----- Original Message -----
From: "Thomas Hallgren" <thomas@xxxxxxx>
To: "Buckminster developer discussions" <buckminster-dev@xxxxxxxxxxx>
Sent: Tuesday, July 18, 2006 7:06 PM
Subject: Re: [buckminster-dev] Re: Transient resolve and generated
versiontypes
A dependency to a component will (optionally) contain a version designator,
i.e. [1.2.3,4.0.0) or [alpha,gamma). Are you saying that its wrong that the
dependency would provide information on how to interpreted that designator?
In some respect that would imply that there can be a need for different
interpretations. I can't really see when that would be the case.
The version designator consists a minimum version instance or a range
delimited by two instances. The instance(s) is of a certain type. The type
assigns the semantics and necessary magnitude characteristics to the
instances. If you don't know the type, how can you know how to constitute
an instance?
You say that "all I know is that I need component FOO, version x.y.z". How
do you know that if you have no knowledge of what 'x', 'y', and 'z' really
is?
I like your suggestion to add a versionType attribute to the mp:entry
element. That could be a good way of telling the Maven component type that
"when generating a cspec with a dependency that appoints some version of
tada-sax, you should use the OSGi versionType for that dependency".
Regards,
Thomas Hallgren
_______________________________________________
buckminster-dev mailing list
buckminster-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/buckminster-dev
