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

[Thomas Hallgren <thomas@xxxxxxx>]

On 2009-12-08 00:08, Filip Hrbek wrote:
> Thomas Hallgren wrote:
>> Yes. That sounds like more or less exactly what we want.
>
> Not if we use version ranges - in that case, the IU is resolved to
> something which may be in conflict with other contributions even though
> the aggregation as a whole is still resolvable (see below).
>
Uh, that sounds like a completely different problem (see below).

>> > The presentation of the request would not have to analyze whether
>> > the request is resolvable or not until we want to show status or
>> > mapping hints to the user.
>> >
>> Is that a good thing? I would prefer if all markers etc. were in place
>> from the start so that I can click through my problem view and perhaps
>> execute suggested fixes.
>
> Nothing prevents you from doing this. I suppose that very little will
> change from the user perspective.
>
Sure, but the advantage you just brought up (deferring the analyze) is gone.

>> The advantage is that normal model navigation applies. The engine
>> could do exactly what it does today with no changes.
>>
>> I suspect that we will run into a whole slew of problems if we remove
>> the EMF dependency. A simple change in how the proxy is resolved
>> sounds a lot simpler and safer.
>
> I don't agree here. First, I can't think of a single problem that could
> arise with proposed solution.
>
Problem number one:
Backward compatibility. My suggested approach would have a proxy resolver that acts on a URI. This resolver can easily 
detect if the URI is the old style or a new style. The model is essentially unchanged. If we instead change the model 
and remove the dependency, the backward compatibility layer becomes more complex.

Problem number two:
The EMF model is built on dependencies, containment, reverse dependencies, etc. If we simply remove the dependency, all 
of that is gone and we need to maintain notifications etc. ourselves. All future code (b3 for instance) that wants to 
use the model must cater for our special "almost a dependency but in fact not" solution.

> Second, I don't think current model is capable to  handle version ranges.
>
> An example:
>
> Contribution 1
> |
> + Mapped Repo 1 (http://x.y.z)
> |
> + Feature a.b.c [1.0.0,2.0.0]
> Contribution 2
> |
> + Mapped Repo 2 (http://x.y.z)
> |
> + Feature a.b.c [1.0.0,1.5.0]
>
> If we let EMF resolve the IUs behind the feature "a.b.c", we will get
> a.b.c#2.0.0 for Repo 1 and a.b.c#1.5.0 for Repo 2. Assembling this into
> the all.contributed.content will end up with a resolution conflict.
>
> If we assemble the all.contributed.content from the partial requests,
> it will be resolvable (both contributions will agree on contributing
> a.b.c#1.5.0)
>
That assumes that you don't give the user feedback of what will actually be mapped before you run the aggregation so 
that's a non-starter IMO.

I think a better solution would be to analyze the features that are mapped and make a best effort to come up with a set 
of unique features. If that's not possible, then the planner will not be able to do it either. If we do it that way, we 
stand a chance to give the user early and relevant feedback about potential conflicts as soon as the version ranges are 
entered.

We will also address another problem. If feature 'a' includes feature 'b' and 'c', then there is very little reason for 
the user to map 'b' and 'c' once 'a' has been mapped. It would be great if the user could be made aware of situations 
like that (see thread 'lacking features and some small problems' on the buckminster newsgroup).

- thomas