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



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

Thomas Hallgren

buckminster-dev mailing list