Re: [buckminster-dev] How to improve mapping rules in the Aggregator

[Thomas Hallgren <thomas@xxxxxxx>]

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
> contributions).
> 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
> repositories).
> 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:
>
>
> CURRENT SOLUTION:
>
> <repositories location="http://download.eclipse.org/releases/galileo";>
> <metadataRepository
> href="p2:http://download.eclipse.org/releases/galileo#//@metadataRepository"/>
>
> <features>
> <installableUnit
> href="p2:http://download.eclipse.org/releases/galileo#//@metadataRepository/@installableUnits[id='org.eclipse.acceleo.examples.feature.group',version='0.8.1.v200909161003']"/>
>
> </features>
> </repositories>
>
> 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
> handlers.
>
> PROPOSED SOLUTION:
>
> <repositories location="http://download.eclipse.org/releases/galileo";>
> <metadataRepository
> href="p2:http://download.eclipse.org/releases/galileo#//@metadataRepository"/>
>
> <mapRequest type="feature"
> id="org.eclipse.acceleo.examples.feature.group"
> versionRange="[0.8.1.v200909161003,0.8.1.v200909161003]"/>
> </repositories>
>
> you can see how transparent this is - the request keeps valid even if
> the repo location is changed to something else.
>
> Filip