[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

Hi Filip,
I think I understand what you mean. What I meant was that we can gain full control over the URI. It doesn't need to contain the redundant/problematic parts. Instead, it could contain just the id and the version range of the appointed IU. It's still a URI though and still a Proxy.

- thomas

On 2009-12-07 16:42, Filip Hrbek wrote:
Thomas Hallgren wrote:
On 2009-12-07 14:50, Filip Hrbek wrote:
I think the URI resolution in our ecore model could be rewritten to
actually resolve version ranges without too much effort.

We want to get rid of the URI in the map request (or mapped IU or whatever it is called). The repository URI is in the mapped repository and there is no reason to double the reference in its children (actually it causes implementation problems). So, even if we only allow to have mapping requests resolved
> into single IUs, we need to replace the proxy reference
with a self-contained request mechanism.

Not sure I follow. Please consider that one very important use-case is
to be able to provide configurations in separate files, just like we
do with Galileo. Proxy references are crucial. Without them,
everything sits together in one huge file and there's no way of
splitting it up.

We are mixing several things here - contributions, mapped repositories
and mapped IUs.

Of course we keep supporting EMF proxy references in general (e.g. for
What we need to get rid of is using proxy references for mapped IUs. The
URIs in there
are just partially duplicating the URIs in their containers (i.e. mapped
That's wrong because we need to take care of these URIs when changing
the repo locations.
Converting a mapped IU from a proxy reference to a concrete IU in the
repo into a mapping request
which is resolved (on the first level) before it is passed to the
aggregation processing does
not break anything and helps to keep the code clean.

To avoid misunderstanding, here is an example:


<repositories location="http://download.eclipse.org/releases/galileo";>



you can see the duplicated
"p2:http://download.eclipse.org/releases/galileo";, if the repo location
is changed, the IU reference breaks without implementing special event


<repositories location="http://download.eclipse.org/releases/galileo";>

<mapRequest type="feature"

you can see how transparent this is - the request keeps valid even if
the repo location is changed to something else.