[
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
|
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.
To summarize, I think it's important to keep MapRequest and Rule
separate and that a MapRequest conceptually resovles to one single IU
(best fit) whereas rules are much more open.
This is a very technical point of view. From user perspective, I can't
see such a difference between a rule and a mapping request.
On the contrary. I can see how a technical solution can merge rules and mappings into the same thing. I don't believe
it's very intuitive though. Appointing things in the source repositories (either by drag-n-drop or by selecting in a
list) is one thing. Describing rules that controls configurations, properties, and what not, is completely different
altogether. I fail to see how merging them would bring anything but confusion to the end user.
An idea: If we want to fix a problem in the original repository (such
> as SVN native libraries), what about changing the metadata so that the
> unvalidated features would not be visible for platforms that were not
> validated?
Changing meta-data is very problematic. Everything in p2 works on the notion that an IU is immutable. So if you change
an IU, you need to give it another name or another version. That in turn, potentially breaks the meta-data that is
dependent on the IU since the version ranges used there doesn't include your new version. So the effect ripples up. Not
to mention that suddenly, you have gained responsibility for maintaining the IU in question.
I think the approach has to be to not change IU's (with the exception of categories. They don't have proper versions and
are not really used as IU's). Whatever rules or other functionality that we provide, it must be to make it easy to
aggregate what's out there. Not to change it.
- thomas
