[
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
|
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.
Does it mean that we must keep the original model forever? No!
We have two options:
a) provide a conversion tool
b) implement automatic conversion attempt on unsuccessful opening
It's always better to clean up the model than to keep backward capability together
with problems. Using option b), current users won't notice that anything
has changed.
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.
Not sure I follow - could you provide a concrete example of what we
are breaking and what problems you can see there?
We are talking about requests what to map, not about concrete IUs to map.
So I think that the proposed solution is much much cleaner and I would expect
much less problems than now.
> 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.
I have this in mind too. It is not a better solution, it is yet another
addition to that solution. I can imagine running this analysis if we
don't use EMF URI resolution for mapped IUs.
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).
Yes - the same as the paragraph above. However, if contributors are people
from different companies for example, it makes sense that each of them
specifies his own requirements that may overlay someone else's requirements.
If the result is resolvable, then this approach is still ok even though
there are unnecessary duplicities in the requirements.
It's too late, I need some sleep :-)
Filip
