Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [buckminster-dev] How to improve mapping rules in the Aggregator

Thomas Hallgren wrote:
On 2009-12-08 11:44, Filip Hrbek wrote:
When the reference to the IU is established, it refers to a resolved IU
instance
and its proxy URI is undefined at that time.
The proxy URI is generated by the EMF resource implementation at the time
the model is being saved. It is unclear to me how we are going to hack
this.
Even if we do, is that a proper usage of EMF?

The advice to rewrite the URI resolution comes from Ed Merks. I'm not an expert, but he is.


OK, I'll talk to Ed about this to learn more.
Before I do, I'd like to ensure that I understand your thought:

If the proxy URI is resolved according to its version range, then mapping
the same IU twice (at different places) with different upper version range
bounds makes the whole model unresolvable - even though a solution exists
in fact. Is that assumption correct? If so, is it acceptable for users?

Example:

Mapping 1: a.b.c#[1.0.0,2.0.0] resolves to a.b.c#2.0.0
Mapping 2: a.b.c#[1.0.0,1.5.0] resolves to a.b.c#1.5.0

In addition to this, there may be a transitive request to include
a.b.c#[0.0.2,1.2.0] (from a dependency of something else).

If we resolve each of the two mappings using EMF proxy URI resolution
one by one (before we run the resolution of all contributed content),
we'll get a conflict.


Third, I would provide the GUI necessary to alter the range boundaries
(i.e. tweak the proxy). This is probably just a matter of adding a
custom derived property to the model (or perhaps more then one to
bring clarity).


This is also unclear to me - where do we add the properties? Are they
persistent/transient? How do we edit them?

They are transient. There are some examples in the book on how to do this.


And where are they? On the InstallableUnitReference which refers to the actual IU?
Or anywhere else?

Filip


Back to the top